BGP Support for Four-octet AS Number Space
Summary: Needs a YES. Needs 9 more YES or NO OBJECTION positions to pass.
Note: This ballot was opened for revision 12 and is now closed.
( Mark Townsley ) Yes
Jari Arkko No Objection
( Ross Callon ) No Objection
( Brian Carpenter ) No Objection
( Lars Eggert ) No Objection
Comment (2006-10-23 for -)
Section 1., paragraph 2: > Two new > attributes, NEW_AS_PATH and NEW_AGGREGATOR, are introduced that can > be used to propagate four-octet based AS path information across BGP > speakers that do not support the four-octet AS numbers. I'd suggest to use a prefix other than "NEW_", which is both very unspecific and can't be extended in the future ("NEW_NEW_?") Maybe "AS4_" or something. Section 3., paragraph 1: > For the purpose of this document we define a BGP speaker which does > not support the new 4-octet AS number extensions as an OLD BGP > speaker, and a BGP speaker which supports the new 4-octet AS number > extensions as a NEW BGP speaker. Similar to above, I'd suggest something more descriptive than "NEW" and "OLD" here. Section 11., paragraph 1: > [AS-EXT-COM] Rekhter, Y., Ramachandra, S., and Tappan, D. "Four- > octet AS Specific BGP Extended Community", draft-rekhter-as4octet- > ext-community-00.txt, October 2005. Nit: Cited as [AS-EXT-COMM]
( Bill Fenner ) (was Discuss, Yes, Discuss, Yes) No Objection
( Ted Hardie ) No Objection
( Russ Housley ) No Objection
Comment (2006-10-24 for -)
To make it easier to update these attributes in the future, if needed. I suggest the use of a different prefix: NEW_AS_PATH --> AS4_AS_PATH NEW_AGGREGATOR --> AS4_AGGREGATOR From the SecDir Review by Vidya Narayanan: The security considerations section says: > > This extension to BGP does not change the underlying security > issues inherent in the existing BGP. > While this seems to be largely true, reading section 4.2, it appears that some incomplete AS path information or routing loops may occur as a result of interaction between old and new BGP speakers. It seems plausible that a rogue node could use this to its advantage to create such incomplete AS paths or routing loops. This is not a major concern, but may be worth mentioning in a sentence or two in the security considerations section.
( Cullen Jennings ) No Objection
( David Kessens ) No Objection
Comment (2006-10-25 for -)
Although this draft has been a long time in the making and has had a large number of revisions, I am a bit disappointed by its overall quality. The text is not particularly crisp and uses the words SHOULD (NOT) in way too many places where there really is little reason not to use a MUST/SHALL or MUST/SHALL NOT. For example, in section '6. Transition': 'An OLD BGP speaker SHOULD NOT use AS_TRANS as its Autonomous System number.' I am not convinced that a 'SHOULD NOT' is at all appropriate here. AS_TRANS has been allocated by IANA for a particular use as defined in this draft and there is no reason that I can see that there 'may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful' (as 'SHOULD NOT' is defined in rfc 2119) Operational problems are touched on but there is very little that helps the reader to understand what will happen when the possible failure scenarios do happen. The document signals: 'Under certain conditions it may not be possible to reconstruct the entire AS path information from the AS_PATH and the NEW_AS_PATH attributes of a route.' While it is explained how this could potentially happen, there is precious little guidance on what an implementor should do when it is detected that inconsistent information is received. The IANA section is similarly difficult: why does it not simply mention which values were assigned by IANA (together with a reference) instead of forcing the reader to look them up in the referenced rfcs/IANA registry. I am also somewhat annoyed that the draft does not contain a simple one line paragraph that describes the textual convention on how one should represent the 4 byte ASes in CLIs etc. It seems rather ridiculous that we will have to publish a second document just for this purpose and it is strange that there is no informative reference to this draft. In fact, if one is real suspicious, one may think that the actual values are not mentioned in the IANA considerations to avoid this topic altogether instead of just dealing with it as it has to be dealt with at some point anyways. To summarize, I don't think there is anything in the above that is blocking. On the other hand, this document could have have been much more clear and crisp. I also received the following review from the Ops Directorate by Pekka Savola: In general I'm not sure if the solution which reinterprets and redefines (conditionally) the existing attributes is a good idea rather than just using new attributes and rewriting those, but it seems that the current decision was made so long ago this is already a moot point. RFC3392 has replaced RFC2842 (DS vs PS) but replacing this is just an editorial update. [BGP] reference should also be updated to RFC4271. This document should probably have "Updates RFC4271" in the header, abstract and introduction, as the size of the AS_PATH and AGGREGATOR attributes changes depending on the capability "An OLD BGP speaker SHOULD NOT use AS_TRANS as its Autonomous System number." ==> why a SHOULD NOT? Isn't this a MUST NOT issue? " This document makes the four-octet, unsigned integers larger than 65535 available for allocation as AS numbers. These AS numbers need to be managed by the IANA "Autonomous System Numbers" registry." ==> does te new management have new IANA considerations? For example, should new private/reserved AS number spaces be taken out of the end (or some other part) of the 4byte AS ranges as well? D ==> Further, does IANA require guidance on how (e.g. how large blocks -- remember the sad story with IPv6 prefix allocation size to RIRs..) or when to start assigning from it? Specifically, should IANA keep "Reserved by the IANA" (48128 - 64511) to itself or redistribute those to RIRs as well? Should 4byte AS number allocations start at 2^16 or from some other number?
( Jon Peterson ) No Objection
( Dan Romascanu ) No Objection
( Magnus Westerlund ) No Objection
( Sam Hartman ) Abstain
Comment (2006-10-24 for -)
I don't think this document is clear enough that I would have a reasonbly good probability of successfully taking a BGP implementation, the BGP specs and this document and getting something interoperable out the other end. In particular, I think examples would significantly improve this document. If this were a less important document I would block it on the clarity issue. However I realize that this is something we need to get out soon and so I'm not going to block. I would object to advancing the current text to draft standard.