idnits 2.17.1 draft-ietf-idr-rtc-no-rt-09.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 (Using the creation date from RFC4684, updated by this document, for RFC5378 checks: 2004-06-02) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 23, 2018) is 2192 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 (~~), 1 warning (==), 2 comments (--). 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 Updates: 4684 (if approved) K. Patel 5 Intended status: Standards Track Arccus 6 Expires: October 25, 2018 J. Haas 7 Juniper Networks, Inc. 8 R. Raszuk 9 Bloomberg LP 10 April 23, 2018 12 Route Target Constrained Distribution of Routes with no Route Targets 13 draft-ietf-idr-rtc-no-rt-09.txt 15 Abstract 17 There are a variety of BGP-enabled services in which the originator 18 of a BGP route may attach one or more "Route Targets" to the route. 19 By means of a procedure known as "RT Constrained Distribution" (RTC), 20 a given BGP speaker (call it "B") can announce the set of RTs in 21 which it has interest. The implication is that if a particular route 22 (call it "R") carries any RTs at all, BGP speaker B wants to receive 23 route R if and only if B has announced interest in one of the RTs 24 carried by R. However, if route R does not carry any RTs at all, 25 prior specifications do not make it clear whether B's use of RTC 26 implies that it does not want to receive route R. This has caused 27 interoperability problems in the field, as some implementations of 28 RTC do not allow B to receive R, but some services presuppose that B 29 will receive R. This document updates RFC 4684 by clarifying the 30 effect of the RTC mechanism on routes that do not have any RTs. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on October 25, 2018. 49 Copyright Notice 51 Copyright (c) 2018 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Some Deployment Scenarios . . . . . . . . . . . . . . . . . . 4 68 3. Default Behavior . . . . . . . . . . . . . . . . . . . . . . 4 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 73 6.2. Informative References . . . . . . . . . . . . . . . . . 6 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 76 1. Introduction 78 A BGP route can carry a particular type of BGP path attribute known 79 as an "Extended Communities Attribute" [RFC4360]. Each such 80 attribute can contain a variable number of typed communities. 81 Certain typed communities are known as "Route Targets" (RTs) 82 ([RFC4360], [RFC4364]). 84 [RFC4684] defines a procedure, known as "RT Constrained Distribution" 85 (RTC) that allows a BGP speaker to advertise its interest in a 86 particular set of RTs. It does so by advertising "RT membership 87 information". (See [RFC4684] for details.) It may advertise RT 88 membership for any number of RTs. By advertising membership for a 89 particular RT, a BGP speaker declares that it is interested in 90 receiving BGP routes that carry that RT. 92 If RTC is enabled on a particular BGP session, the session must be 93 provisioned with the set of "address family" and "subsequent address 94 family" values (AFI/SAFIs) to which RTC is to be applied. In 95 [RFC4684] it is implicitly assumed that RTC will only be applied to 96 AFI/SAFIs for which all the routes carry RTs. When this assumption 97 is true, the RTC semantics are clear. A BGP speaker advertising its 98 interest in RT1, RT2, ..., RTk is saying that, for the AFI/SAFIs to 99 which RTC is being applied, it is interested in any route that 100 carries at least one of those RTs, and it is not interested in any 101 route that does not carry at least one of those RTs. 103 However, [RFC4684] does not specify how the RTC procedures are to be 104 applied to AFI/SAFIs whose routes sometimes carry RTs and sometimes 105 do not. Consider a BGP session between routers R1 and R2, where R1 106 has advertised its interest in RT1, RT2, ..., RTk, and RTC is being 107 applied to a particular AFI/SAFI. Suppose R2 has a route of that 108 AFI/SAFI, and that route carries no RTs. Should R2 advertise this 109 route to R1 or not? 111 There are two possible answers to this question, each of which seems 112 prima facie reasonable: 114 o No, R2 should not advertise the route, because it belongs to an 115 AFI/SAFI to which RTC is being applied, and the route does not 116 carry any of the RTs in which R1 is interested. 118 o Yes, R2 should advertise the route; since the route carries no 119 RTs, the intention of the route's originator is that the 120 distribution of the route not be constrained by the RTC mechanism. 122 As might be expected, "one size does not fit all". The best answer 123 depends upon the particular deployment scenario, and upon the 124 particular AFI/SAFI to which RTC is being applied. 126 Section 3 defines a default behavior for existing AFI/SAFIs. This 127 default behavior ensures proper operation when RTC is applied to an 128 existing AFI/SAFI. The default behavior may of course be overridden 129 by local policy. 131 Section 3 also defines a default "default behavior" for new AFI/ 132 SAFIs. When a new AFI/SAFI is defined, the specification defining it 133 may specify a different default behavior; otherwise the default 134 default behavior will apply. 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 138 "OPTIONAL" in this document are to be interpreted as described in 139 [RFC2119]. 141 2. Some Deployment Scenarios 143 The lack of a clearly defined default behavior for applying RTC to 144 routes that carry no RTs is problematic in at least three scenarios. 146 o [RFC6037] describes a deployed Multicast VPN (MVPN) solution. It 147 defines a BGP SAFI known as "MDT-SAFI". Routes with this SAFI may 148 carry RTs, but are not required to do so. In order for the 149 procedures of [RFC6037] to work properly, if an MDT-SAFI route 150 does not carry any RTs, the distribution of that route MUST NOT be 151 constrained by RTC. However, if an MDT-SAFI route does carry one 152 or more RTs, its distribution SHOULD be constrained by RTC. 154 o [RFC7716] specifies a way to provide "Global Table Multicast" (as 155 opposed to VPN multicast), using procedures that are very similar 156 to those described in [RFC6513] and [RFC6514] for MVPN. In 157 particular, it uses routes of the MCAST-VPN SAFI that is defined 158 in [RFC6514]. When used for MVPN, each MCAST-VPN route carries at 159 least one RT. However, when used for Global Table Multicast, it 160 is optional for certain MCAST-VPN routes to carry RTs. In order 161 for the procedures of [RFC7716] to work properly, if an MCAST-VPN 162 route does not carry any RTs, the distribution of that route MUST 163 NOT be constrained by RTC. 165 o Typically, Route Targets have been carried only by routes that are 166 distributed as part of a VPN service (or the Global 167 Table Multicast service mentioned above). However, it may be 168 desirable to be able to place RTs on non-VPN routes (e.g., on 169 unicast IPv4 or IPv6 routes) and then to use RTC to constrain the 170 delivery of the non-VPN routes. For example, if a BGP speaker 171 desires to receive only a small set of IPv4 unicast routes, and 172 the desired routes carry one or more RTs, the BGP speaker could 173 use RTC to advertise its interest in one or more of those RTs. In 174 this application, the intention would be that any IPv4 unicast 175 route not carrying an RT would be filtered. Note that this is the 176 opposite of the behavior needed for the other use cases discussed 177 in this section. 179 3. Default Behavior 181 In order to handle the use cases discussed in Section 2, this 182 document specifies a default behavior for the case where RTC is 183 applied to a particular AFI/SAFI, and some (or all) routes of that 184 address family do not carry any RTs. 186 When RTC is applied, on a particular BGP session, to routes of the 187 MDT-SAFI address family (SAFI=66, [RFC6037]), the default behavior 188 MUST be that routes that do not carry any RTs are distributed on that 189 session. 191 When RTC is applied, on a particular BGP session, to routes of the 192 MCAST-VPN address family (SAFI=5, [RFC6514], [RFC7716]), the default 193 behavior MUST be that routes that do not carry any RTs are 194 distributed on that session. 196 When RTC is applied, on a particular BGP session, to routes of other 197 address families, the default behavior MUST be that routes without 198 any RTs are not distributed on that session. This default "default 199 behavior" applies to all AFI/SAFIs for which a different default 200 behavior has 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 The security considerations of [RFC4684] apply. 213 The procedures of this document may allow the distribution of certain 214 SAFI-5 and SAFI-66 routes, in situations where some implementations 215 of RTC would previously have prevented their distribution. However, 216 it is necessary to distribute such routes in order for the 217 applications using them to operate properly. Allowing the 218 distribution of such routes does not create any new security 219 considerations beyond those of the applications that use the routes. 221 6. References 223 6.1. Normative References 225 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 226 Requirement Levels", BCP 14, RFC 2119, 227 DOI 10.17487/RFC2119, March 1997, 228 . 230 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 231 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 232 February 2006, . 234 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 235 R., Patel, K., and J. Guichard, "Constrained Route 236 Distribution for Border Gateway Protocol/MultiProtocol 237 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 238 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 239 November 2006, . 241 6.2. Informative References 243 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 244 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 245 2006, . 247 [RFC6037] Rosen, E., Ed., Cai, Y., Ed., and IJ. Wijnands, "Cisco 248 Systems' Solution for Multicast in BGP/MPLS IP VPNs", 249 RFC 6037, DOI 10.17487/RFC6037, October 2010, 250 . 252 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 253 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 254 2012, . 256 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 257 Encodings and Procedures for Multicast in MPLS/BGP IP 258 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 259 . 261 [RFC7716] Zhang, J., Giuliano, L., Rosen, E., Ed., Subramanian, K., 262 and D. Pacella, "Global Table Multicast with BGP Multicast 263 VPN (BGP-MVPN) Procedures", RFC 7716, 264 DOI 10.17487/RFC7716, December 2015, 265 . 267 Authors' Addresses 269 Eric C. Rosen (editor) 270 Juniper Networks, Inc. 271 10 Technology Park Drive 272 Westford, Massachusetts 01886 273 United States 275 Email: erosen@juniper.net 277 Keyur Patel 278 Arccus 280 Email: keyur@arccus.com 281 Jeffrey Haas 282 Juniper Networks, Inc. 283 1194 N. Mathilda Ave. 284 Sunnyvale, California 94089 285 United States 287 Email: jhaas@juniper.net 289 Robert Raszuk 290 Bloomberg LP 291 731 Lexington Ave 292 New York City, NY 10022 293 United States 295 Email: robert@raszuk.net