L3VPN Routing Working Group H. Jeng Internet-Draft AT&T Intended status: Standards Track R. Bonica Expires: March 19, 2014 Y. Rekhter Juniper Networks September 15, 2013 Covering Prefixes Outbound Route Filter for BGP-4 draft-bonica-l3vpn-orf-covering-prefixes-00 Abstract This document defines a new ORF-type, called the "Covering Prefixes ORF (CP-ORF)". The CP-ORF is applicable in the context of a Virtual Hub-and-Spoke VPN. It may also be applicable in other BGP/MPLS VPN environments. 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]. 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 March 19, 2014. Copyright Notice Copyright (c) 2013 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 Jeng, et al. Expires March 19, 2014 [Page 1] Internet-Draft ORF Shortest Conveing September 2013 (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. Table of Contents 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 2. CP-ORF Encoding . . . . . . . . . . . . . . . . . . . . . . . 3 3. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 4 4. Applicability In Virtual Hub-and-Spoke VPNs . . . . . . . . . 5 4.1. CP-ORF Clean-up . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 8. Normative References . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Problem Statement [RFC5291] provides a mechanism through which a BGP [RFC4271] speaker can send a set of Outbound Route Filters (ORFs) to a peer. The peer uses those ORFs to filter routing updates that it sends to the BGP speaker. The ORF mechanism allows the speaker to realize the "route pull" paradigm with BGP, where the speaker, on demand, can pull certain routes from the peer. This document defines a new ORF-type, called the "Covering Prefixes ORF (CP-ORF)". The CP-ORF is applicable in the context of a Virtual Hub-and-Spoke VPN [I-D.ietf-l3vpn-virtual-hub]. However, it may also be applicable in other BGP/MPLS VPN [RFC4364] environments. 1.1. Terminology This document uses the terms "Address Family Identifier (AFI)" and "Subsequent Address Family Identifier (SAFI)". In the context of this document, the meaning of these terms is the same as in [RFC4760]. This document also uses the terms "VPN IP default route"," V-hub" and "V-spoke". In the context of this document, the meaning of these terms is the same as in [I-D.ietf-l3vpn-virtual-hub]. Jeng, et al. Expires March 19, 2014 [Page 2] Internet-Draft ORF Shortest Conveing September 2013 2. CP-ORF Encoding [RFC5291] augments the BGP ROUTE-REFRESH message so that it can carry ORF entries. When the ROUTE-REFRESH message carries ORF entries, it includes the following fields: o AFI o SAFI o When-to-refresh (IMMEDIATE or DEFERRED) o ORF Type o Length (of ORF entries) The ROUTE-REFRESH message also contains a list of ORF entries. Each ORF entry contains the following fields: o Action (ADD, REMOVE, or REMOVE-ALL) o Match (PERMIT or DENY) The ORF entry may also contain Type-specific information. Type- specific information is present only when the Action is equal to ADD or REMOVE. It is not present when the Action is equal to REMOVE-ALL. When the BGP ROUTE-REFRESH message carries CP-ORF entries, the following conditions must be true: o ORF Type MUST be equal to CP-ORF. (The value of CP-ORF is TBD. See Section 5 for details.) o AFI MUST be equal to either IPv4 or IPv6 o SAFI MUST be equal to "MPLS-labeled VPN address" [IANA.SAFI] o Match field MUST be equal to PERMIT Figure 1 depicts the encoding of the CP-ORF type-specific information. +--------------------------------+ | Sequence (32 bits) | +--------------------------------+ | VPN Route Target (64 bits) | +--------------------------------+ | Import Route Target (64 bits) | Jeng, et al. Expires March 19, 2014 [Page 3] Internet-Draft ORF Shortest Conveing September 2013 +--------------------------------+ | Host Address (32 or 128 bits) | +--------------------------------+ Figure 1: CP-ORF Type-specific Encoding The Sequence field specifies the relative ordering of the entry among all CP-ORF entries. The VPN Route Target field is used by the recipient of CP-ORF to identify the set of routes to which CP-ORF applies. See Section 3 for details. The Import Route Target also is used by the recipient of CP-ORF. The CP-ORF recipient marks routes selected by CP-ORF with the value of the Route Target extended community before advertising them to the originator of the CP-ORF. See Section 3 for details. If the AFI field in the ROUTE-REFRESH message is equal to IPv4, the Host Address field MUST contain exactly 32 bits and MUST represent an IPv4 host address. If the AFI field in the ROUTE-REFRESH message is equal to IPv6, the Host Address field MUST contain exactly 128 bits and MUST represent an IPv6 host address. 3. Processing Rules When a BGP speaker receives a ROUTE-REFRESH message that contains a CP-ORF, and that ROUTE-REFRESH message that violates any of the encoding rules specified in Section 2, the BGP speaker MUST log the event and ignore the entire ROUTE-REFRESH message. Otherwise, the BGP speaker processes each CP-ORF entry as indicated by the Action field. If the Action is equal to ADD, the BGP speaker adds a CP-ORF entry in the position specified by the Sequence field. If the Action is equal to REMOVE, the BGP speaker removes a CP-ORF entry. If the Action is equal to REMOVE-ALL, the BGP speaker removes all CP-ORF entries. Whenever the BGP speaker advertises routes to a peer, it evaluates each route in terms of each CP-ORF entry received from that peer. A route matches the selection criteria of a CP-ORF if the following statements are true: o the route is more specific than a /64 (i.e., the route more specific than an IP VPN default route) o the route carries RT whose value is the same as the CP-ORF VPN Route Target Jeng, et al. Expires March 19, 2014 [Page 4] Internet-Draft ORF Shortest Conveing September 2013 o the route covers the CP-ORF Host Address When evaluating whether the route covers the CP-ORF Host Address, the BGP speaker ignores Route Distinguishers. For example, assume that the CP-ORF Host Address is equal to 192.0.2.1. Assume also that the RIB contains routes for the following IPv4 VPN prefixes, and that all of these routes carry an RT whose value is the same as the CP-ORF VPN Route Target: o 1:0.0.0.0/64. o 2:192.0.2.0/88 o 3:192.0.2.0/89 For the purposes of this search, 2:192.0.2.0/88 and 3:192.0.2.0/89 cover 192.0.2.1. This is because the search algorithm ignores Route Distinguishers. However, 1:0.0.0.0/64 does not cover 192.0.2.1, because the search algorithm requires a prefix length greater than / 64. If a route matches the selection criteria of a CP-ORF, the BGP speaker places the route into the Adj-RIB-Out associated with the peer from which CP-ORF was received. When placing the route into the Adj-RIB-Out, the speaker applies the following rules: o all BGP attributes except for Route Targets are unchanged o The Route Target specified by the CP-ORF Import Route Target is added to the list or Route Targets that the route already carries As a result of placing the route into the Adj-RIB-Out, the route is advertised to the peer. 4. Applicability In Virtual Hub-and-Spoke VPNs In a Virtual Hub-and-Spoke environment, VPN sites are attached to Provider Edge (PE) routers, V-hubs and V-spokes. PE routers, V-hubs and V-spokes can exchange VPN routes through an iBGP mesh. Alternatively, they can exchange customer routes using Route Reflectors (RR). For the purposes of this document, assume that RED-VPN sites are attached to PE routers, V-hub1 and V-spoke1. All of these devices advertise RED-VPN routes to a RR. They mark these routes with a route target, which we will call RT-RED. Jeng, et al. Expires March 19, 2014 [Page 5] Internet-Draft ORF Shortest Conveing September 2013 V-hub1 serves the RED-VPN. Therefore, V-hub1 advertises a VPN IP default route for the RED-VPN to the RR, carrying the route target RT-RED-FROM-HUB1. V-spoke1 establishes a BGP session with the RR, negotiating the CP- ORF capability, as well as the Multiprotocol Extensions Capability [RFC2858] . Upon establishment of the BGP session, the RR does not advertise any routes to V-spoke1. The RR will not advertise any routes until it receives either a ROUTE-REFRESH message or a BGP UPDATE message containing a Route Target Membership NLRI [RFC4684]. Immediately after the BGP session is established, V-spoke1 sends the RR a BGP UPDATE message containing a Route Target Membership NLRI. The Route Target Membership NLRI specifies RT-RED-FROM-HUB1 as its route target. In response to the BGP-UPDATE message, the RR advertises the VPN IP default route for the RED-VPN to V-spoke1. This route still carries the route target RT-RED-FROM-HUB1. V-spoke1 subjects this route to its import policy and accepts it because it carries the route target RT-RED-FROM-HUB1. Now, V-spoke1 begins normal operation, sending all of its traffic through V-hub1. At some point, V-spoke1 determines that it might benefit from a more direct route to a destination. (Criteria by which V-spoke1 determines that it needs a more direct route are beyond the scope of this document.) In order to discover a more direct route, V-spoke1 assigns a unique numeric identifier to the flow. V-spoke1 then sends a ROUTE-REFRESH message to the RR, containing the following information: o AFI is equal to IPv4 or IPv6, as appropriate o SAFI is equal to "MPLS-labeled VPN address" o When-to-refresh is equal IMMEDIATE o Action is equal to ADD o Match is equal to PERMIT o ORF Type is equal to CP-ORF o CP-ORF Sequence is equal to the identifier associated with the flow o CP-ORF VPN Route Target is equal to RT-RED o CP-ORF Import Route Target is equal to RT-RED-FROM-HUB1 Jeng, et al. Expires March 19, 2014 [Page 6] Internet-Draft ORF Shortest Conveing September 2013 o CP-ORF Host Address is equal the destination address associated with the flow Upon receipt of the ROUTE-REFRESH message, the RR must ensure that it carries all routes belonging to the RED-VPN. In at least one special case, where all of the RR clients are V-spokes and none of the RR clients are V-hubs, the RR will lack some or all of the required RED- VPN routes. So, the RR sends a BGP UPDATE message containing a Route Target Membership NLRI for VPN-RED to all of its peers. This causes the peers to advertise VPN-RED routes to the RR, if they have not done so already. Next, the RR installs the CP-ORF and refreshes routes for V-spoke1. If the RR maintains any routes matching the CP-ORF selection criteria, it advertises those routes. As it advertises those routes, it adds the CP-ORF Import Route Target to the list of route targets that they carry. The advertised routes may specify either V-hub1 or any other node as the NEXT-HOP. V-spoke1 subjects the advertised routes to its import policy and accepts them because they carry the route target RT-RED-FROM-HUB1. V-spoke1 may repeat this process whenever it discovers another flow that might benefit from a more direct route to its destination. 4.1. CP-ORF Clean-up Each CP-ORF consumes memory and compute resources on the device that supports it. Therefore, in order to obtain optimal performance, the V-spoke periodically evaluates all CP-ORFs that it has originated and removes unneeded CP-ORFs. The V-spoke determines that a CP-ORF is unneeded if its forwarding table includes no route satisfying the following criteria: o Covers the CP-ORF Host Address o Carries the same route target as the CP-ORF VPN Route Target o Has prefix length greater than 64 (i.e., is not a default route) o Has NEXT-HOP different from that of any VPN IP default route (i.e., different from any V-hub with which the V-Spoke is associated) When the V-spoke finds an unneeded CP-ORF, it removes the CP-ORF, as described below, and adds CP-ORF Host Address to a list of addresses known to be reachable only through the V-hub. The Host Address remains on that list for a configurable period of time. While the Jeng, et al. Expires March 19, 2014 [Page 7] Internet-Draft ORF Shortest Conveing September 2013 Host Address is on that list, flows directed toward it will not be considered as candidates for a more direct route. Also, the V-spoke removes all CP-ORFs when a configurable period of time has elapsed since their installation. When it does this, it does not add CP-ORF Host Address to the list of addresses known to be reachable only through a V-hub. If the V-spoke once again determines that a flow directed towards the Host Address might benefit from a more direct route, it will send another CP-ORF. In order to removed unneeded CP-ORFs, the V-spoke sends a single ROUTE Refresh message containing the following information: o AFI is equal to IPv4 or IPv6, as appropriate o SAFI is equal to "MPLS-labeled VPN address" o When-to-refresh is equal IMMEDIATE o Action is equal to REMOVE o Match is equal to PERMIT o ORF Type is equal to CP-ORF o A list of CP-ORFs, with one element representing each unneeded CP- ORF The recipient of this message responds to it as described in [RFC5291]. 5. IANA Considerations IANA is requested to assign a All Covering Prefixes ORF Type from the BGP Outbound Route Filtering (ORF) Types Registry. 6. Security Considerations Each CP-ORF consumes finite memory and compute resources on the control plane of the V-hub. Therefore, the V-hub MUST take the following steps to protect itself from oversubscription: o When negotiating the ORF capability, advertise willingness to receive the CP-ORF only to known, trusted iBGP peers o Enforce a per-peer limit on the number of CP-ORFs that can be installed at any given time. Ignore all requests to add CP-ORFs beyond that limit Jeng, et al. Expires March 19, 2014 [Page 8] Internet-Draft ORF Shortest Conveing September 2013 7. Acknowledgements The authors wish to acknowledge Han Nguyen and James Uttaro for their comments and contributions. 8. Normative References [I-D.ietf-l3vpn-virtual-hub] Jeng, H., Uttaro, J., Jalil, L., Decraene, B., Rekhter, Y., and R. Aggarwal, "Virtual Hub-and-Spoke in BGP/MPLS VPNs", draft-ietf-l3vpn-virtual-hub-08 (work in progress), July 2013. [IANA.SAFI] IANA, "abbrev="Subsequent Address Family Identifiers (SAFI) Parameters"", , . [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. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 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. [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. [RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering Capability for BGP-4", RFC 5291, August 2008. [RFC5292] Chen, E. and S. Sangli, "Address-Prefix-Based Outbound Route Filter for BGP-4", RFC 5292, August 2008. Authors' Addresses Jeng, et al. Expires March 19, 2014 [Page 9] Internet-Draft ORF Shortest Conveing September 2013 Huajin Jeng AT&T Email: hj2387@att.com Ron Bonica Juniper Networks 2251 Corporate Park Drive Herndon, Virginia 20170 USA Email: rbonica@juniper.net Yakov Rekhter Juniper Networks 1194 North Mathilda Ave. Sunnyvale, California 94089 USA Email: yakov@juniper.net Jeng, et al. Expires March 19, 2014 [Page 10]