Protocol Action: 'BGP Support for Four-octet AS Number Space' to Proposed Standard

[The IESG <[e-mail]>]

The IESG has approved the following document:

- 'BGP Support for Four-octet AS Number Space '
   <draft-ietf-idr-as4bytes-13.txt> as a Proposed Standard

This document is the product of the Inter-Domain Routing Working Group. 

The IESG contact persons are Bill Fenner and Ross Callon.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-13.txt

Technical Summary
 
   Currently the Autonomous System number is encoded as a two-octet
   entity in BGP. This document describes extensions to BGP to carry the
   Autonomous System number as a four-octet entity.

   Based on historical and current allocation rates, the range available
   to two-octet AS numbers is expected to run out in 2010.

Working Group Summary
 
     This is a long-standing work item for the working group, with the
     first draft being published in February 2001.

     The approach described in the draft to support 4 Byte AS numbers
     is one of no change to BGP in terms of protocol in all but one
     aspect: The OPEN message uses a 4-Byte capability advertisement
     and the use of a 2 Byte MyAS field value. In all other respects
     there is no change to the protocol elements of BGP, other than
     using 4 bytes where ASs are used.

     The other substantive topic of the draft is in the interoperation
     of 4-Byte AS speakers with 2-Byte AS speakers.

     The OPEN message with capability advertisement has attracted one
     comment that this is contrary to RFC3392, however a detailed
     analysis of this comment has not lead to substantiation of this
     comment.  Using this as a dynamic capability rather than an OPEN
     capability was raised as a comment, with the response that there
     is no reason to make the capability dynamic in this case.

     The tunnelling technique of using an opaque transitive community
     attribute to carry the 4-Byte AS Path attracted some comment. The
     comment was concerned with the reconstruction of the 4-Byte AS
     path across a 2-to-4 byte BGP boundary, where the algorithm for
     the reconstruction was, in some comments, not sufficiently
     well-defined.

     However it is also the case that the critical elements of the role
     of the AS Path are adequately described in the draft. The AS path
     length is used as a metric in the BGP path selection process, and
     the AS path itself is used for loop prevention. The draft
     specifies that the reconstruction of the AS path across a 2-byte
     to 4-byte AS transition should preserve the AS path length. The
     draft does not cover every possible eventuality of reconstruction
     of the 4-byte AS path, but a closer examination of the loop
     detection issue reveals that loops that may occur across a mixed 2
     Byte / 4 Byte path are detectable within one iteration of the loop
     within the 2-Byte component of the mixed loop path in all
     circumstances. Accordingly, both the use of the AS path length as
     a path metric and the use of the AS path as a loop detection
     mechanism are preserved in this approach, even though the draft is
     not definitive in describing the AS path reassembly algorithm in
     every possible eventuality. In other words the draft contains the
     necessary and sufficient minimum set of properties for AS path
     reconstruction, leaving the precise algorithm up to the
     implementation. This approach is not seen as impairing the
     functionality, interoperability or integrity of BGP, either within
     the context of the individual peering session or in the context of
     the broader IDR framework.

     A comment was raised that on-the-wire inspection of BGP updates
     would not know in all cases whether they were seeing 2-byte or
     4-byte AS BGP updates. The BGP update contains no additional
     control flags, and unless the on-the-wire device collects the
     initial OPEN message with the capability negotiation then the
     information as to 2-byte or 4-byte AS updates is not explicit. It
     has been noted that heuristics could be readily applied here, and
     the presence of the reserved 2-byte AS value 0 in the AS path is
     one indicator that the momitor is applying a 2-byte interpretation
     to a 4-byte BGP update.

     There were no other approaches referenced in the working group
     during Last Call, and the choice of this draft as representing one
     that is backwards compatible with existing BGP appears to have
     been an obvious obvious choice to the working group.

     The IETF Last call comments concernd the RFC3392 Capability
     Advertisement examination of these comments indicates that the
     concerns relating to RFC3392 are unwarranted, and the treatment of
     the capability advertisement is consistent with a conventional use
     of RFC3392 and is compatible with older versions of BGP.

     The IETF Last Call comments touched upon the larger size of BGP
     updates, and the desireability of using a compressed
     representation of AS Path.  The Working Group did not see any need
     to include a compressed representation of AS paths in BGP
     updates. It appears that the onus of making a case that some form
     of compressed encoding of these BGP fields is of merit lies with
     the proponents of this as a potential source of problem, and the
     solution with respect to the AS_PATH representation lies in
     RFC3392 with additional capabilities being negotiated, either at
     session OPEN time or possibly dynamically.  Thus, this 4-byte
     spec, that does not used compressed representation of AS_PATH is
     adequate, and those who believe that more compact representations
     are called for have a clear path of proposing such a specification
     to the IDR working group as a negotiated capability. The task for
     those who are of the opinion that such compact encodings are
     important to show why and propose a capability to be negotiated to
     do so in both the 4Byte and 2Byte worlds in the IDR Working
     Group.
 
Protocol Quality
 
   Bill Fenner and Geoff Huston reviewed the document for the IESG.
   There are implementations; see the implementation report at
   http://www.ietf.org/IESG/Implementations/bgp4_impleme.txt


_______________________________________________
IETF-Announce mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf-announce