4-Byte AS Number soon to come?

Thu Aug 25 14:06:53 UTC 2005

Dan:

(chair-hat-off)

I believe we need to move quickly.  3 years for a major new feature to
be fully deployed is tight.  But I don't want to deploy something that
causes operators problems.   If we change, we need to get the changed
defined and initial implementation out quickly.

(chair-hat-back-on)

I believe the WG can move quickly.  

Sue

-----Original Message-----
From: Daniel Golding [mailto:dgolding at burtongroup.com] 
Sent: Wednesday, August 24, 2005 9:16 AM
To: Iljitsch van Beijnum; Susan Hares
Cc: Yakov Rekhter; NANOG list
Subject: Re: 4-Byte AS Number soon to come? 

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