idnits 2.17.1 draft-ietf-l3vpn-mvpn-mldp-nlri-10.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 RFC6514, updated by this document, for RFC5378 checks: 2006-08-01) -- 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 (November 25, 2014) is 3434 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) == Outdated reference: A later version (-19) exists of draft-ietf-idr-error-handling-16 -- Obsolete informational reference (is this intentional?): RFC 4601 (ref. 'PIM') (Obsoleted by RFC 7761) == Outdated reference: A later version (-17) exists of draft-ietf-mpls-seamless-mcast-14 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L3VPN Working Group IJsbrand Wijnands 3 Internet Draft Cisco Systems, Inc. 4 Intended Status: Proposed Standard 5 Updates: 6514 Eric C. Rosen 6 Expires: May 25, 2015 Juniper Networks, Inc. 8 Uwe Joorde 9 Deutsche Telekom 11 November 25, 2014 13 Encoding mLDP FECs in the NLRI of BGP MCAST-VPN Routes 15 draft-ietf-l3vpn-mvpn-mldp-nlri-10.txt 17 Abstract 19 Many service providers offer "BGP/MPLS IP VPN" service to their 20 customers. Existing IETF standards specify the procedures and 21 protocols that a service provider uses in order to offer this service 22 to customers who have IP unicast and IP multicast traffic in their 23 VPNs. It is also desirable to be able to support customers who have 24 MPLS multicast traffic in their VPNs. This document specifies the 25 procedures and protocol extensions that are needed to support 26 customers who use the Multicast Extensions to Label Distribution 27 Protocol (mLDP) as the control protocol for their MPLS multicast 28 traffic. Existing standards do provide some support for customers 29 who use mLDP, but only under a restrictive set of circumstances. 30 This document generalizes the existing support to include all cases 31 where the customer uses mLDP, without any restrictions. This 32 document updates RFC 6514. 34 Status of this Memo 36 This Internet-Draft is submitted to IETF in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF), its areas, and its working groups. Note that 41 other groups may also distribute working documents as Internet- 42 Drafts. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/ietf/1id-abstracts.txt. 52 The list of Internet-Draft Shadow Directories can be accessed at 53 http://www.ietf.org/shadow.html. 55 Copyright and License Notice 57 Copyright (c) 2014 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1 Introduction .......................................... 3 73 2 Why This Document is Needed ........................... 4 74 3 Encoding an mLDP FEC in the MCAST-VPN NLRI ............ 5 75 4 Wildcards ............................................. 7 76 5 IANA Considerations ................................... 7 77 6 Security Considerations ............................... 10 78 7 Acknowledgments ....................................... 10 79 8 Authors' Addresses .................................... 10 80 9 Normative References .................................. 11 81 10 Informative References ................................ 11 82 1. Introduction 84 Many service providers (SPs) offer "BGP/MPLS IP VPN" service to their 85 customers. When a customer has IP multicast traffic in its VPN, the 86 service provider needs to signal the customer multicast states across 87 the backbone. A customer with IP multicast traffic is typically 88 using PIM ("Protocol Independent Multicast") [PIM] and/or IGMP 89 ("Internet Group Management Protocol") [IGMP] as the multicast 90 control protocol in its VPN. The IP multicast states of these 91 protocols are commonly denoted as "(S,G)" and/or "(*,G)" states, 92 where "S" is a multicast source address and "G" is a multicast group 93 address. [MVPN-BGP] specifies the way an SP may use BGP to signal a 94 customer's IP multicast states across the SP backbone. This is done 95 by using "Multiprotocol BGP" Updates whose "Subsequent Address Family 96 Identifier" (SAFI) value is "MCAST-VPN" (5). The NLRI ("Network 97 Layer Reachability Information") field of these Updates includes a 98 customer Multicast Source field and a customer Multicast Group field, 99 thus enabling the customer's (S,G) or (*,G) states to be encoded in 100 the NLRI. 102 It is also desirable for the BGP/MPLS IP VPN service to be able to 103 support customers who are using MPLS multicast, either instead of, or 104 in addition to, IP multicast. This document specifies the procedures 105 and protocol extensions needed to support customers who use mLDP 106 ("Multicast Extensions to Label Distribution Protocol") [mLDP] to 107 create and maintain Point-to-Multipoint (P2MP) and/or Multipoint-to- 108 Multipoint (MP2MP) Label Switched Paths (LSPs). While mLDP is not 109 the only protocol that can be used to create and maintain multipoint 110 LSPs, consideration of other MPLS multicast control protocols is 111 outside the scope of this document. 113 When a customer is using mLDP in its VPN, the customer multicast 114 states associated with mLDP are denoted by an mLDP "FEC Element" 115 ("Forwarding Equivalence Class element", see [mLDP]), instead of by 116 an (S,G) or (*,G). Thus it is necessary to have a way to encode a 117 customer's mLDP FEC Elements in the NLRI field of the BGP MCAST-VPN 118 routes. 120 While [MVPN-BGP] does specify a way of encoding an mLDP FEC Element 121 in the MCAST-VPN NLRI field, the encoding specified therein makes a 122 variety of restrictive assumptions about the customer's use of mLDP. 123 (These assumptions are described in section 2 of this document.) The 124 purpose of this document is to update [MVPN-BGP] so that customers 125 using mLDP in their VPNs can be supported even when those assumptions 126 do not hold. 128 Some SPs use the MVPN procedures to provide "global table multicast" 129 service (i.e., multicast service that is not in the context of a VPN) 130 to customers. Methods for doing this are specified in [GTM] and in 131 [SEAMLESS-MCAST]. The procedures described in this document can be 132 used along with the procedures of [GTM] or [SEAMLESS-MCAST] to 133 provide global table multicast service to customers that use MPLS 134 multicast in a global table context. 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119]. 140 2. Why This Document is Needed 142 An mLDP FEC Element consists of a FEC Type, a Root Node, and an 143 Opaque Value. mLDP uses several FEC types, and in particular, uses 144 the FEC type to distinguish between P2MP LSPs and MP2MP LSPs. 146 Section 11.1.2 of [MVPN-BGP] ("Originating routes: mLDP as the C- 147 multicast control protocol") states: 149 Whenever a PE ("Provider Edge" router) receives from one of its 150 CEs ("Customer Edge" routers) a P2MP Label Map over 151 interface I, where X is the Root Node Address, Y is the Opaque 152 Value, and L is an MPLS label ... the PE constructs a Source Tree 153 Join C-multicast route whose MCAST-VPN NLRI contains X as the 154 Multicast Source field, and Y as the Multicast Group field. 156 In other words, the Root Node of the mLDP FEC Element appears in the 157 Multicast Source Field, and the Opaque Value of the mLDP FEC Element 158 appears in the Multicast Group field. 160 This method of encoding an mLDP FEC in an MCAST-VPN NLRI can only be 161 used if all of the following conditions hold: 163 1. A customer using mLDP is not also using PIM/IGMP. 165 The encoding in [MVPN-BGP] does not specify any way in which 166 one can determine, upon receiving a BGP Update, whether the 167 Multicast Group field contains an IP address or whether it 168 contains an mLDP FEC Element Opaque Value. Therefore it might 169 not uniquely identify a customer multicast state if the 170 customer is using both PIM/IGMP and mLDP in its VPN. 172 2. A customer using mLDP is using only the mLDP P2MP FEC Element, 173 and is not using the mLDP MP2MP FEC Element. 175 The encoding in [MVPN-BGP] does not specify any way to encode 176 the type of the mLDP FEC Element; it just assumes it to be a 177 P2MP FEC Element. 179 3. A customer using mLDP is using only an mLDP Opaque Value type 180 for which the Opaque Value is exactly 32 bits or 128 bits long. 182 The use of Multicast Group fields that have other lengths is 183 declared by [MVPN-BGP] to be "out of scope" of that document 184 (see, e.g., section 4.3 of that document). 186 This condition holds if the customer uses only the mLDP 187 "Generic LSP Identifier" Opaque Value type (defined in [mLDP]). 188 However, mLDP supports many other Opaque Value types whose 189 length is not restricted to be 32 or 128 bits. 191 The purpose of this document is to update [MVPN-BGP] so that 192 customers using mLDP can be supported, even when these conditions do 193 not hold. 195 3. Encoding an mLDP FEC in the MCAST-VPN NLRI 197 When mLDP is used as the customer multicast control protocol, [MVPN- 198 BGP] presupposes that an mLDP FEC element will be encoded in the NLRI 199 of the following three MCAST-VPN route types: 201 - C-multicast Source Tree Join, 203 - S-PMSI A-D route, and 205 - Leaf A-D route. 207 The other four MCAST-VPN route types defined in [MVPN-BGP] do not 208 ever need to carry mLDP FEC Elements. The C-multicast Shared Tree 209 Join route and the Source Active A-D route are used to communicate 210 state about unidirectional shared trees; since mLDP does not have 211 unidirectional shared trees, these routes are not used to signal mLDP 212 states. The Intra-AS I-PMSI A-D route and the Inter-AS I-PMSI A-D 213 route do not identify specific customer multicast states, and hence 214 do not carry any information that is specific to the customer's 215 multicast control protocol. 217 This document defines three new route types: 219 - C-Multicast Source Tree Join route for C-multicast mLDP 220 - S-PMSI A-D route for C-multicast mLDP 222 - Leaf A-D route for C-multicast mLDP. 224 The term "C-multicast mLDP" in the names of these route types is 225 intended to indicate that the NLRI of these routes contains mLDP FEC 226 elements. 228 Each of these route types corresponds to a route type defined in 229 [MVPN-BGP]. IANA has been requested to allocate codepoints for these 230 three route types such that (a) the high order two bits have the 231 value 0x01, and (b) the low order six bits have the same value as 232 the codepoints for the corresponding route types from [MVPN-BGP]. 234 In general, the procedures defined in other MVPN specifications for 235 the C-Multicast Source Tree Join route, the S-PMSI A-D route, and the 236 Leaf A-D route apply as well to the C-Multicast Source Tree Join 237 route for C-multicast mLDP, the S-PMSI A-D route for C-multicast 238 mLDP, and the Leaf A-D route for C-multicast mLDP, respectively. 239 However, the NLRI of these three new route types is constructed 240 differently than the NLRI of the corresponding routes from [MVPN- 241 BGP]: the "Multicast Source Length", "Multicast Source", "Multicast 242 Group Length", and "Multicast Group" fields are omitted, and in their 243 place is a single mLDP FEC Element, as defined in [mLDP]. (See 244 section 2.2 of [mLDP] for a diagram of the mLDP FEC element.) 246 As a result, the NLRI of an S-PMSI A-D route for C-multicast mLDP 247 will consist of a Route Distinguisher, followed by the mLDP FEC, 248 followed by the "Originating Router's IP Address Field". 250 The NLRI of a C-multicast Source Tree Join route for C-multicast mLDP 251 will consist of a Route Distinguisher, followed by the Source AS, 252 followed by the mLDP FEC. 254 In a Leaf A-D route for C-multicast mLDP that has been derived from 255 an S-PMSI A-D route for C-multicast mLDP, the "route key" field 256 remains the NLRI of the S-PMSI A-D route from which it was derived. 258 In a Leaf A-D route for C-multicast mLDP that has not been derived 259 from an S-PMSI A-D, the "route key" field is as specified in 260 [SEAMLESS-MCAST], except that the "Multicast Source Length", 261 "Multicast Source", "Multicast Group Length", and "Multicast Group" 262 fields are omitted, and in their place is a single mLDP FEC Element. 263 Thus the route key field consists of a Route Distinguisher, an MLDP 264 FEC element, and the IP address of the Ingress PE router. 266 Please note that [BGP-ERR] section 5.4 ("Typed NLRI") is applicable 267 if the Route Type field of the NLRI of a received MCAST-VPN route 268 contains an unrecognized value. Any such routes will be discarded. 270 An mLDP FEC element contains an "address family" field whose value is 271 from IANA's "Address Family Numbers" registry. The value of the 272 "address family" field identifies the address family of the "root 273 node address" field of the FEC element. When an mLDP FEC element is 274 encoded into the NLRI of an a BGP update whose SAFI is MCAST-VPN, the 275 address family of the root node address (as indicated in the FEC 276 element) MUST "correspond to" the address family that is identified 277 in the "Address Family Identifier" (AFI) field of that BGP update. 278 These two "address family" fields are considered to "correspond" to 279 each other under the following conditions: 281 - they contain identical values, or 283 - the BGP update's AFI field identifies IPv4 as the address family, 284 and the mLDP FEC element identifies "Multi-Topology IPv4" as the 285 address family of the root node, or 287 - the BGP update's AFI field identifies IPv6 as the address family, 288 and the mLDP FEC element identifies "Multi-Topology IPv6" as the 289 address family of the root node. 291 For more information about the "multi-topology" address families, see 292 [LDP-MT] and [mLDP-MT]. 294 4. Wildcards 296 [MVPN-WILDCARDS] specifies encodings and procedures that allow 297 "wildcards" to be specified in the NLRI of S-PMSI A-D routes. A set 298 of rules are given that specify when a customer multicast flow 299 "matches" a given S-PMSI A-D route whose NLRI contains wildcards. 300 However, the use of these wildcards is defined only for the case 301 where the customer is using PIM as its multicast control protocol. 302 The use of wildcards when the customer is using mLDP as its multicast 303 control protocol is outside the scope of this document. 305 5. IANA Considerations 307 [MVPN-BGP] does not create a registry for the allocation of new 308 MCAST-VPN Route Type values. In retrospect, it seems that it should 309 have done so. IANA is requested to create a new registry called "BGP 310 MCAST-VPN Route Types", referencing this document and [MVPN-BGP]. 311 The registry should be created under the "top-level" registry: 312 "Border Gateway Protocol (BGP) Parameters 313 http://www.iana.org/assignments/bgp-parameters/bgp-parameters". The 314 allocation policy should be "Standards Action". Values may be 315 assigned from one of several ranges: 317 - Range 0x01-0x3f: Generic/PIM Range. Values are assigned from 318 this range when the NLRI format associated with the route type 319 presupposes that PIM or IGMP is the C-multicast control protocol, 320 or when the NLRI format associated with the route type is 321 independent of the C-multicast control protocol. 323 - Range 0x43-0x7f: mLDP Range. Values are assigned from this range 324 when the NLRI format associated with the route type presupposes 325 that mLDP is the C-multicast control protocol. 327 - Range 0x80-0xff: This range is reserved; values should not be 328 assigned from this range. 330 In general, whenever an assignment is requested from this registry, 331 two codepoints should be requested at the same time: one from the 332 Generic/PIM range and one from the mLDP range. The two codepoints 333 should have the same low-order 6 bits. If one of the two codepoints 334 is not actually needed, it should be registered anyway, and marked as 335 "reserved". 337 When the BGP MCAST-VPN Route Types registry is created, it should 338 contain the following assignments: 340 Value Meaning Reference 341 0x00 Reserved This RFC 343 0x01 Intra-AS I-PMSI A-D route This RFC, RFC6514 345 0x02 Inter-AS I-PMSI A-D route This RFC, RFC6514 347 0x03 S-PMSI A-D route This RFC, RFC6514 349 0x04 Leaf A-D route This RFC, RFC6514 351 0x05 Source Active A-D route This RFC, RFC6514 353 0x06 Shared Tree Join route This RFC, RFC6514 355 0x07 Source Tree Join route This RFC, RFC6514 357 0x08-0x3f Unassigned (Generic/PIM range) This RFC 359 0x40-0x42 Reserved This RFC 361 0x43 S-PMSI A-D route for 362 C-multicast mLDP This RFC 364 0x44 Leaf A-D route for C-multicast mLDP This RFC 366 0x45-0x46 Reserved This RFC 368 0x47 Source Tree Join route for 369 C-multicast mLDP This RFC 371 0x48-0x7f Unassigned (mLDP range) This RFC 373 0x80-0xff Reserved This RFC 375 6. Security Considerations 377 This document specifies a method of encoding an mLDP FEC element in 378 the NLRI of some of the BGP Update messages that are specified in 379 [MVPN-BGP]. The security considerations of [mLDP] and of [MVPN-BGP] 380 are applicable, but no new security considerations are raised. 382 7. Acknowledgments 384 The authors wish to thank Pradosh Mohapatra and Saquib Najam for 385 their ideas and comments. We also thank Yakov Rekhter and Martin 386 Vigoureux for their comments. 388 8. Authors' Addresses 390 IJsbrand Wijnands 391 Cisco Systems, Inc. 392 De kleetlaan 6a Diegem 1831 393 BE 394 E-mail: ice@cisco.com 396 Eric C. Rosen 397 Juniper Networks, Inc. 398 10 Technology Park Drive 399 Westford, Massachusetts 01886 400 US 401 E-mail: erosen@juniper.net 403 Uwe Joorde 404 Deutsche Telekom 405 Hammer Str. 216-226 406 D-48153 Muenster, Germany 407 E-mail: Uwe.Joorde@telekom.de 409 9. Normative References 411 [mLDP] "Label Distribution Protocol Extensions for Point-to- 412 Multipoint and Multipoint-to-Multipoint Label Switched Paths", 413 Wijnands, Minei, Kompella, Thomas, RFC 6388, November 2011 415 [MVPN-BGP] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP 416 VPNs", Aggarwal, Rosen, Morin, Rekhter, RFC 6514, February 2012 418 [RFC2119] "Key words for use in RFCs to Indicate Requirement 419 Levels.", Bradner, RFC 2119, March 1997 421 10. Informative References 423 [BGP-ERR] "Revised Error Handling for BGP UPDATE Messages", Chen, 424 Scudder, Mohapatra, Patel, draft-ietf-idr-error-handling-16.txt, 425 November 2014 427 [GTM] "Global Table Multicast with BGP-MVPN Procedures", Zhang, 428 Giuliano, Rosen, Subramanian, Pacella, Schiller, draft-ietf-l3vpn- 429 mvpn-global-table-mcast-00.txt, June 2014 431 [IGMP] "Internet Group Management Protocol, Version 3", Cain, 432 Deering, Kouvelas, Fenner, Thyagarajan, RFC 3376, October 2002 434 [LDP-MT] "LDP Extensions for Multi-Topology", Zhao, et. al., RFC 435 7307, July 2014 437 [mLDP-MT] "mLDP Extensions for Multi Topology Routing", Wijnands, 438 Raza, draft-iwijnand-mpls-mldp-multi-topology-03.txt, June 2013 440 [MVPN-WILDCARDS], "Wildcards in Multicast VPN Auto-Discovery Routes", 441 Rosen, Rekhter, Hendrickx, Qiu, RFC 6625, May 2012 443 [PIM] "Protocol Independent Multicast - Sparse Mode (PIM-SM)", 444 Fenner, Handley, Holbrook, Kouvelas, August 2006, RFC 4601 446 [SEAMLESS-MCAST] "Inter-Area P2MP Segmented LSPs", Rekhter, Aggarwal, 447 Morin, Grosclaude, Leymann, Saad, draft-ietf-mpls-seamless- 448 mcast-14.txt, July 2014