idnits 2.17.1 draft-rosen-l3vpn-mvpn-mspmsi-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 -- 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 (February 6, 2012) is 4460 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) ** Obsolete normative reference: RFC 4601 (ref. 'PIM') (Obsoleted by RFC 7761) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L3VPN Working Group Yiqun Cai 3 Internet Draft Eric C. Rosen (Editor) 4 Intended Status: Proposed Standard IJsbrand Wijnands 5 Expires: August 6, 2012 Cisco Systems, Inc. 7 Maria Napierala 8 AT&T 10 Arjen Boers 12 February 6, 2012 14 MVPN: Optimized use of PIM via MS-PMSIs 16 draft-rosen-l3vpn-mvpn-mspmsi-10.txt 18 Abstract 20 This document specifies an optimized method that a service provider 21 can use to provide MVPN service when using PIM as the MVPN control 22 protocol. As in prior MVPN methods, PIM control messages are sent 23 over multicast tunnels through the provider network. However, unlike 24 older MVPN methods, the tunnels are only created if they are needed 25 to carry multicast data traffic; no tunnels are used only for control 26 traffic. 28 Status of this Memo 30 This Internet-Draft is submitted to IETF in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt. 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html. 49 Copyright and License Notice 51 Copyright (c) 2012 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 (http://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 Specification of requirements ......................... 3 67 2 Introduction .......................................... 3 68 2.1 Terminology ........................................... 3 69 3 MS-PMSI: Multidirectional Selective PMSI .............. 3 70 3.1 A PE's Primary MS-PMSI ................................ 4 71 3.2 Instantiating MS-PMSIs ................................ 5 72 3.2.1 Bidirectional P-Tunnels ............................... 5 73 3.2.2 Unidirectional P-Tunnels .............................. 5 74 3.2.2.1 PPMP LSPs ............................................. 5 75 3.2.2.2 Sparse Mode ASM Groups ................................ 7 76 4 PIM over MS-PMSI ...................................... 7 77 5 IANA Considerations ................................... 9 78 6 Security Considerations ............................... 9 79 7 Acknowledgments ....................................... 9 80 8 Authors' Addresses .................................... 10 81 9 Normative References .................................. 10 82 10 Informative References ................................ 11 83 1. Specification of requirements 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC2119]. 89 2. Introduction 91 [MVPN] specifies how to run PIM [PIM] as the multicast routing 92 protocol of a particular MVPN, by running it over an MI-PMSI for that 93 MVPN. In this specification, we provide a specification for running 94 PIM over an MS-PMSI. When PIM is run over an MI-PMSI, there may need 95 to be P-tunnels that only carry PIM messages, but do not carry 96 multicast data. However, when PIM is run over an MS-PMSI, there is 97 never any need to create a P-tunnel just for control messages; the 98 only P-tunnels needed are those that carry multicast data. 100 2.1. Terminology 102 In the following, we will sometimes talk of a PE receiving traffic 103 from a PMSI and then discarding it. If PIM is being used as the 104 multicast control protocol between PEs, this always implies that the 105 discarded traffic will not be seen by PIM on the receiving PE. 107 In the following, we will sometimes speak of an S-PMSI A-D route 108 being "ignored". When we say the route is "ignored", we do not mean 109 that its normal BGP processing is not done, but that the route is not 110 considered when determining which P-tunnel to use when sending 111 multicast data, and that the MPLS label values it conveys are not 112 used. We will generally use "ignore" in quotes to indicate this 113 meaning. 115 3. MS-PMSI: Multidirectional Selective PMSI 117 [MVPN] defines three kinds of PMSI: 119 - "Multidirectional Inclusive" PMSI (MI-PMSI) 121 A Multidirectional Inclusive PMSI is one that enables ANY PE 122 attaching to a particular MVPN to transmit a message such that it 123 will be received by EVERY other PE attaching to that MVPN. 125 - "Unidirectional Inclusive" PMSI (UI-PMSI) 127 A Unidirectional Inclusive PMSI is one that enables a particular 128 PE, attached to a particular MVPN, to transmit a message such 129 that it will be received by all the other PEs attaching to that 130 MVPN. There is at most one UI-PMSI per PE per MVPN, though the 131 P-tunnel that instantiates a UI-PMSI may in fact carry the data 132 of more than one PMSI. 134 - "Selective" PMSI (S-PMSI). 136 A Selective PMSI is one that provides a mechanism wherein a 137 particular PE in an MVPN can multicast messages so that they will 138 be received by a subset of the other PEs of that MVPN. There may 139 be an arbitrary number of S-PMSIs per PE per MVPN. 141 In this document we add the notion of a "Multidirectional Selective 142 PMSI" (MS-PMSI). An MS-PMSI provides a mechanism that enables a 143 subset of PEs in a given MVPN to multicast messages so that they will 144 be received by the other PEs that are in the subset. There may be an 145 arbitrary number of MS-PMSIs per PE per MVPN. 147 According to the definition of S-PMSI in [MVPN], only a single PE can 148 transmit onto a given S-PMSI. An MS-PMSI may be thought of as a 149 collection of S-PMSIs, each of which has the same subset of PEs as 150 transmitters or receivers. Although each individual S-PMSI in the 151 set has a single PE as transmitter, the collection of S-PMSIs has all 152 members of the subset as transmitters, and all members of the subset 153 as receivers. 155 3.1. A PE's Primary MS-PMSI 157 Although a PE may belong to many MS-PMSIs, we allow one MS-PMSI per 158 PE to be distinguished as the MS-PMSI that is that PE's "primary MS- 159 PMSI". A PE is considered to be advertising its primary MS-PMSI in a 160 BGP S-PMSI A-D route if that route has the following properties: 162 - the double wild card selector (C-*,C-*) [MVPN_WILD] is specified 164 - the advertised S-PMSI is instantiated using one of the set of 165 techniques described in the next section. 167 3.2. Instantiating MS-PMSIs 169 There are a number of ways to instantiate MS-PMSIs. These are 170 specified in in the follow sub-sections. Additional methods of 171 instantiation may be added in the future. 173 3.2.1. Bidirectional P-Tunnels 175 An MS-PMSI be instantiated as a bidirectional P-tunnel. See 176 [MVPN_BIDIR] for the details of advertising bidirectional P-tunnels. 178 [MVPN_BIDIR] specifies two kinds of bidirectional P-tunnels (P- 179 tunnels that are BIDIR-PIM [BIDIR-PIM] multicast trees, or that are 180 MP2MP LSPs [MLDP] without PE distinguisher labels) that may only be 181 advertised by their "roots" (as defined in that document). It 182 follows that a PE may advertise such a P-tunnel as the instantiation 183 of its primary MS-PMSI only if that PE is the root of the P-tunnel. 185 If PE1, PE2, ..., PEn are using a MP2MP LSP with PE Distinguisher 186 labels to instantiate an MS-PMSI, the MP2MP LSP should be thought of 187 as instantiating n MS-PMSIs, each one being the primary MS-PMSI of 188 one of the PEs. A packet traveling on the MP2MP LSP is said to be 189 traveling PEi's primary MS-PMSI if it is carrying the PE 190 Distinguisher label that the root of the LSP has assigned to PEi. 192 3.2.2. Unidirectional P-Tunnels 194 For best efficiency, MS-PMSIs should be instantiated by bidirectional 195 P-tunnels. However, it is possible to instantiate MS-PMSIs as 196 unidirectional P-tunnels, and this can be useful in certain 197 circumstances. 199 3.2.2.1. PPMP LSPs 201 An MS-PMSI can be implemented as a Point-to-Point-to-Multipoint 202 (PPMP) LSP. (See, e.g, the "shared P2MP LSP" of [mLDP] section 3.) 203 The procedures for advertising a PPMP LSP in an S-PMSI A-D route are 204 as follows. 206 A new BGP attribute is defined, the "PPMP Label" attribute. This is 207 an optional transitive attribute defined as follows: 209 +---------------------------------+ 210 | MPLS Label (3 octets) | 211 +---------------------------------+ 213 This attribute may be carried by a BGP S-PMSI A-D route that is 214 advertising a primary MS-PMSI instantiated as a P2MP LSP. The PPMP 215 label is a downstream-assigned MPLS label assigned by the PE that 216 originated the route carrying this attribute. 218 A PPMP label MUST NOT be added to an S-PMSI A-D route UNLESS the 219 route contains a PTA identifying a P2MP LSP, and the route is origi- 220 nated by the root of the LSP. 222 The rules for transmitting packets on a PPMP LSP are as follows: 224 - The root of the LSP transmits normally, without using the PPMP 225 label. 227 - A PE which is not the root of the LSP transmits a packet on the 228 LSP as follows: 230 * it pushes the PPMP label onto the packet's label stack, then 232 * it unicasts the packet to the PE that is the root of the LSP; 233 this requires pushing another label onto the packet's label 234 stack. 236 When the packet is received (as a unicast) by the PE at root of the 237 LSP, the PPMP label will either be at the top of the label stack (if 238 penultimate hop popping is in use), or else will rise to the . The 239 PPMP label is then popped from the stack, and that PE processes 240 packet's label stack, recognizes the PPMP label, and as a result 241 retransmits the packet on the corresponding P2MP LSP. In addition, 242 the PE at the root of the P2MP processes the received packet as a 243 multicast packet in the context of the VPN corresponding to the PPMP 244 label. (The relationship between a PPMP label and a VPN is 245 established by the RTs carried by the S-PMSI A-D route that 246 advertised the PPMP label.) 248 Note that when an MS-PMSI is instantiated as a PPMP LSP, the PE that 249 transmits a given packet may receive it back. A PE MUST discard, 250 without processing, any packet it receives from the PPMP LSP if it 251 transmitted that packet to the PPMP LSP. As a result, the procedure 252 of instantiating an MS-PMSI as a PPMP LSP MUST NOT be used UNLESS 253 there is a method by which a PE can identify the packets it 254 transmitted. It is recommended to use this method only for 255 transmitting PIM control packets, rather than multicast data packets. 257 3.2.2.2. Sparse Mode ASM Groups 259 One way to instantiate an MS-PMSI is to use a set of PIM sparse mode 260 ASM groups. A PE advertises its primary MS-PMSI by sending an S-PMSI 261 A-D route whose PTA identifies a "PIM-SM Tree". Every PE would have 262 to advertise a PIM-SM tree with a distinct ASM ("Any Source 263 Multicast") group address. To transmit a packet on the primary 264 MS-PMSI of a particular PE, the packet would be encapsulated in GRE, 265 with the GRE header's IP source address being the IP address of the 266 transmitting PE, and the GRE header's IP destination address being 267 the group address that was advertised for that MS-PMSI. 269 Generally speaking, this is not an efficient method of instantiating 270 an MS-PMSI. However, it can be useful in certain circumstances, such 271 as the "hub and spoke" MVPN discussed in [MVPN_EXTRANET]. It can 272 also be useful as a transitional method of instantiating MS-PMSIs, 273 allowing MS-PMSIs to be used in a network even if that network has 274 not (yet) deployed native MPLS multicast techniques. 276 4. PIM over MS-PMSI 278 [MVPN] provides two alternative means of distributing C-multicast 279 routing information: PIM or BGP. Procedures for running PIM over 280 MI-PMSI are specified in that document. However, a number of 281 efficiencies can be obtained by running PIM instead over MS-PMSI. 282 The procedures for this are as follows. 284 Each PE that attaches to a given MVPN MUST originate an Intra-AS 285 I-PMSI A-D route that does NOT contain a PTA. Each such PE MUST also 286 advertise a primary MS-PMSI instantiated by one of the methods 287 described in the previous section. 289 If PE1 needs to direct a PIM Join/Prune message to PE2, PE1 MUST join 290 the PE2's primary MS-PMSI by joining the P-tunnel advertised in PE2's 291 corresponding S-PMSI A-D route. The PIM J/P messages MUST be sent 292 over that MS-PMSI. 294 If PE1 does not need to direct a PIM Join/Prune message to PE2, then 295 PE1 SHOULD NOT join the P-tunnel advertised in PE2's S-PMSI A-D 296 route, as PE1 will not be receiving any multicast data on that LSP. 297 In the "PIM over MI-PMSI" scheme of [MVPN], if PE1 attaches to a 298 given MVPN, the number of P-tunnels that it has to join for that MVPN 299 is on the order of the total number of PEs attached to that MVPN. In 300 the "PIM over MS-PMSI" scheme, the number of P-tunnels that PE1 has 301 to join is on the order of the total number of PEs attached to those 302 sites of the MVPN that contain multicast transmitters. In many 303 deployments, only a small proportion of a VPN's sites contain 304 multicast transmitters, in which case the MS-PMSI scheme can result 305 in a considerable reduction in the total number of P-tunnels. 307 Note that if PE1 and PE3 both need to send PIM Join/Prune messages to 308 PE2, then PE1 and PE3 both join PE2's primary MS-PMSI. As a result, 309 PE1 will see the Join/Prune messages that PE3 sends to PE2, and PE3 310 will see the one that PE1 sends to PE2. This allows such PIM 311 procedures as "join suppression" and "prune override" to work 312 normally, without impacting any PEs that do not send PIM Join/Prune 313 messages to PE2. 315 At some time after PE1 has joined the P-tunnel instantiating PE2's 316 primary MS-PMSI, PE1 may find that it no longer has any need to send 317 PIM J/P messages to PE2. PE1 SHOULD NOT immediately prune itself 318 from the P-tunnel, but SHOULD instead remain joined to the P-tunnel 319 for a configurable amount of time. An implementation MUST provide a 320 configurable parameter determining how long a PE remains joined to 321 the P-tunnel instantiating an MS-PMSI when that PE no longer has any 322 need to send PIM J/P messages on that tunnel. 324 Any PE that sends a PIM Join/Prune message on a given P-tunnel is 325 automatically considered to be a PIM adjacency of every PE that 326 receives the message on that P-tunnel. This implies that any PE 327 receiving the LSP MUST accept a PIM Join/Prune message on that 328 P-tunnel from any other PE, even if the PE that transmitted the 329 Join/Prune messages has not previously transmitted a PIM Hello. That 330 is, the "adjacency relationship" does not depend on the reception of 331 PIM Hellos. 333 However, there is no harm if Hellos are sent, as the suppression of 334 Hellos is only an optimization. This optimization, allowing a PIM 335 Join/Prune message from a given router to be accepted even if no 336 Hello from that router has been received, is often deployed in non- 337 MVPN scenarios, and would work even when MI-PMSIs are being used. 338 Also, PIM Hellos may be useful in certain environments for OAM 339 purposes. Therefore, it MUST be possible to configure a PE to allow 340 Hellos to be sent. Any PIM Hellos that PE1 sends MUST be sent on the 341 P-tunnel advertised in PE1's S-PMSI A-D route above. 343 Standard PIM procedures are used, except for: 345 - The above change in the adjacency maintenance procedures. 347 - Changes in the "RPF determination" or "RPF checking" procedures 348 as may be defined in [MVPN] or other documents extending or 349 enhancing MVPN procedures, such as [MVPN_EXTRANET]. 351 If an MS-PMSI is instantiated as a bidirectional P-tunnel, then the 352 data handling procedures of [MVPN_BIDIR] will prevent PIM from ever 353 seeing any packets that come from the wrong transmitter or that are 354 in the wrong partition; when such packets are received they are 355 discarded, rather than being passed to PIM's state machinery. As a 356 result, such packets do not cause Asserts to be generated. Other 357 standard PIM procedures, such as Join Suppression and Prune Override 358 may come into play, however. 360 If an MS-PMSI is instantiated as a PPMP tree, a PE that transmits a 361 Join/Prune message will receive it back. Any such message is easily 362 identified by its source address, and MUST be discarded. A PE only 363 transmits data packets on its primary MS-PMSI, and hence does not 364 receive them back. 366 All other MVPN-specific PIM procedures are as specified in [MVPN]. 368 5. IANA Considerations 370 This document specifies a new BGP optional transitive attribute, 371 "PPMP Label". A value must be assigned from the "BGP Path Attributes 372 Registry". 374 6. Security Considerations 376 There are no additional security considerations beyond those of 377 [MVPN] and [MVPN-BGP]. 379 7. Acknowledgments 381 The "PPMP" mechanism is similar to a mechanism that appeared in 382 earlier drafts of [MVPN], known as "unicasting to the root of a 383 shared tree"; this mechanism was discussed among the authors of 384 [MVPN]. 386 The possibility of using of sparse mode groups to instantiate MS- 387 PMSIs arose from a discussion with Yakov Rekhter. 389 8. Authors' Addresses 391 Arjen Boers 393 E-mail: arjen@boers.com 395 Yiqun Cai 396 Cisco Systems, Inc. 397 170 Tasman Drive 398 San Jose, CA, 95134 399 E-mail: ycai@cisco.com 401 Maria Napierala 402 AT&T Labs 403 200 Laurel Avenue, Middletown, NJ 07748 404 E-mail: mnapierala@att.com 406 Eric C. Rosen 407 Cisco Systems, Inc. 408 1414 Massachusetts Avenue 409 Boxborough, MA, 01719 410 E-mail: erosen@cisco.com 412 IJsbrand Wijnands 413 Cisco Systems, Inc. 414 De kleetlaan 6a Diegem 1831 415 Belgium 416 E-mail: ice@cisco.com 418 9. Normative References 420 [BIDIR-PIM] "Bidirectional Protocol Independent Multicast", Handley, 421 Kouvelas, Speakman, Vicisano, RFC 5015, October 2007 423 [MLDP] "Label Distribution Protocol Extensions for 424 Point-to-Multipoint and Multipoint-to-Multipoint Label Switched 425 Paths", Wijnands, Minei, Kompella, Thomas, RFC 6388, November 2011 427 [MVPN] "Multicast in MPLS/BGP IP VPNs", Rosen, Aggarwal, et. al., 428 draft-ietf-l3vpn-2547bis-mcast-10.txt, January 2010 430 [MVPN-BGP] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP 431 VPNs", Aggarwal, Rosen, Morin, Rekhter, 432 draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt, October 2009 434 [MVPN_BIDIR] "MVPN: Using Bidirectional P-Tunnels", Cai, Rosen, 435 Wijnands, Boers, draft-ietf-l3vpn-mvpn-bidir-01.txt, February 2012 437 [MVPN_WILD] "Wildcards in Multicast VPN Auto-Discovery Routes", 438 Rosen, Rekhter, Hendrickx, Qiu, draft-ietf-l3vpn-mvpn- 439 wildcards-01.txt, January 2012 441 [PIM] "Protocol Independent Multicast - Sparse Mode (PIM-SM): 442 Protocol Specification (Revised)", Fenner, Handley, Holbrook, 443 Kouvelas, RFC 4601, August 2006 445 [RFC2119] "Key words for use in RFCs to Indicate Requirement 446 Levels.", Bradner, March 1997 448 10. Informative References 450 [MVPN_EXTRANET] "MVPN: Extranets, Anycast-Sources, 'Hub & Spoke', 451 with PIM Control Plane", Cai, Rosen, Sharma, Wijnands, draft-rosen- 452 l3vpn-mvpn-extranet-04.txt, February 2012