Привет, Какое-то движение появилось :) -------- Original Message -------- Begin forwarded message: Date: Fri, 09 Mar 2007 16:34:36 -0500 From: The IESG To: IETF-Announce Cc: idr mailing list , idr chair , Internet Architecture Board , RFC Editor Subject: Protocol Action: 'BGP Support for Four-octet AS Number Space' to Proposed Standard The IESG has approved the following document: - 'BGP Support for Four-octet AS Number Space ' 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 IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce --Steve Bellovin, http://www.cs.columbia.edu/~smb ----- End forwarded message ----- -- Katie Petrusha =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message