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