4-Byte AS Number soon to come?

Wed Aug 24 06:57:58 UTC 2005

On 24-aug-2005, at 5:50, Susan Hares wrote:

> This is the first of many steps.  And to be fair to the authors, the
> process got held up due to the base draft being re-written.

> So, the key discussion points are (as Yakov has indicated as well):
>     a) Are there any technical problems with the specification
>     b) Does the specification cause operational problems?
>     c) General concerns about the design of the additions to BGP
>         (scaling, etc).

I find the design less robust than it could be.

What it does is define that toward a neighbor that also supports wide  
AS numbers it will send the AS path with 32-bit AS numbers, and  
toward a neighbor that doesn't support wide AS numbers it sends the  
AS path with 16-bit AS numbers and a "new AS path" with 32-bit AS  
numbers.

I think it makes more sense to ALWAYS send the old 16-bit AS path and  
the new 32-bit AS path attribute. This makes the code path identical  
for the two types of peers, which is less likely to lead to new bugs  
and makes for easier (operational) debugging.

> Implementation reports give us the opinion of those who have already
> implemented the protocol.  That's usually worth hearing about.

As an operator, I'm sorry to say I don't always have the highest  
possible opinion of the people implementing the protocols. (I always  
say: never ask the people who built the thing what it can do.)  
Obviously implementing a specification is a crucial step, and an  
illuminating one because it brings out bugs and hidden assumptions in  
the specification. It can also uncover a broken design, but I hope  
and believe this is relatively rare. (And it's not like a broken  
design is automatically unimplementable, so implementation is  
certainly not guaranteed to bring out design problems.) So yes, it's  
worth hearing about, but not worth delaying publication for. And  
since the IETF only has one way to publish documents for periods  
extending six months...