Note: This ballot was opened for revision 12 and is now closed.
Summary: Needs a YES. Needs 9 more YES or NO OBJECTION positions to pass.
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
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
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?
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]
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.
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.