Internet Domain Routing S. Chakrabarti Internet-Draft IP Infusion - An Access Company Intended status: Standards Track July 7, 2008 Expires: January 9, 2009 AS4-specific RD/RT/SOO Capability exchange draft-chakrabarti-idr-as4-route-cap-01.txt Status of this Memo 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." 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. This Internet-Draft will expire on January 9, 2009. Abstract RFC 4893 defines BGP support for four-octet AS number space for handling AS_PATH attributes and "My ASN" value in BGP OPEN messages. Foue-Octet AS specific Extended Community attribute formats are defined in draft-rekhter-as4octet-ext-community-03.txt. However, an implementation compliant to RFC 4893 does not necessarily provide support for 4-Octet Route-distinguisher, Route-target or Site-of- origin in the BGP-MPLS-VPN. Thus BGP capability exchange for extended AS number attribute does not cover the BGP-MPLS-VPN AS4- specific route-attributes and route-distinguishers. This document proposes an optional BGP capability exchange between the Provider Edge (PE) routers in order to communicate the intention of handling 4-Octet or 2-Octet exteneded AS-specific Route-targets or Site-of- Chakrabarti Expires January 9, 2009 [Page 1] Internet-Draft AS4-specific PE-Route Capability July 2008 Origins or being able to handle and inteprete the 4-Octet route- distinguishers correctly. This capability parameter will be part of OPEN message during the BGP session initiation. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Use BGP Capability advertisement . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 7. Normative References . . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . . . 7 Chakrabarti Expires January 9, 2009 [Page 2] Internet-Draft AS4-specific PE-Route Capability July 2008 1. Requirements notation 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]. 2. Introduction RFC 4893[AS4PATH] defines BGP support for four-octet AS number space for handling AS_PATH attributes and "My ASN" value in BGP OPEN messages. Foue-Octet AS specific Extended Community attribute formats are defined in [AS4-EXTCOM]. However, an implementation compliant to RFC 4893[AS4PATH] does not necessarily provide support for 4-Octet Route-distinguisher, Route-target or Site-of-origin in the BGP-MPLS-VPN. Thus BGP capability exchange for extended AS number attribute does not cover the BGP-MPLS-VPN AS4-specific route- attributes and route-distinguishers. This document proposes an optional BGP capability exchange between the Provider Edge (PE) routers in order to communicate the intention of handling 4-Octet or 2-Octet exteneded AS-specific Route-targets or Site-of-Origins or being able to handle and inteprete the 4-Octet route-distinguishers correctly. This capability parameter will be part of OPEN message during the BGP session initiation. Provider Edge (PE) rotuers [BGP-MPLS] are normally configured with Route-distinguishers (RD), Route-targets(RT). RFC 4364 [BGP-MPLS] states that a PE router may assign a Site Of origin in order to prevent routing loops when CEs use private non-unique AS numbers. In the following diagram, PE1 and PE2 belong to the same autonomous system. But they may run two different vendors' implementations. Even though both PEs can be compliant to RFC 4893, it is possible that they may not support 4-Octet AS specific Route-target(RT) or Route-distinguishers(RD) at the same time. The capability exchange on handling 4-octet AS-specific Route-target, Route distinguishers and Site Of Origin is needed for two PEs to interoperate efficiently in interpreting each-other's route-attributes and RDs in a VPN-IPv4 or VPN-IPv6 prefixes. So far, the Route-target and Site Of Orgin are used as extended community attributes with 2byte AS number format, thus static configurations on different PEs were sufficient. With the introduction of 4-Octet AS specific extended communities [AS4-EXTCOM] and 4-Octet AS specifc RDs [BGP-MPLS], static configurations in different PEs are not enough; if one does not support the 4-octet RT for example, it the other expects 4-Octet RTs the sessions will be reset in the middle of the session and routing outage will take place. This capability negotiation will be also useful for inter-AS BGP-MPLS-VPN scenario option C. This document Chakrabarti Expires January 9, 2009 [Page 3] Internet-Draft AS4-specific PE-Route Capability July 2008 introduces a new capability message for BGP-MPLS-VPN scenarios for handling OLD and NEW implementations which support extended AS- specific routing attributes. The following sections will detail the format of AS-specifc routing capability messages. ------------ ------------- ----- ------------- ------- | | | | | | | | | | | CE1 |-----| PE1 |-----| P |--| PE2 |--------| CE2 | | | | | | | | | | | ------------ ------------- ------- ------------- -------- rd = 200:300 rd = 200:300 rt = 200:300 (export/import ) rt = 200:300 (export/import) (2byte format) (4byte format) configured configured A problem scenario with PEs supporting 2byte and 4byte AS-specific ext-communities 3. Terminology OLD implementation: A BGP speaker which is RFC 4364[BGP-MPLS] compliant and does not implement 4byte extension to the AS number as defined in RFC 4893 or it implements RFC 4893, but does not implement AS4-specific extended RT, SOO communities or 4-octet AS specific RDs. NEW implementation: A BGP speaker which implements the 4-byte AS number support as defined in RFC 4893 and it supports As4-specific extended communities [AS4-EXTCOM] 4. Use BGP Capability advertisement The AS-specific routing capability message will be used during OPEN message as defined in RFC 4271. This capability message SHOULD be used in conjuction with Extended AS capability message defined in RFC 4893. The fields in the Capabilities Optional Parameter are set as follows. The Capability type Code field is TBD (to be assigned by IANA). The Capability Length field is set to 2. The Capability Value field is defined as: Chakrabarti Expires January 9, 2009 [Page 4] Internet-Draft AS4-specific PE-Route Capability July 2008 The use and meaning of this field is as follow: 0 7 15 +-------+-------+-------+-------+ | Resvd | |D|S|R| Resvd | RT-val| +-------+-------+-------+-------+ Resvd - These 4 bits are reserved for future use D - If D bit is on the implementation sends and receives 4-octet AS-specific RD format S - If S bit is on, then implementation sends and receives 4-octet AS-specific Site Of Origin attributes along with the VPN routes R - If R bit is on, the implementation is able to send and receive 4-octet AS specific RT format RT-val - If this value is 1, the PE is able to export 4-octet AS- specific RTs; if this value is 2 the PE is able to import 4-octet AS-specific RT attributes. When the value is 3, the implementation is able to handle As4-specific RT extended community attributes for both export and import. Please note that a NEW implementation supporting the above capabilities SHOULD be able to optionally support 2-octet AS-specific RD, RT and Site of origin attributes as per the local configuration. The NEW implementation is not capable of converting the 2-octet AS specific to 4-octet AS specific attributes for a given route. 5. IANA Considerations This document requests a BGP capability type code from IANA. 6. Acknowledgements 7. Normative References [AS4PATH] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS Number Space", RFC 4893, May 2007. [BGP-MPLS] Rekhter, Y. and E. Rosen, "BGP/MPLS IP Virtual Private Networks", RFC 4364, February 2006. [AS4-EXTCOM] Rekhter, Y., Sangli, S., and D. Tappan, "Four-octet AS Specific BGP Extended Community", Chakrabarti Expires January 9, 2009 [Page 5] Internet-Draft AS4-specific PE-Route Capability July 2008 draft-rekhter-as4octet-ext-community-03.txt (work in progress), April 2008. [BGP-4] Rekhter, Y., Li, T., and S. Hares, "Border Gateway Protocol 4", RFC 4271, January 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Author's Address Samita Chakrabarti IP Infusion - An Access Company 1188 Arques Avenue Sunnyvale, CA USA Email: samitac@ipinfusion.com Chakrabarti Expires January 9, 2009 [Page 6] Internet-Draft AS4-specific PE-Route Capability July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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, THE IETF TRUST 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. Intellectual Property 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 on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at 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. Chakrabarti Expires January 9, 2009 [Page 7]