|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: 4-Byte AS Number soon to come?
Daniel, > 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?) The time it would take it to be deployed depends (among other factors) on whether the IDR WG would reach a (rough) consensus on moving forward with the existing spec, even if one may argue that there could be a better alternative to the existing spec. Yakov. P.S. For more details you may look at the on-going discussion on the IDR mailing list. > Thanks, > Dan > > On 8/24/05 2:57 AM, "Iljitsch van Beijnum" <[email protected]> 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 >
|