Network Working Group X. Xu Internet-Draft M. Chen Intended status: Standards Track Huawei Expires: July 27, 2014 January 23, 2014 Address Prefix Based VPN Route Distribution Constrain draft-xu-l3vpn-prefix-constrain-00 Abstract This document defines MP-BGP procedures that allow BGP speakers to exchange VPN route interest information. This information can be used to control VPN route distribution at the granularity of address prefix, which is applicable in the context of Virtual Subnet and may also be applicable in other BGP/MPLS IP VPN environments. 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/. 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 July 27, 2014. Copyright Notice Copyright (c) 2014 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. Xu & Chen Expires July 27, 2014 [Page 1] Internet-Draft January 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. VPN Route Interest Advertisement . . . . . . . . . . . . . . 3 4. Capability Advertisement . . . . . . . . . . . . . . . . . . 4 5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 9.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction The Route Target Contrain mechanism defined in [RFC4684] allows a BGP speaker to control VPN route distribution by using the received Route Target membership information. However, in some network environments where the amount of VPN routes is too large, it's usually expected to control the VPN route distribution at a finer granulurity (e.g., VPN address prefix). In other word, it's expected to support the pull- mode for VPN route distribution at a finer granurility. This document builds on the concept of on-demand VPN route distribution asdescribed in [RFC4684] and defines new procedures that allow BGP speakers to exchange VPN route interest information. This information can be used to control VPN route distribution at the granularity of address prefix. This fine-grained VPN route distribution control is applicable in the context of Virtual Subnet [I-D.xu-l3vpn-virtual-subnet] and may also be applicable in other BGP /MPLS IP VPN [RFC4364] environments. 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 [RFC2119]. 2. Terminology This memo makes use of the terms defined in [RFC2858] and [RFC4364]. Xu & Chen Expires July 27, 2014 [Page 2] Internet-Draft January 2014 3. VPN Route Interest Advertisement VPN Route Interest NLRI is advertised in BGP UPDATE messages using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC2858]. The [AFI, SAFI] value pair for VPNv4 Route Interest NLRI is (AFI=1, SAFI=TBD1), and the [AFI, SAFI] value pair for VPNv6 Route Interest NLRI is (AFI=2, SAFI=TBD1). The Next Hop field of MP_REACH_NLRI attribute shall be interpreted as an IPv4 address whenever the length of NextHop address is 4 octets, and as a IPv6 address whenever the length of the NextHop address is 16 octets. The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI contains the IPv4 or IPv6 address prefix part of a VPN address prefix which is interesting to the originator of such NLRI. In other word, the Route Distinguisher (RD) part of that VPN address prefix is not contained. A Route Target extended community is attached to the NLRI to indicate the VPN instance that the above IPv4 or IPv6 address prefix belongs to. In order to restrict the propagation scope of VPN route interest information, the VPN Route Interest NLRI containning a VPN route of a particular VPN SHOULD only be propagated to those BGP peers which maintain routes for that VPN. That's to say, the exact propagation of the VPN Route Interest NLRI is built upon the discovery of the export Route Target membership Information. Note that the export Route Target membership information here is different from the (import) Route Target membership information as described in [RFC4684], since the former expresses the semantic of "I have VPN routes associated with a particular Route Target" while the latter expresses the semantic of "I want VPN routes associated with a particular Route Target". To disthguish them from each other, the export Route Target membership information SHOULD be conveyed in a different NLRI (AFI=1, SAFI=TBD2) other than that (AFI=1, SAFI=132) for conveying the (import) Route Target membership information. The advertisement procedure for export Route Target membership information is the same as that for the (import) Route Target membership information except that the former is used for controlling the propagation of VPN Route Interest NLRIs while the latter is used for controlling the propagation of VPN routes. Of course, the export Route Target membership informaiton can also be used to control the propagation of the (import) Route Target membership information if desired. In this way, the (import) Route Target membership information expressing the semantic of "I want VPN route of a given Route Target X" would only be propagated to those BGP peers who have indicated that they have VPN routes for Route Target X by advertising the export Route Target membership information. A VPN Route Interest NLRI SHOULD only be advertised to a peer that participates in the exchange of VPN route interest information if that peer has advertised either the default export Route Target Xu & Chen Expires July 27, 2014 [Page 3] Internet-Draft January 2014 membership NLRI or a export Route Target membership NLRI containing any of the targets contained in the extended communities attribute of the VPN route interest NRLI in question. In other word, the export Route Target membership information is used to restrict the distribution of the VPN route interest information (at the Route Target granularity) which in turn is used to control the VPN route distribution (at the address prefix granularity). The address prefix-based VPN route distribution control based upon the VPN Route Interest NRLIs could be used together with the Route Target-based route distribution control based upon the (import) Route Target Membership NLRIs. For instance, a BGP speaker may want its peer to send all routes for VPN red and some particular routes for VPN blue. It is NOT RECOMMENDED to propagate a VPN Route Interest NLRI associated with a given Route Target towards a peer to whom an "import" Route Target membership NLRI containing the said Route Target has been sent before. 4. Capability Advertisement A BGP speaker that wishes to exchange VPN Route Interest information MUST use the Multiprotocol Extensions Capability Code, as defined in [RFC2858], to advertise the corresponding (AFI, SAFI) pair. Since the exact propagation of the VPN Route Interest Information depends on the pre-progagation of the export Route Target membership Information, the Capability for the export Route Target membership NLRI (AFI=1, SAFI=TBD2) MUST be supported as a prerequisite. 5. Operations A VPN route SHOULD be advertised to a peer that participates in the exchange of VPN route interest information if that peer has advertised a VPN Route Interest NLRI containing the the same IPv4 or IPv6 address prefix as that of the VPN route in question and the Route Target of that VPN route is the same as the Route Target associated with that VPN Route Interest NLRI. Note that here the RD part of the VPN route SHOULD be ignored when performing the VPN route search. When a BGP speaker receives a BGP UPDATE that advertises or withdraws a given VPN Route Interest NLRI, it SHOULD examine the RIB- OUTs of VPN NLRIs and re-evaluate the advertisement status of routes that match the VPN Route Interest NLRI in question. A BGP speaker SHOULD generate the minimum set of BGP VPN route updates (advertisements and/or withdrawls) necessary to transition between the previous and current state of the route distribution graph that is derived from VPN Route Interest information. As a hint that initial VPN Route Interest Information exchange is complete, implementations SHOULD generate an End-of-RIB marker, as defined in [RFC4724], for the VPN Route Interest information (AFI=1 or 2, SAFI=TBD1), regardless of whether graceful-restart is enabled on the Xu & Chen Expires July 27, 2014 [Page 4] Internet-Draft January 2014 BGP session. This allows the receiver to know when it has received the full contents of the peer's VPN Route Interest information. The exchange of VPN NLRI SHOULD follow the receipt of the End-of-RIB markers. If a BGP speaker chooses to delay the advertisement of BGP VPN route updates until it receives this End-of-RIB marker, it MUST limit that delay to an upper bound. By default, a 60 second value SHOULD be used. Similarly, the exchange of VPN Route Interest NLRI SHOULD folow the receipt of the End-of-RIB markers for the export Route Target Membership NLRI (AFI=1, SAFI=TBD2). 6. Acknowledgements The authors would like to thank ... for their comments on this document. 7. IANA Considerations The SAFI codes for VPNv4 and VPNv6 Route Interest needs to be assigned respectively by the IANA. 8. Security Considerations This document does not introduce any new security risk to the BGP/ MPLS IP VPN. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. [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. [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, January 2007. Xu & Chen Expires July 27, 2014 [Page 5] Internet-Draft January 2014 9.2. Informative References [I-D.xu-l3vpn-virtual-subnet] Building, K., Hares, S., Yongbing, F., Jacquenet, C., Boyes, T., and B. Fee, "Virtual Subnet: A L3VPN-based Subnet Extension Solution", draft-xu-l3vpn-virtual- subnet-02 (work in progress), November 2013. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. Authors' Addresses Xiaohu Xu Huawei Email: xuxiaohu@huawei.com Mach Chen Huawei Email: mach.chen@huawei.com Xu & Chen Expires July 27, 2014 [Page 6]