Inter-Domain Routing S. Ray Internet-Draft A. Sreekantiah Intended status: Standards Track Cisco Systems, Inc. Expires: August 18, 2014 February 14, 2014 Signaling AFI-SAFI scope for Constrained Route Distribution draft-ray-idr-route-constrain-scope-00 Abstract The Route Constrain address family can be used by a BGP speaker to signal a neighbor its interest in receiving only the routes with a matching route target (RT) extended community. This signaling is afi-safi agnostic; the sender of a route constrain NLRI with an RT expresses its interest in receiving routes with that RT for all afi- safi. The ability to further scope a given RT to a list of afi-safi would simplify network operations; then optimal route filtering would no longer require that the set of RTs used for different afi-safi be disjoint. This document proposes a simple extended community based backward compatible method to associate the list of afi-safi of interest to a route constrain NLRI and discusses the operational procedure. 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 August 18, 2014. Ray & Sreekantiah Expires August 18, 2014 [Page 1] Internet-Draft Signaling AFI-SAFI scope with RT Constrain February 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Sub-optimality of route constrain in shared RT deployments . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.1. Unused route advertisement and retention . . . . . . 3 1.1.2. Need for route-refresh on some configuration changes 4 1.2. Solutions . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2.1. Use of disjoint set of RTs . . . . . . . . . . . . . 5 1.2.2. New route constrain NLRI . . . . . . . . . . . . . . 5 1.2.3. Using BGP Path Attribute . . . . . . . . . . . . . . 5 2. AFI-SAFI Extended Community . . . . . . . . . . . . . . . . . 6 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. Manageability Considerations . . . . . . . . . . . . . . . . 10 5.1. Configuration Management . . . . . . . . . . . . . . . . 10 5.2. Operational Considerations . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction A VPN route (such as VPNv4/VPNv6 unicast [RFC4364], Multicast VPN [RFC6513], Layer 2 VPN [RFC6624], Flow-spec [RFC5575], etc.) is retained by a BGP speaker only if the route is of interest to itself - e.g., if the route belongs to a local VPN, or if it needs to be sent to one of its neighbors. The VPN membership of a route is determined by the set of route target (RT) extended communities attached to the route. Therefore the speaker's neighbors need to Ray & Sreekantiah Expires August 18, 2014 [Page 2] Internet-Draft Signaling AFI-SAFI scope with RT Constrain February 2014 send only those routes to the speaker that carry one or more RTs that are of interest to the speaker. [RFC4684] defines a new address family called Route Target Constrain (RTC) using which a BGP speaker can signal its neighbors the set of RTs it is interested in. For instance, if one of speaker A's locally configured VPNs is a member of RT:1:1 (i.e., if a local VRF imports RT:1:1), then speaker A advertises an RTC NLRI with RT:1:1 to speaker B. In turn speaker B sends to speaker A only the VPN routes with RT:1:1. [I-D.ietf-idr-bgp-ipv6-rt-constrain] extends the NLRI definition to accommodate longer IPv6 Specific Route Target extended communities [RFC5701]. The scope of an RTC NLRI RT:X:Y spans all address family routes with RT:X:Y. This design choice makes RTC a standard route filtering mechanism for all BGP based VPN solutions. On the flip side, RTC can deliver optimal filtering only when the set of RTs used by an address family afi=x/safi=y is disjoint from the set of RTs used by any other address family afi=z/safi=w. The following section illustrates some of the problems when shared RTs are used. 1.1. Sub-optimality of route constrain in shared RT deployments 1.1.1. Unused route advertisement and retention +-------------+---+ +---+-------------+ |IPv4 VRF | | RTC:1:1 +---+ RTC:1:1 | |IPv4 VRF | |export RT:1:1| |<---------------| | <------------ | |import RT:1:1| +-------------| A +----------------+ B +---------------+ C |-------------+ |IPv6 VRF | |--------------->| | ------------> | | |export RT:1:1| | VPNv4 unicast +---+ VPNv4 unicast | | +-------------+---+ VPNv6 unicast VPNv6 unicast +---+ Figure 1: Sub-optimality: Unused route advertisement and retention Suppose speaker A has local VPNv4 unicast and VPNv6 unicast routes, both with membership in RT:1:1. Speaker B is a route-reflector with client speaker C. Speaker C only needs VPNv4 unicast routes with RT:1:1 for its VPN with membership in RT:1:1. Speaker C sends an RTC NLRI RT:1:1 to speaker B and speaker B in turn sends an RTC NLRI RT:1:1 to speaker A. Spearker A sends its VPNv4 unicast and VPNv6 unicast routes with RT:1:1 to speaker B. Speaker B retains routes from both address families and sends all of them to speaker C. Speaker C retains only the VPNv4 unicast routes and drops VPNv6 unicast routes. Ray & Sreekantiah Expires August 18, 2014 [Page 3] Internet-Draft Signaling AFI-SAFI scope with RT Constrain February 2014 In this deployment, advertisement of VPNv6 unicast routes are not needed, but they are still advertised. Second, speaker B (the route- reflector) does not need to retain any VPNv6 unicast route since its only client, speaker C, does not need them. But speaker B still retains the VPNv6 unicast routes. Therefore, route constrain does not lead to optimal route filtering. 1.1.2. Need for route-refresh on some configuration changes RTC:1:1 +-------------+---+ RTC:1:1 +---+-------------+ |IPv4 VRF | | +---+ | |IPv4 VRF | |export RT:1:1| | | | | |import RT:1:1| +-------------| A +----------------+ B +---------------+ C |-------------+ |IPv6 VRF | | | | | |IPv6 VRF . |export RT:1:1| | +---+ | |import RT:1:1. +-------------+---+ VPNv4 unicast +---+.............+ VPNv6 unicast VPNv4 unicast Figure 2: Sub-optimality: Route refresh In the deployment shown in Figure 1, in steady state speaker C retains the VPNv4 unicast routes for RT:1:1 and speaker B has an RTC NLRI path for RT:1:1 from speaker C. Now suppose the operator adds a new IPv6 VRF on speaker C that imports RT:1:1 depicted in Figure 2. Now speaker C needs to get the VPNv6 unicast routes from speaker B with RT:1:1. At this point, if speaker C advertises the RTC NLRI RT:1:1 to speaker B again, speaker B would receive an identical path from speaker C. Standard BGP implementation practice is to ignore identical updates (i.e., not mark the local prefix for further processing), in which case speaker B will not send the VPN routes to speaker C again. Thus, speaker C would need to send a route refresh message to speaker B and receive all VPNv6 routes (this set of routes is larger than necessary if RT:1:1 is not the first RT imported by an IPv6 VRF on speaker C). There are possible implementation tricks to get around this issue (e.g., readvertise the RTC NLRI RT:1:1 from speaker C after changing an attribute such as local-preference). However, a standardized solution without possible side-effects is much more preferable. 1.2. Solutions Ray & Sreekantiah Expires August 18, 2014 [Page 4] Internet-Draft Signaling AFI-SAFI scope with RT Constrain February 2014 1.2.1. Use of disjoint set of RTs Not using shared RTs by ensuring that the set of RTs used by one address family is disjoint from the set of RTs used by any other address family avoids the problems. However, this constraint poses a burden on the network operation, especially in large networks that are run by multiple loosely coupled departments, where configurations change frequently. Therefore, a protocol level solution is more preferable. 1.2.2. New route constrain NLRI [I-D.dong-idr-vpn-route-constrain] proposes a new NLRI format that includes the safi value (among other fields) and use different afi values during capability negotiations. This is not a backward compatible solution. Given many existing (large) deployments of [RFC4684] based multi-vendor networks, backward compatibility is necessary. In addition, [I-D.ietf-idr-bgp-ipv6-rt-constrain] solves the IPv6 specific RT issue in a backward compatible manner that [I-D.dong-idr-vpn-route-constrain] addresses. 1.2.3. Using BGP Path Attribute The list of afi-safi that a speaker needs in the scope for a given RT can be carried in the path attribute of the RTC NLRI. This approach does not require any change in the NLRI format as the new information is not carried in the NLRI making the approach backward compatible. In addition, RTC being a hop-by-hop technique by nature, best path selection done on, say, a route-reflector, does not lead to missing information. In this document, we adopt this approach which leads to a light-weight, backward compatible solution. In addition, if the policy language supported on the BGP speakers allow attaching arbitrary extended communities to a route, then the proposed solution can be deployed on edge routers (i.e., on leafs of the VPN distribution graph) even without any software upgrade. While one could define a new BGP path attribute to carry the list of afi-safi as the scope, use of communities suffices for the present purpose. Specifically, we propose using a new type of opaque extended community called AFI-SAFI extended community to encode each afi-safi pair that is of interest to the speaker and use multiple extended communities to form the list. Extended communities instead of standard communities are used since the latter are used widely by the providers for communicating internal information. Ray & Sreekantiah Expires August 18, 2014 [Page 5] Internet-Draft Signaling AFI-SAFI scope with RT Constrain February 2014 2. AFI-SAFI Extended Community The AFI-SAFI Community is an Non-Transitive Opaque Extended Community ([RFC4360], [I-D.ietf-idr-extcomm-iana]) defined as follows: Type Field: The value of the high-order octet of the extended Type Field is 0x43, which indicates that it is non-transitive. The value of low-order octet of the extended type field for this community is TBD. Value Field: The first 3 octets of the Value field contains two sub-fields, described below. The last 3 octets of the Value field are reserved. The originator of an AFi-SAFI community must set the reserved octets to 0, and a receiver of an AFi-SAFI community must ignore the reserved octets. +--------------------------------------------------+ | Address Family Identifier (2 octets) | +--------------------------------------------------+ | Subsequent Address Family Identifier (1 octet) | +--------------------------------------------------+ | Reserved (3 octets) | +--------------------------------------------------+ Figure 3: AFI-SAFI Extended Community Format We denote an AFI-SAFI extended community with Address Family Identifier field x and Subsequent Address Family Identifier field y as AFI-SAFI-EC:(x/y). A route carrying AFI-SAFI-EC:(x/y) implies that the route is correlated to the address family with index x/y. The route itself may belong to a different address family. The semantics of the correlation is context dependent. This document defines the correlation sematics for route constrain routes carrying AFI-SAFI-EC. 3. Operation Suppose BGP speakers A and B have negotiated route constrain capability. Speaker A receives an RTC NLRI RT:X:Y from speaker B with set S of AFI-SAFI-EC attached. We define the following semantics: Ray & Sreekantiah Expires August 18, 2014 [Page 6] Internet-Draft Signaling AFI-SAFI scope with RT Constrain February 2014 o If S is empty, then speaker A SHOULD send all otherwise eligible routes from all address families to speaker B. o If S is nonempty, then speaker A SHOULD send an otherwise eligible AFI=x/SAFI=y route with RT:X:Y to speaker B ONLY if S contains AFI-SAFI-EC:(x/y). o Suppose speaker A has RTC route RT:X:Y with path i with AFI-SAFI- EC set S_i, for i=1..n. * If all S_i are nonempty, then speaker A attaches AFI-SAFI-EC set S to RTC NLRI RT:X:Y that it advertises to its neighbors, where S is the union of S_i, i=1..n. * If there is an empty S_i, then speaker A does not attach any AFI-SAFI-EC to RTC NLRI RT:X:Y that it advertises to its neighbors. The essential idea is to treat an RTC NLRI path with no AFI-SAFI-EC attached as a path with AFI-SAFI-EC for all address families attached. We illustrate the rules with a couple of examples shown in Figure 4 and Figure 5. Ray & Sreekantiah Expires August 18, 2014 [Page 7] Internet-Draft Signaling AFI-SAFI scope with RT Constrain February 2014 RTC:1:1 EC: 2/128 +---+ <------------- | | +----------------+ C | | -------------> | | | VPNv6 +---+ | | RTC:1:1 RTC:1:1 v EC: 1/128 +-------+ (No AFI-SAFI extcomm) +---+ EC: 2/128 +---+ | VPNv4 | <---------------------- | |<------------ | | | VPNv6 +-------------------------+ B +--------------+ D | | MVPN | ----------------------> | |------------->| | +-------+ VPNv4, VPNv6, MVPN +---+ VPNv4, VPNv6 +---+ Router A ^ | | RTC:1:1 |(No AFI-SAFI EC)+---+ | <------------- | | +----------------+ E | -------------> | | VPNv4, VPNv6, MVPN +---+ Figure 4: Operational rule in asymmetric cases In Figure 4, speaker B receives RTC NLRI RT:1:1 from neighbors C, D and E. Neighbor C attaches AFI-SAFI-EC:(2/128) and neighbor D attaches AFI-SAFI-EC:(1/128) and AFI-SAFI-EC:(2/128). Neighbor E does not attach any AFI-SAFI-EC to its route. From the received set of AFI-SAFI-EC, speaker B knows that among all the routes with RT:1:1, speaker C needs only VPNv6 unicast routes and speaker D needs only VPNv4 unicast and VPNv6 unicast routes. However, speaker B does not know which address family routes node E needs. Therefore, speaker B must request routes with RT:1:1 for all address families (whose capabilities have been negotiated) from its neighbors. So speaker B advertises RTC NLRI RT:1:1 to speaker A with no AFI-SAFI-EC. Speaker A has VPNv4 unicast, VPNv6 uncast and MVPN routes with RT:1:1 that are eligible for sending to speaker B. Speaker A sends all those routes to speaker B. Speaker B now has VPNv4 unicast, VPNv6 uncast and MVPN routes with RT:1:1 that are eligible for sending to neighbors C, D and E. Among those routes, speaker B sends only the VPNv6 unicast routes to neighbor C, VPNv4 unicast and VPNv6 unicast routes to neighbor D and Ray & Sreekantiah Expires August 18, 2014 [Page 8] Internet-Draft Signaling AFI-SAFI scope with RT Constrain February 2014 VPNv4 unicast, VPNv6 unicast and MVPN (i.e., all) routes to neighbor E. If speaker E actually only needs VPNv4 unicast routes, it would drop the VPNv6 unicast and MVPN routes it receives from speaker B for RT 1:1. This sub-optimal behavior improves when speaker E also uses AFI-SAFI-EC to signal the scope for RT:1:1 and the "island" of contiguous AFI-SAFI-EC users expands. RTC:1:1 EC: 2/128 +---+ <------------- | | +----------------+ C | | -------------> | | | VPNv6 +---+ | | RTC:1:1 RTC:1:1 v EC: 1/128 +-------+ EC: 1/128, EC: 2/128 +---+ EC: 2/128 +---+ | VPNv4 | <---------------------- | |<------------ | | | VPNv6 +-------------------------+ B +--------------+ D | | MVPN | ----------------------> | |------------->| | +-------+ VPNv4, VPNv6 +---+ VPNv4, VPNv6 +---+ Router A ^ | | RTC:1:1 | EC: 1/128 +---+ | <------------- | | +----------------+ E | -------------> | | VPNv4 +---+ Figure 5: Operational rule in symmetric cases In Figure 5, speaker B receives RTC NLRI RT:1:1 from neighbors C, D and E. Neighbor C attaches AFI-SAFI-EC:(2/128), neighbor D attaches AFI-SAFI-EC:(1/128) and AFI-SAFI-EC:(2/128), and neighbor E attaches AFI-SAFI-EC:(1/128). From the received set of AFI-SAFI-EC, speaker B knows that among all routes with RT:1:1, speaker C needs only VPNv6 unicast routes, speaker D needs only VPNv4 unicast and VPNv6 unicast routes, and speaker E needs only VPNv4 unicast routes. Speaker B advertises RTC NLRI RT:1:1 to speaker A with AFI-SAFI-EC:(1/128) and AFI-SAFI-EC:(2/ 128), which is the union of all AFI-SAFI-EC from all paths of the RTC NLRI. Ray & Sreekantiah Expires August 18, 2014 [Page 9] Internet-Draft Signaling AFI-SAFI scope with RT Constrain February 2014 Speaker A therefore sends only VPNv4 unicast and VPNv6 unicast routes speaker B. Among those routes with RT:1:1 that speaker B has, speaker B sends only the VPNv6 unicast routes to neighbor C, VPNv4 unicast and VPNv6 unicast routes to neighbor D and only VPNv4 unicast routes to neighbor E. Therefore, when all speakers use AFI-SAFI-EC, optimal route filtering is restored even in shared RT deployments. 4. IANA Considerations This document requests assignment of a codepoint from the Non- Transitive Opaque Extended Community Sub-Types registry for AFI-SAFI extended community. 5. Manageability Considerations This section is structured as recommended in [RFC5706]. 5.1. Configuration Management TBD. 5.2. Operational Considerations TBD. 6. Security Considerations Procedures and protocol extensions defined in this document do not affect the BGP security model. See the 'Security Considerations' section of [RFC4271] for a discussion of BGP security. Also refer to [RFC4272] and [I-D.ietf-karp-routing-tcp-analysis] for analysis of security issues for BGP. 7. Acknowledgements TBD. 8. References 8.1. Normative References [I-D.ietf-idr-extcomm-iana] Rosen, E. and Y. Rekhter, "IANA Registries for BGP Extended Communities", draft-ietf-idr-extcomm-iana-02 (work in progress), December 2013. Ray & Sreekantiah Expires August 18, 2014 [Page 10] Internet-Draft Signaling AFI-SAFI scope with RT Constrain February 2014 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, January 2006. [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 8.2. Informative References [I-D.dong-idr-vpn-route-constrain] Li, Z., Dong, J., Ni, H., Chen, M., and G. Liu, "Constrained Route Distribution for BGP based Virtual Private Networks(VPNs)", draft-dong-idr-vpn-route- constrain-02 (work in progress), September 2010. [I-D.ietf-idr-bgp-ipv6-rt-constrain] Patel, K., Raszuk, R., Djernaes, M., Dong, J., and M. Chen, "IPv6 Extensions for Route Target Distribution", draft-ietf-idr-bgp-ipv6-rt-constrain-04 (work in progress), August 2013. [I-D.ietf-karp-routing-tcp-analysis] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP and MSDP Issues According to KARP Design Guide", draft-ietf-karp-routing-tcp-analysis-07 (work in progress), April 2013. [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. [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., and D. McPherson, "Dissemination of Flow Specification Rules", RFC 5575, August 2009. Ray & Sreekantiah Expires August 18, 2014 [Page 11] Internet-Draft Signaling AFI-SAFI scope with RT Constrain February 2014 [RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community Attribute", RFC 5701, November 2009. [RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, November 2009. [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", RFC 6513, February 2012. [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling", RFC 6624, May 2012. Authors' Addresses Saikat Ray Cisco Systems, Inc. 170, West Tasman Drive San Jose, CA 95134 US Email: sairay@cisco.com Arjun Sreekantiah Cisco Systems, Inc. 170, West Tasman Drive San Jose, CA 95134 US Email: asreekan@cisco.com Ray & Sreekantiah Expires August 18, 2014 [Page 12]