idnits 2.17.1 draft-ietf-l3vpn-mvpn-mldp-nlri-01.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 15, 2013) is 3970 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 (-12) exists of draft-ietf-mpls-ldp-multi-topology-08 -- 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-07 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 15, 2013 Uwe Joorde 7 Deutsche Telekom 9 May 15, 2013 11 Encoding mLDP FECs in the NLRI of BGP MCAST-VPN Routes 13 draft-ietf-l3vpn-mvpn-mldp-nlri-01.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) 2013 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 ................................... 8 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" 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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC2119]. 128 2. Why This Document is Needed 130 An mLDP FEC Element consists of a FEC Type, a Root Node, and an 131 Opaque Value. mLDP uses several FEC types, and in particular, uses 132 the FEC type to distinguish between P2MP LSPs and MP2MP LSPs. 134 Section 11.1.2 of [MVPN-BGP] ("Originating routes: mLDP as the C- 135 multicast control protocol") states: 137 Whenever a PE receives from one of its CEs a P2MP Label Map over interface I, where X is the Root Node Address, Y is 139 the Opaque Value, and L is an MPLS label ... the PE constructs a 140 Source Tree Join C-multicast route whose MCAST-VPN NLRI contains 141 X as the Multicast Source field, and Y as the Multicast Group 142 field. 144 In other words, the Root Node of the mLDP FEC Element appears in the 145 Multicast Source Field, and the Opaque Value of the mLDP FEC Element 146 appears in the Multicast Group field. 148 This method of encoding an mLDP FEC in an MCAST-VPN NLRI can only be 149 used if all of the following conditions hold: 151 1. A customer using mLDP is not also using PIM/IGMP. 153 The encoding in [MVPN-BGP] does not specify any way in which 154 one can determine, upon receiving a BGP Update, whether the 155 Multicast Group field contains an IP address or whether it 156 contains an mLDP FEC Element Opaque Value. Therefore it may 157 not uniquely identify a customer multicast state if the 158 customer is using both PIM/IGMP and mLDP in its VPN. 160 2. A customer using mLDP is using only the mLDP P2MP FEC Element, 161 and is not using the mLDP MP2MP FEC Element. 163 The encoding in [MVPN-BGP] does not specify any way to encode 164 the type of the mLDP FEC Element; it just assumes it to be a 165 P2MP FEC Element. 167 3. A customer using mLDP is using only an mLDP Opaque Value type 168 for which the Opaque Value is exactly 32 bits or 128 bits long. 170 The use of Multicast Group fields that have other lengths is 171 declared by [MVPN-BGP] to be "out of scope" of that document 172 (see, e.g., section 4.3 of that document). 174 This condition holds if the customer uses only the mLDP 175 "Generic LSP Identifier" Opaque Value type (defined in [mLDP]). 176 However, mLDP supports many other Opaque Value types whose 177 length is not restricted to be 32 or 128 bits. 179 The purpose of this document is to update [MVPN-BGP] so that 180 customers using mLDP can be supported, even when these conditions do 181 not hold. 183 In addition, neither [MVPN-BGP] nor [MVPN-WILDCARDS] addresses the 184 use of "wild cards" when the MCAST-VPN NLRI encodes an MLDP FEC. 185 This document specifies a way to encode mLDP FEC Element wild cards 186 in the NLRI of the relevant BGP MCAST-VPN routes. 188 3. Encoding an mLDP FEC in the MCAST-VPN NLRI 190 This section specifies the way to encode an mLDP FEC element in the 191 NLRI of the following three MCAST-VPN route types defined in [MVPN- 192 BGP]: 194 - C-multicast Source Tree Join, 196 - S-PMSI A-D route, and 198 - Leaf A-D route. 200 The other four MCAST-VPN route types defined in [MVPN-BGP] do not 201 ever need to carry mLDP FEC Elements. The C-multicast Shared Tree 202 Join route and the Source Active A-D route are used to communicate 203 state about unidirectional shared trees; since mLDP does not have 204 unidirectional shared trees, these routes are not used to signal mLDP 205 states. The Intra-AS I-PMSI A-D route and the Inter-AS I-PMSI A-D 206 route do not identify specific customer multicast states, and hence 207 do not carry any information that is specific to the customer's 208 multicast control protocol. 210 Per [MVPN-BGP], the first octet of the NLRI of an MCAST-VPN route is 211 a "route type". Only values 1-7 are defined. The high order 5 bits 212 of that octet are thus always zero. 214 This document updates [MVPN-BGP] by specifying a use for the high 215 order 2 bits of the "route type" octet. The following two values are 216 defined: 218 - If the two high order bits are both zero, the NLRI is as 219 specified in [MVPN-BGP] and/or [MVPN-WILDCARDS]. 221 - If the two high order bits have the value 01, the NLRI encoding 222 is modified as follows: the "Multicast Source Length", "Multicast 223 Source", "Multicast Group" length, and "Multicast Group" fields 224 are omitted, and in their place is a single mLDP FEC Element, as 225 defined in [mLDP]. See section 2.2 of [mLDP] for a diagram of 226 the mLDP FEC element. 228 The other two possible values (11 and 10) for the two high order bits 229 may be used at a later time to identify other multicast control 230 protocols. 232 As a result, the NLRI of an S-PMSI A-D route with an mLDP FEC in its 233 NLRI will consist of a Route Distinguisher, followed by the mLDP FEC, 234 followed by the "Originating Router's IP Address Field". 236 The NLRI of a C-multicast Source Tree Join route with an mLDP FEC in 237 its NLRI will consist of a Route Distinguisher, followed by the 238 Source AS, followed by the mLDP FEC. 240 In a Leaf A-D route that has been derived from an S-PMSI A-D route, 241 the "route key" field remains the NLRI of the S-PMSI A-D route from 242 which it was derived. 244 In a Leaf A-D route that has not been derived from an S-PMSI A-D 245 route, the "route key" field is as specified in [SEGMENTED-MVPN], 246 except that the "Multicast Source Length", "Multicast Source", 247 "Multicast Group" length, and "Multicast Group" fields are omitted, 248 and in their place is a single mLDP FEC Element. Thus the route key 249 field consists of a Route Distinguisher, an MLDP FEC element, and the 250 IP address of the Ingress PE router. 252 An mLDP FEC element contains an "address family" field from IANA's 253 "Address Family Numbers" registry. This identifies the address 254 family of the "root node address" field of the FEC element. When an 255 mLDP FEC element is encoded into the NLRI of an a BGP update whose 256 SAFI is MCAST-VPN, the address family of the root node (as indicated 257 in the FEC element) MUST "correspond to" the address family that is 258 identified in the AFI field of that BGP update. These two "address 259 family" fields are considered to "correspond" under the following 260 conditions: 262 - they contain identical values, or 263 - the BGP update's AFI field identifies IPv4 as the address family, 264 and the mLDP FEC element identifies "Multi-Topology IPv4" as the 265 address family of the root node, or 267 - the BGP update's AFI field identifies IPv6 as the address family, 268 and the mLDP FEC element identifies "Multi-Topology IPv6" as the 269 address family of the root node. 271 For more information about the "multi-topology" address families, see 272 [LDP-MT] and [mLDP-MT]. 274 4. Wildcards 276 [MVPN-WILDCARDS] specifies encodings and procedures that allow 277 "wildcards" to be specified in the NLRI of S-PMSI A-D routes. A set 278 of rules are given that specify when a customer multicast flow 279 "matches" a given S-PMSI A-D route whose NLRI contains wildcards. 280 However, the use of these wildcards is defined only for the case 281 where the customer is using PIM as its multicast control protocol. 282 In this section, we define the wildcard encodings for the case where 283 the customer is using mLDP as its multicast control protocol. 285 Customer mLDP Multipoint LSPs do NOT ever match S-PMSI A-D routes 286 containing the wildcards specified in [MVPN-WILDCARDS]. 288 To specify a wildcard that can be matched by a customer mLDP 289 Multipoint LSP, one encodes an mLDP "typed wildcard FEC" [LDP-WC] 290 into the NLRI of the S-PMSI A-D route. 292 The mLDP typed wildcard FEC is specified in section 9 of [mLDP], 293 which includes the following diagram: 295 0 1 2 3 296 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Typed Wcard | Type | Len = 2 | AFI ~ 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 ~ | 301 +-+-+-+-+-+-+-+-+ 303 The field "Typed Wcard" contains the value in the IANA LDP Registry 304 "Forwarding Equivalence Class (FEC) Type Name Space" that is 305 assigned to "Typed Wildcard FEC Element" (i.e., 5). 307 The AFI field contains an address family identifier, from IANA's 308 "Address Family Numbers" registry. 310 The "Type" field MUST either be set to zero, or contain one of the 311 following values from the IANA LDP Registry "Forwarding Equivalence 312 Class (FEC) Type Name Space": 314 - P2MP FEC (6) 316 - MP2MP-Up FEC (7) 318 - MP2MP-Down FEC (8) 320 If the type field is set to "P2MP-FEC", the wildcard FEC element 321 means "any P2MP FEC whose root node address is of the specified 322 address family". 324 If the type field is set to "MP2MP-Up" or "MP2MP-Down", the wildcard 325 FEC element means "any MP2MP FEC" whose root node address is of the 326 specified address family. When generating this wildcard FEC, the 327 value "MP2MP-Down" SHOULD be used. 329 If the type field is set to 0, the wildcard FEC element means "any 330 P2MP or MP2MP" FEC whose root node address is of the specified 331 address family. 333 A future revision of this document will discuss use cases, and 334 provide a more detailed set of procedures for using these wildcards. 336 5. IANA Considerations 338 [MVPN-BGP] does not create a registry for the allocation of new 339 MCAST-VPN Route Type values. In retrospect, it seems that it should 340 have done so. IANA should create a registry called "MCAST-VPN Route 341 Types", referencing this document and [MVPN-BGP]. The allocation 342 policy should be "Standards Action with Early Allocation", and the 343 assignable values are in the range 0-0xFF. The following values 344 should be assigned: 346 - 0x00: Reserved 348 - 0x01: Intra-AS I-PMSI A-D route (reference: [MVPN-BGP]) 350 - 0x02: Inter-AS I-PMSI A-D route (reference: [MVPN-BGP]) 351 - 0x03: S-PMSI A-D route for PIM as the C-multicast control 352 protocol (reference: [MVPN-BGP]) 354 - 0x43: S-PMSI A-D route for mLDP as the C-multicast control 355 protocol (reference: this document) 357 - 0x04: Leaf A-D route for PIM as the C-multicast control protocol 358 (reference: [MVPN-BGP]) 360 - 0x44: Leaf A-D route for mLDP as the C-multicast control protocol 361 (reference: this document) 363 - 0x05: Source Active A-D route for PIM as the C-multicast control 364 protocol (reference: [MVPN-BGP]) 366 - 0x06: Shared Tree Join route for PIM as the C-multicast control 367 protocol (reference: [MVPN-BGP]) 369 - 0x07: Source Tree Join route for PIM as the C-multicast control 370 protocol (reference: [MVPN-BGP]) 372 - 0x47: Source Tree Join route for mLDP as the C-multicast control 373 protocol (reference: this document) 375 6. Security Considerations 377 No new security issues. 379 7. Acknowledgments 381 The authors wish to think Pradosh Mohapatra and Saquib Najam for 382 their ideas and comments. We also thank Yakov Rekhter for his 383 comments. 385 8. Authors' Addresses 387 IJsbrand Wijnands 388 Cisco Systems, Inc. 389 De kleetlaan 6a Diegem 1831 390 Belgium 391 E-mail: ice@cisco.com 392 Eric C. Rosen 393 Cisco Systems, Inc. 394 1414 Massachusetts Avenue 395 Boxborough, MA, 01719 396 E-mail: erosen@cisco.com 398 Uwe Joorde 399 Deutsche Telekom 400 Hammer Str. 216-226 401 D-48153 Muenster, Germany 402 E-mail: Uwe.Joorde@telekom.de 404 9. Normative References 406 [LDP-WC] Asati, R., Minei, I., and B. Thomas, "Label Distribution 407 Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)", RFC 408 5918, August 2010. 410 [mLDP] "Label Distribution Protocol Extensions for Point-to- 411 Multipoint and Multipoint-to-Multipoint Label Switched Paths", 412 Wijnands, Minei, Kompella, Thomas, RFC 6388, November 2011 414 [MVPN-BGP] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP 415 VPNs", Aggarwal, Rosen, Morin, Rekhter, RFC 6514, February 2012 417 [MVPN-WILDCARDS], "Wildcards in Multicast VPN Auto-Discovery Routes", 418 Rosen, Rekhter, Hendrickx, Qiu, RFC 6625, May 2012 420 [RFC2119] "Key words for use in RFCs to Indicate Requirement 421 Levels.", Bradner, RFC 2119, March 1997 423 10. Informative References 425 [IGMP] "Internet Group Management Protocol, Version 3", Cain, 426 Deering, Kouvelas, Fenner, Thyagarajan, RFC 3376, October 2002 428 [LDP-MT] "LDP Extensions for Multi-Topology Routing", Zhao, et. al., 429 draft-ietf-mpls-ldp-multi-topology-08.txt, May 2013 431 [mLDP-MT] "mLDP Extensions for Multi Topology Routing", Wijnands, 432 Raza, draft-iwijnand-mpls-mldp-multi-topology-02.txt, July 2012 434 [PIM] "Protocol Independent Multicast - Sparse Mode (PIM-SM)", 435 Fenner, Handley, Holbrook, Kouvelas, August 2006, RFC 4601 437 [SEGMENTED-MVPN] "Inter-Area P2MP Segmented LSPs", Rekhter, Aggarwal, 438 Morin, Grosclaude, Leymann, Saad, draft-ietf-mpls-seamless- 439 mcast-07.txt, May 2013