--- 1/draft-ietf-idr-as4bytes-09.txt 2006-02-04 23:29:15.000000000 +0100 +++ 2/draft-ietf-idr-as4bytes-10.txt 2006-02-04 23:29:15.000000000 +0100 @@ -1,40 +1,36 @@ - Network Working Group Quaizar Vohra Internet Draft Juniper Networks -Expiration Date: June 2005 Enke Chen +Expiration Date: January 2006 Enke Chen Cisco Systems BGP support for four-octet AS number space - draft-ietf-idr-as4bytes-09.txt + draft-ietf-idr-as4bytes-10.txt 1. Status of this Memo - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - or will be disclosed, and any of which I become aware will be - disclosed, in accordance with RFC 3668. - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress". + material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. Abstract Currently the Autonomous System number is encoded in BGP [BGP] as a @@ -43,21 +39,21 @@ 3. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 4. Protocol Extensions For the purpose of this document lets define a BGP speaker which - doesn’t support the new 4-octets AS number extensions as an OLD BGP + doesn‚ÇÖt support the new 4-octets AS number extensions as an OLD BGP speaker, and a BGP speaker which supports the new 4-octets AS number extensions as a NEW BGP speaker. BGP carries the Autonomous System number in the My Autonomous System field of the OPEN message, in the AS_PATH attribute of the UPDATE message, and in the AGGREGATOR attribute of the UPDATE message. BGP also carries the Autonomous System number in the BGP Communities attribute. A NEW BGP speaker uses BGP Capability Advertisements [RFC2842] to @@ -100,21 +96,21 @@ into 4-octets Autonomous System numbers by setting the high-order 2 octets of the 4-octets field to zero. Such a 4-octets AS number is said to be mappable to a 2-octets AS number. To represent 4-octets AS numbers (which are not mapped from 2-octets) as 2-octets AS numbers in the AS path information encoded with 2-octets AS numbers, this document reserves a 2-octets AS number. Lets denote this special AS number as AS_TRANS for ease of description in the rest of this specification. This AS number is also placed in the My Autonomous System field of the OPEN message - originated by a NEW BGP speaker if the speaker doesn’t have a + originated by a NEW BGP speaker if the speaker doesn‚ÇÖt have a (globally unique) 2-octets AS number. 5. Operations 5.1. Interaction between NEW BGP speakers A BGP speaker that supports 4-octets Autonomous System numbers may advertise this to its peers using the BGP Capability Advertisements. A BGP speaker that advertises such capability to a particular peer, and receives from that peer the advertisement of such capability MUST @@ -128,21 +124,21 @@ speaker that receives the NEW_AS_PATH and NEW_AGGREGATOR path attributes in an UPDATE message from a NEW BGP speaker should discard these path attributes and continue processing the UPDATE message. 5.2. Interaction between NEW and OLD BGP speaker 5.2.1. BGP Peering Note that peering between a NEW BGP speaker and an OLD one is possible only if the NEW BGP speaker has a 2-octets AS number. - However, this document doesn’t assume that an Autonomous System with + However, this document doesn‚ÇÖt assume that an Autonomous System with NEW speakers has to have a globally unique 2-octets AS number - AS_TRANS could be used instead (even if multiple Autonomous System would use it). 5.2.2. Generating Updates When communicating with an OLD BGP speaker, a NEW speaker MUST send the AS path information in the AS_PATH attribute encoded with 2-octets AS numbers. The NEW speaker also MUST send the AS path information in the NEW_AS_PATH attribute (encoded with 4-octets AS @@ -160,21 +156,21 @@ The NEW speaker constructs the NEW_AS_PATH attribute from the information carried in the AS_PATH attribute. In the case where the AS_PATH attribute contains either AS_CONFED_SEQUENCE or AS_CONFED_SET path segments, the NEW speaker, when constructing the NEW_AS_PATH attribute from the AS_PATH attribute, must exclude such path segments. The NEW_AS_PATH attribute will be carried across a series of OLD BGP speakers without modification and will help preserve the truely 4-octets AS numbers in the AS path information. Similarly, if the NEW speaker has to send the AGGREGATOR attribute, - and if the aggregating Autonomous System’s AS number is truely + and if the aggregating Autonomous System‚ÇÖs AS number is truely 4-octets, the speaker constructs the NEW_AGGREGATOR attributes by taking the attribute length and attribute value from the AGGREGATOR attribute and placing them into the attribute length and attribute value of the NEW_AGGREGATOR attribute, and sets the AS number field in the existing AGGREGATOR attribute to the reserved AS number, AS_TRANS. Note that if the AS number is 2-octets only, then the NEW_AGGREGATE attribute should not be sent. 5.2.3. Processing Received Updates @@ -282,22 +278,22 @@ The authors would like to thank Yakov Rekhter, Chaitanya Kodeboyina, and Jeffrey Haas for the numerous discussions which went into the making of this draft. 11. References [BGP] Rekhter, Y., Li, T., and Hares, S., "A Border Gateway Protocol 4 (BGP-4)", draft-ietf-idr-bgp4-26.txt, October 2004. [EXT-COM] Ramachandra, S., Tappan, D., and Rekter Y. "BGP Extended - Communities Attribute", draft-ramachandra-bgp-ext-communities-07.txt, - March 2004. + Communities Attribute", draft-ramachandra-bgp-ext-communities-09.txt, + July 2005. [RFC1997] Chandra, R., Traina, P. and T. Li, "BGP Communities Attribute", RFC 1997, August 1996. [RFC2842] Chandra, R., and Scudder, J., "Capabilities Advertisement with BGP-4", RFC 2842, May 2000. [RFC3065] Traina, P., McPherson, D., Scudder, J., "Autonomous System Confederations for BGP", RFC3065, February 2001. @@ -307,20 +303,22 @@ 12. Author Information Quaizar Vohra Juniper Networks 1194 N.Mathilda Ave Sunnyvale, CA 94089 e-mail: qv@juniper.net Enke Chen Cisco Systems, Inc. + 170 W. Tasman Dr. + San Jose, CA 95134 e-mail: enkechen@cisco.com 13. Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information @@ -335,21 +333,23 @@ http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. 14. Full Copyright Notice - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.