This is a good example of a useless argument caused when one
person is speaking from a customer viewpoint and one customer
is speaking from an operator viewpoint.
Last time I checked, the O in [EU|NA|AFRI]NOG stands for 'operator'.
Niels made a perfectly valid point by saying that it is impossible for
an end-user to be connected to the AMS-IX and he was flamed for it. If
Peter Dambier has no clue about end-hosts vs intermediate systems, let
alone how to parse a traceroute with his grey mass, he needs to be educated.
Just as I needed many years ago.
Anyway, this is going way off-topic so this will be my last post in this
subthread. Feel free to reply off-list.
Yes, I see, Sabri and me are on two different rails, one leading north,
the other one leading east. I hope Sabri still has got all his hairs.
I am counting mine now.
How many people on this list remember the transition from BGP3 to
BGP4 and CIDR? This was, uhh, about 12 years ago. Before that there
was an EGP to BGP transition, but that was less of an issue.
But history will repeat itself. Not that I see any great evil in that --
people are always busy, have always been. It's a case of which priorities
are most pressing, so, indeed, yes, the only way is to run out of the
existing resource. Likewise for whatever will provide more address space.-)
> The only way to get 32-bit AS number support deployed is to run out
> of AS numbers in
> the 16 bit space.
Exactly.
- When will the Internet deploy X?
- Just before it's too late.
How many people on this list remember the transition from BGP3 to
BGP4 and CIDR? This was, uhh, about 12 years ago. Before that there
was an EGP to BGP transition, but that was less of an issue.
EGP-BGP
BGP-BGP2
BGP2-BGP3
BGP3-BGP4
cidr ...
did them all. CIDR was a pita. took years. something about presumtions
by equipment vendors and burning those assumptions into silicon.
for most of the rest, we clustered the engineers into the IETF terminal
room (or the Interop NOC, back in the day) and "rebooted" the net.
most fun was the folks writing the code, hung-over from the night before,
trying to meet the 11:00 "deadline" before the noon hackery. Ah, the
bad ol'days.
But history will repeat itself. Not that I see any great evil in that --
people are always busy, have always been. It's a case of which priorities
are most pressing, so, indeed, yes, the only way is to run out of the
existing resource. Likewise for whatever will provide more address space.-)
i can only hope you are right. re-kindling the excitment and enthusiasim
that once existed will be a highlight.
I think, however, that this will be less dramatic than other
things. This is a "relatively" simple software change. The one thing
it *will* do is make sure that all the old hardware out there that
runs BGP won't work anymore and have to be updated. This is arguably a
good thing. Also remember that this is still some time away. Getting
ever closer, but still a future event.
Yes ... but those were easier, more overlap was possible, especially at
the edge. We had EGP peers right into BGP4 times. CIDR was more
universal, outright a 'flag day' all things considered. But never mind ...
i can only hope you are right. re-kindling the excitment and enthusiasim
that once existed will be a highlight.
Lemme see ... "Cisco hires Tony Li to lead next generation development." ?
Interesting thought, if nothing else.
Then, how about "All the big telcos rehire all the nerdy people that
got p****d off and left a long time ago".
Okay, so as people pointed out, I forgot that hardware engineers like
to make assumptions about software for the sake of efficiency in ASICs
and the like. So add a few exponents of pain. Still shouldn't be *all*
that bad I wouldn't think.
i think you misunderstand the h/w / s/w distinction here.
BGP is a 'control-plane'-driven protocol. control-plane = software.
no vendor would have BGP "in hardware" per-se (although its forseeable that they may have 'AS# accounting for netflow' in h/w and that may be limited to addressing 16-bits).
"forwarding a packet" (i.e. data-plane path) is typically in h/w in many {modern,large} routers. even if the routing protocol is based on AS#s, forwarding is typically based on a RIB creating a FIB.
a FIB typically doesn't contain AS# information as there is no need to - you're not 'forwarding' on AS#, you're forwarding on Destination address.
i think the distinction of "old hardware" that the original poster was trying to make was really one of things like RAM and Flash RAM space. if we take "Cisco routers" as an example, it may be that 32-bit AS# support mandates the use of the fictional IOS 12.666S software train which probably won't fit in the 16MB RAM and 16MB FLash on a 15-year-old c2500 series router.
cheers,
lincoln.
NB. obvious 12.666S is fictional. don't try to read anything into that. and if its not obvious, no i'm not officially talking for Cisco.
not at all - you are correct. The presentation at the last NANOG said that if you are in a routing domain with an existing 2 byte AS number then you need to change _nothing_. Of course, after a few years, you may come to the conclusion that AS23456 has launched a nefarious plot and is popping up all over the routing world, but you will still need to change _nothing_.
