[83768] in North American Network Operators' Group
Re: 4-Byte AS Number soon to come?
daemon@ATHENA.MIT.EDU (Yakov Rekhter)
Wed Aug 24 16:11:35 2005
To: Daniel Golding <dgolding@burtongroup.com>
Cc: Iljitsch van Beijnum <iljitsch@muada.com>,
Susan Hares <skh@nexthop.com>, NANOG list <nanog@merit.edu>
In-Reply-To: Your message of "Wed, 24 Aug 2005 09:15:42 EDT."
<BF31EB3E.E173%dgolding@burtongroup.com>
Date: Wed, 24 Aug 2005 13:10:50 -0700
From: Yakov Rekhter <yakov@juniper.net>
Errors-To: owner-nanog@merit.edu
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" <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
>
