L3VPN Working Group K. Patel Internet-Draft R. Raszuk Intended status: Standards Track Cisco Systems Expires: April 21, 2011 M. Djernaes Juniper Networks J. Dong M. Chen Huawei Technologies Co., Ltd. October 18, 2010 AFI Specific Route Target Distribution draft-keyur-bgp-af-specific-rt-constrain-00.txt Abstract The current route target distribution specification described in RFC4684 defines Route Target NLRIs of maxiumum length of 12 bytes. Furthermore, the current specification mandates that Route Targets exchanged using the current specification are applied towards filtering for all VPN applications that uses the notion of Route Target BGP extended communities. In particular, the same Route Target distribution mechanism is used to exchange VPNv4, VPNv6 and L2VPN prefixes. The IPv6 specific Route Target extended community is defined in RFC5701 as length of 20 bytes. Since the current specification only supports prefixes of maximum length of 12 bytes, the lack of an IPv6 specific Route Target reachability information may be a problem when an operator wants to use this application in a pure IPv6 environment. This document defines an extension to the current constrained route distribution specification that allows BGP speakers to distribute Route Target prefixes using multiple different Address Families thereby limiting the application of Route Target prefix filters to the specific address family under which it is advertised. Furtheremore, this document defines an extension that allows BGP to exchange longer length IPv6 Route Target prefixes. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Patel, et al. Expires April 21, 2011 [Page 1] Internet-Draft AFI Specific Route Target Distribution October 2010 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." This Internet-Draft will expire on April 21, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Patel, et al. Expires April 21, 2011 [Page 2] Internet-Draft AFI Specific Route Target Distribution October 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 4 2. BGP Constrained Route Target Capability . . . . . . . . . . . . 4 3. AFI specific Route Target NLRI Advertisements . . . . . . . . . 5 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Patel, et al. Expires April 21, 2011 [Page 3] Internet-Draft AFI Specific Route Target Distribution October 2010 1. Introduction The current constrained route distribution specification defined in [RFC4684] supports prefixes with a fixed maximum length of 12 bytes. Furthermore, the current specification mandates that the Route Targets exchanged using the current specification are applied towards filtering for all VPNv4, VPNv6, and L2VPN address families. This behavior needs to be modified for the following reasons: o The IPv6 specific Route Target extended community defined in [RFC5701] is 20 bytes in length. Since the current specification only supports prefixes of maximum length of 12 bytes, the lack of an IPv6 specific Route Target reachability information may be a problem when one wants to use this application in a pure IPv6 environment. o The behavior of applying filtering for all VPN address families (VPNv4, VPNv6 and L2VPN) is sub-optimal in cases where the operators want to assign common Route Targets and perform scoped filtering on an address family basis. This document defines an extension to the current constrained route distribution specification that allows BGP speakers to distribute Route Target prefixes using multiple different Adddress Families thereby limiting the application of Route Target filters to the specific address family under which it is advertised. Address families that do not exchange Route Target information using their own AFI and SAFI = 132 MUST always use AFI=1 and SAFI=132 to exchange their Route Targets and filter prefixes accordingly. Furthermore, Address families that do exchange the Route Target information using its own AFI and SAFI = 132 MUST override the Route Target information received in AFI=1 and SAFI=132. In this way, the current extension would preserve the backward compatibility with [RFC4684]. 1.1. Requirements Language 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 RFC 2119 [RFC2119]. 2. BGP Constrained Route Target Capability A BGP speaker that wishes to exchange Route Target membership information for any address family must use the Multiprotocol Extensions Capability Code, as defined in [RFC4760] section [5], to advertise the corresponding (AFI, SAFI) pair. Patel, et al. Expires April 21, 2011 [Page 4] Internet-Draft AFI Specific Route Target Distribution October 2010 The BGP IPv6 Constrained Route Target capability is a new BGP Capability [RFC5492] defined with Multiprotocol Extension Capability code with AFI=2 and SAFI=132. The BGP L2VPN Constrained Route Target capability is a new BGP Capability [RFC5492] defined with Multiprotocol Extension Capability code with AFI=25 and SAFI=132. By advertising these capabilities to a peer, a BGP speaker conveys to the peer that the speaker supports and can interpret appropriate address family based Route Target reachability information and the related procedures described in this document along with the procedures described in [RFC4684]. When not present, the current Constrained Route Target AFI=1 and SAFI=132 MUST apply to all the VPN address families that did not exchanged the Constrained AFI specific capability. Alternatively, the VPN address families that do successful negotiation of newly defined Constrained Route Target capabilities MUST override the Route Target information received in the Constrained Route Target Address family of AFI=1 and SAFI=132. In this way we make this specification fully backwards compatible with the existing deployments. 3. AFI specific Route Target NLRI Advertisements Route Target membership NLRI is advertised in BGP UPDATE messages using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes as defined in [RFC4760]. The [AFI, SAFI] value pair used to identify this NLRI is (AFI=X,SAFI=132) where X describes the address family to which Specific RT Constrained advertisement will apply. The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix of 0 to 24 octets, encoded as defined in Section 4 of [5] for all the constrain route distribution AFI/SAFI other than AFI = 1 and SAFI = 132. The valid NLRI length value for AFI = 1 and SAFI = 132 is defined in [RFC4684]. This prefix is structured as follows: Patel, et al. Expires April 21, 2011 [Page 5] Internet-Draft AFI Specific Route Target Distribution October 2010 +-------------------------------+ | origin as (4 octets) | +-------------------------------+ | route target (8 or 20 octets)| ~ ~ | | +-------------------------------+ Except for the default route target, which is encoded as a zero- length prefix, the minimum prefix length is 32 bits. As the origin- as field cannot be interpreted as a prefix. Route targets can then be expressed as prefixes, where, for instance, a prefix would encompass all route target extended communities assigned by a given Global Administrator [6]. The default route target can be used to indicate to a peer the willingness to receive all VPN route advertisements such as, for instance, the case of a route reflector speaking to one of its PE router clients. 4. Acknowledgements The authors would like to thank Pedro Marques, John Scudder and Alton Lo for discussions and review. 5. IANA Considerations This draft does not require any new allocations by IANA. In all address families constrained route target distribution will use the already allocated SAFI = 132. 6. Security Considerations This extension to [RFC4684] does not change the underlying security issues inherent in the existing BGP and [RFC4684]. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Patel, et al. Expires April 21, 2011 [Page 6] Internet-Draft AFI Specific Route Target Distribution October 2010 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., Patel, K., and J. Guichard, "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, November 2006. [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, February 2009. [RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community Attribute", RFC 5701, November 2009. 7.2. Informative References [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. Authors' Addresses Keyur Patel Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA Email: keyupate@cisco.com Robert Raszuk Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA Email: raszuk@cisco.com Patel, et al. Expires April 21, 2011 [Page 7] Internet-Draft AFI Specific Route Target Distribution October 2010 Martine Djernaes Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089 USA Email: mdjernaes@juniper.net Jie Dong Huawei Technologies Co., Ltd. KuiKe Building, No.9 Xinxi Rd. Hai-Dian District, Beijing 100085 P.R. China Email: dongjie_dj@huawei.com Mach(Guoyi) Chen Huawei Technologies Co., Ltd. KuiKe Building, No.9 Xinxi Rd. Hai-Dian District, Beijing 100085 P.R. China Email: mach@huawei.com Patel, et al. Expires April 21, 2011 [Page 8]