idnits 2.17.1 draft-ietf-idr-rtc-no-rt-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (January 5, 2015) is 3370 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group E. Rosen, Ed. 3 Internet-Draft Juniper Networks, Inc. 4 Intended status: Standards Track K. Patel 5 Expires: July 9, 2015 Cisco Systems, Inc. 6 J. Haas 7 Juniper Networks, Inc. 8 R. Raszuk 9 Mirantis Inc. 10 January 5, 2015 12 Route Target Constrained Distribution of Routes with no Route Targets 13 draft-ietf-idr-rtc-no-rt-00.txt 15 Abstract 17 BGP routes sometimes carry an "Extended Communities" path attribute. 18 An Extended Communities path attribute can contain one or more "Route 19 Targets" (RTs). By means of a procedure known as "RT Constrained 20 Distribution" (RTC), a BGP speaker can send BGP UPDATE messages that 21 express its interest in a particular set of RTs. Generally, RTC has 22 been applied only to address families whose routes always carry RTs. 23 When RTC is applied to such an address family, a BGP speaker 24 expressing its interest in a particular set of RTs is indicating that 25 it wants to receive all and only the routes of that address family 26 that have at least one of the RTs of interest. However, there are 27 scenarios in which the originator of a route chooses not to include 28 any RTs at all, assuming that the distribution of a route with no RTs 29 at all will be unaffected by RTC. This has led to interoperability 30 problems in the field, where the originator of a route assumes that 31 RTC will not affect the distribution of the route, but intermediate 32 BGP speakers refuse to distribute that route because it does not 33 carry any RT of interest. The purpose of this document is to clarify 34 the effect of the RTC mechanism on routes that do not have any RTs. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on July 9, 2015. 53 Copyright Notice 55 Copyright (c) 2015 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. Some Deployment Scenarios . . . . . . . . . . . . . . . . . . 4 72 3. Default Behavior . . . . . . . . . . . . . . . . . . . . . . 4 73 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 75 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 77 6.2. Informative References . . . . . . . . . . . . . . . . . 5 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 80 1. Introduction 82 A BGP route can carry a particular type of BGP path attribute known 83 as an "Extended Communities Attribute" [RFC4360]. Each such 84 attribute can contain a variable number of typed communities. 85 Certain typed communities are known as "Route Targets" (RTs) 86 ([RFC4360], [RFC4364]). 88 [RFC4684] defines a procedure, known as "RT Constrained Distribution" 89 (RTC) that allows a BGP speaker to advertise its interest in a 90 particular set of RTs. It does so by advertising "RT membership 91 information". (See [RFC4684] for details.) It may advertise RT 92 membership for any number of RTs. By advertising membership for a 93 particular RT, a BGP speaker declares that it is interested in 94 receiving BGP routes that carry that RT. 96 If RTC is enabled on a particular BGP session, the session must be 97 provisioned with the set of "address family" and "subsequent address 98 family" (AFI/SAFIs) values to which RTC is to be applied. In 99 [RFC4684] it is implicitly assumed that RTC will only by applied to 100 AFI/SAFIs where all the routes carry RTs. When this assumption is 101 true, the RTC semantics are clear. A BGP speaker advertising its 102 interest in RT1, RT2, ..., RTk is saying that, for the AFI/SAFIs to 103 which RTC is being applied, it is interested in any route that 104 carries at least one of those RTs, and it is not interested in any 105 route that does not carry at least one of those RTs. 107 However, [RFC4684] does not specify how the RTC procedures are to be 108 applied to address families whose routes sometimes carry RTs and 109 sometimes do not. Consider a BGP session between routers R1 and R2, 110 where R1 has advertised its interest in RT1, RT2, ..., RTk, and RTC 111 is being applied to a particular AFI/SAFI. Suppose R2 has a route of 112 that AFI/SAFI, and that route carries no RTs. Should R2 advertise 113 this route to R1 or not? 115 There are two different answers to this question, each of which seems 116 prima facie reasonable: 118 o No, R2 should not advertise the route, because it belongs to an 119 AFI/SAFI to which RTC is being applied, and the route does carry 120 any of the RTs in which R1 is interested. 122 o Yes, R2 should advertise the route; since the route carries no 123 RTs, the intention of the route's originator is that the 124 distribution of the route not be constrained by the RTC mechanism. 126 As might be expected, "one size does not fit all", and the best 127 answer depends upon the particular deployment scenario, and upon the 128 particular AFI/SAFI to which RTC is being applied. 130 Section 3 defines a default behavior for each existing AFI/SAFI. 131 This default behavior will ensure proper operation of that AFI/SAFI 132 when RTC is applied. The default behavior may of course be 133 overridden by a local policy. 135 Section 3 also defines a default "default behavior" for new AFI/ 136 SAFIs. When a new AFI/SAFI is defined, the specification defining it 137 may specify a different default behavior; otherwise the default 138 default behavior will apply. 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 142 "OPTIONAL" are to be interpreted as described in [RFC2119]. 144 2. Some Deployment Scenarios 146 There are at least three deployment scenarios where lack of a clearly 147 defined default behavior for RTC is problematic. 149 o [RFC6037] describes a deployed Multicast VPN (MVPN) solution. It 150 defines a BGP address family known as "MDT-SAFI". Routes of this 151 address family may carry RTs, but are not required to do so. In 152 order for the RFC6037 procedures to work properly, if an MDT-SAFI 153 route does not carry any RTs, the distribution of that route must 154 not be constrained by RTC. However, if an MDT-SAFI route does 155 carry one or more RTs, its distribution may be constrained by RTC. 157 o [GTM] specifies a way to provide "global table" (as opposed to 158 VPN) multicast, using procedures that are very similar to those 159 described in [RFC6513] and [RFC6514] for MVPN. In particular, it 160 uses routes of the MCAST-VPN address family that is defined in 161 [RFC6514]. When used for MVPN, each MCAST-VPN route carries at 162 least one RT. However, when used for global table multicast, it 163 is optional for certain MCAST-VPN route types to carry RTs. In 164 order for the procedures of [GTM] to work properly, if an MCAST- 165 VPN route does not carry any RTs, the distribution of that route 166 must not be constrained by RTC. 168 o Typically, Route Targets have been carried only by routes that are 169 distributed as part of a VPN service. However, it may be 170 desirable to be able to place RTs on non-VPN routes (e.g., on 171 unicast IPv4 or IPv6 routes) and then to use RTC to constrain the 172 delivery of the non-VPN routes. For example, if a BGP speaker 173 desires to receive only a small set of IPv4 unicast routes, and 174 the desired routes carry one or more RTs, the BGP speaker could 175 use RTC to advertise its interest in one or more of those RTs. In 176 this application, the intention would be that any IPv4 unicast 177 route not carrying an RT would be filtered. Note that this is the 178 opposite of the behavior needed for the other use cases discussed 179 in this section. 181 3. Default Behavior 183 In order to handle the use cases discussed in Section 3, this 184 document specifies a default behavior for the case where RTC is 185 applied to a particular address family (AFI/SAFI), and some (or all) 186 routes of that address family do not carry any RTs. 188 When RTC is applied, on a particular BGP session, to routes of the 189 MDT-SAFI address family (SAFI=66), the default behavior is that 190 routes that do not carry any RTs are distributed on that session. 192 When RTC is applied, on a particular BGP session, to routes of the 193 MCAST-VPN address family (SAFI=5), the default behavior is that 194 routes that do not carry any RTs are distributed on that session. 196 When RTC is applied, on a particular BGP session, to routes of other 197 address families, the default behavior is that routes without any RTs 198 are not distributed on that session. This default "default behavior" 199 applies to all AFI/SAFIs for which a different default behavior has 200 not been defined. 202 A BGP speaker may be provisioned to apply a non-default behavior to a 203 given AFI/SAFI. This is a matter of local policy. 205 4. IANA Considerations 207 This document contains no actions for IANA. 209 5. Security Considerations 211 No security considerations are raised by this document beyond those 212 already discussed in [RFC4684]. 214 6. References 216 6.1. Normative References 218 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 219 Requirement Levels", BCP 14, RFC 2119, March 1997. 221 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 222 Communities Attribute", RFC 4360, February 2006. 224 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 225 R., Patel, K., and J. Guichard, "Constrained Route 226 Distribution for Border Gateway Protocol/MultiProtocol 227 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 228 Private Networks (VPNs)", RFC 4684, November 2006. 230 6.2. Informative References 232 [GTM] Zhang, J., Giulano, L., Rosen, E., Subramanian, K., 233 Pacella, D., and J. Schiller, "Global Table Multicast with 234 BGP-MVPN Procedures", internet-draft draft-ietf-l3vpn- 235 mvpn-global-table-mcast-00, July 2014. 237 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 238 Networks (VPNs)", RFC 4364, February 2006. 240 [RFC6037] Rosen, E., Cai, Y., and IJ. Wijnands, "Cisco Systems' 241 Solution for Multicast in BGP/MPLS IP VPNs", RFC 6037, 242 October 2010. 244 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 245 VPNs", RFC 6513, February 2012. 247 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 248 Encodings and Procedures for Multicast in MPLS/BGP IP 249 VPNs", RFC 6514, February 2012. 251 Authors' Addresses 253 Eric C. Rosen (editor) 254 Juniper Networks, Inc. 255 10 Technology Park Drive 256 Westford, Massachusetts 01886 257 USA 259 Email: erosen@juniper.net 261 Keyur Patel 262 Cisco Systems, Inc. 263 170 Tasman Drive 264 San Jose, California 95134 265 US 267 Email: keyupate@cisco.com 269 Jeffrey Haas 270 Juniper Networks, Inc. 271 1194 N. Mathilda Ave. 272 Sunnyvale, California 94089 273 US 275 Email: jhaas@juniper.net 277 Robert Raszuk 278 Mirantis Inc. 279 615 National Ave. #100 280 Mountain View, California 94043 281 US 283 Email: robert@raszuk.net