RE: 4-Byte AS Number soon to come?
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). Implementation reports give us the opinion of those who have already implemented the protocol. That's usually worth hearing about. Sue -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Iljitsch van Beijnum Sent: Tuesday, August 23, 2005 10:31 AM To: Yakov Rekhter Cc: NANOG list Subject: Re: 4-Byte AS Number soon to come? On 23-aug-2005, at 16:16, Yakov Rekhter wrote:
The IDR draft is awaiting implementation report.
If this is true, it's very distressing.
The IDR draft awaits an implementation report in order to advance the draft to Proposed Standard. What is so distressing about this ?
A draft is work in progress. We don't even get to refer to it because it's deleted after 6 months. As such, it's hardly less ephemeral than a conversation. You can't build implementations based on that. But I guess this is what happens with the convoluted "standards track" mechanism that the IETF currently uses. One thing that bothers me very much about this is that it will make changes that happen in IETF last call much harder. Essentially that means that anyone who isn't in IDR doesn't get to have his or her input considered.
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...
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
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
participants (4)
-
Daniel Golding -
Iljitsch van Beijnum -
Susan Hares -
Yakov Rekhter