BGP Support for Four-octet AS Number Space
RFC 4893

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:

  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 

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
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.