|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical 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" <[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
|