Re: 4-Byte AS Number soon to come?

[Daniel Golding <dgolding () burtongroup com>]

Susan,

In light of Geoff Huston's recent article which urged alacrity in finalizing
a standard and implementing the eventual solution, where are we in this
process? Geoff's article suggest that we have about three years until
Internet transit AS's should begin transitioning. Given the QA cycle at both
router vendors and major carriers, this means that the timeframe is quite
condensed, at least by IETF standards.

My question, in short, is, will we make it? (the corollary is, does the
IETF/IDR have a sense of urgency as they move this process along?)

Thanks,
Dan

On 8/24/05 2:57 AM, "Iljitsch van Beijnum" <iljitsch () muada com> wrote:

> 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...

-- 
Daniel Golding
Network and Telecommunications Strategies
Burton Group