idnits 2.17.1 draft-rekhter-mboned-mvpn-deploy-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 33. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 352. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 368. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 368. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 374. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-l3vpn-2547bis-mcast-bgp-04 == Outdated reference: A later version (-10) exists of draft-ietf-l3vpn-2547bis-mcast-06 -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Rahul Aggarwal (Juniper Networks) 3 Internet Draft Yakov Rekhter (Juniper Networks) 4 Expiration Date: December 2008 5 Intended Status: Informational 7 PIM/GRE Based MVPN Deployment Experience and Recommendations 9 draft-rekhter-mboned-mvpn-deploy-00.txt 11 Status of this Memo 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress". 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 IPR Disclosure Acknowledgement 30 By submitting this Internet-Draft, each author represents that any 31 applicable patent or other IPR claims of which he or she is aware 32 have been or will be disclosed, and any of which he or she becomes 33 aware will be disclosed, in accordance with Section 6 of BCP 79. 35 Abstract 37 Multicast VPN, based on the Virtual Router model using PIM with GRE 38 tunnels, has been in operation in production networks for several 39 years. This document describes some of the experiences gained from 40 implementation and deployment of such Multicast VPNs. Further it 41 describes the practices used by such deployments based on the 42 experience. 44 Specification of Requirements 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document are to be interpreted as described in RFC 2119 [RFC2119]. 50 1. Introduction 52 The first proposal for multicast support for BGP/MPLS IP VPNs 53 [RFC4364], informally known as "draft-rosen", was presented in San 54 Diego IETF, 2000. At that time multicast support was not in the L3VPN 55 WG charter. Since 2000 draft-rosen went through several revisions, 56 with the last revision informally known as draft-rosen-08. 58 At San Diego IETF in 2004 multicast support has been added to the 59 L3VPN WG charter. At the present moment L3VPN WG has several working 60 group documents that specify mechanisms for multicast support in 61 BGP/MPLS IP VPNs ([MVPN-ARCH], [BGP-MPLS-MVPN]). 63 At the present moment multi-vendor interoperable implementations are 64 known to exist only based on a particular version of draft-rosen, 65 informally known as draft-rosen-06, but not based on the later 66 version of draft-rosen - draft-rosen-08. 68 While the mechanisms described in draft-rosen-06 form a subset of the 69 mechanisms described in [MVPN-ARCH], the additional mechanisms 70 introduced in draft-rosen-08 are not part of the mechanisms described 71 in [MVPN-ARCH]. Specifically the mechanisms to support PIM-SSM for 72 Inclusive P-Tunnels and inter-AS operations option (B) specified in 73 draft-rosen-08 are not part of the mechanisms described in [MVPN- 74 ARCH]. The mechanisms to support PIM-SSM for Inclusive P-Tunnels and 75 inter-AS operations option (B) specified in [MVPN-ARCH] are not 76 interoperable with the corresponding mechanisms in draft-rosen-08. 78 While unicast BGP/MPLS IP VPNs solution is based on the aggregated 79 routing architecture [RFC4110], the approach taken by draft-rosen is 80 based on a completely different architecture, namely Virtual Routers 81 [RFC4110]. 83 The differences between unicast BGP/MPLS IP VPNs and draft-rosen are 84 not only in the architecture, but also in the mechanisms: 86 + While unicast BGP/MPLS IP VPNs use BGP to exchange (unicast) 87 VPN's routing information among PEs, draft-rosen uses PIM to 88 exchange (multicast) VPN's routing information among PEs. 90 + While unicast BGP/MPLS IP VPNs use MPLS in the data plane (with 91 GRE as an option for inter-PE tunnels), draft-rosen restricts the 92 data plane to just GRE or IP-in-IP tunnels. (While the draft 93 mentions MPLS as a possible encapsulation, the draft specifies no 94 details on how to support it). Moreover, in terms of 95 implementations multi-vendor implementations exist only for GRE, 96 but not for IP-in-IP. 98 + While unicast BGP/MPLS IP VPNs use LDP or RSVP-TE to set up 99 inter-PE MPLS tunnels, draft-rosen uses PIM for setting up (GRE- 100 based) inter-PE tunnels. 102 + While the control plane used by unicast BGP/MPLS IP VPNs is 103 decoupled from its data plane, the control plane and the data 104 plane of draft-rosen are coupled in a sense that exactly the same 105 inter-PE tunnels are used to exchange both control and data. 107 As a result, deploying draft-rosen requires a set of control plane 108 and data plane mechanisms among the PEs that are completely different 109 from what is required by (unicast) BGP/MPLS IP VPNs. 111 2. Control Plane Scalability Considerations 113 Use of the Virtual Router architecture by draft-rosen means that a 114 given VRF on a given PE has to maintain PIM adjacencies with every 115 other VRF belonging to that MVPN on every other PE. Moreover, these 116 adjacencies have to be maintained not on a per PE, but on a per MVPN, 117 per PE granularity. A PE also has to maintain PIM adjacencies with 118 all the locally connected CEs (and these adjacencies are not due to 119 the use of the Virtual Router architecture). However, as long as the 120 average number of a given MVPN sites connected to a given PE is less 121 than the average number of PEs that have sites of that MVPN, then on 122 a given PE the overhead of maintaining PIM adjacencies with other PEs 123 will dominate the overhead of PIM adjacencies between that PE and its 124 locally connected CEs. Note that this overhead grows with the number 125 of PEs in an MVPN, as well as with the number of MVPNs. 127 To illustrate the overhead consider an example where a PE has 1,000 128 VRFs, and each of these VRFs corresponds to an MVPN that on average 129 is present on 100 PEs. The average number of PIM adjacencies that the 130 PE would need to maintain with other PEs is 100,000. The average rate 131 of PIM Hellos that the PE would need to process is 3,300 per second. 133 3. Join and Prune Latency 135 One consequence of using unreliable transport for PE-PE MVPN 136 multicast routing infromation exchange with PIM is that if the first 137 PIM Join sent by a PE to another PE is lost, then this results in 138 Join latency of at least upto the duration of the PIM Join 139 retransmission. This duration is usually at least 30 seconds. Losing 140 subsequent PIM Joins may further increase this Join latency. 142 Similarly if the last PIM Prune sent by a PE to another PE is lost, 143 then this results in the receiver PEs receiving unwanted data until 144 the corresponding multicast state on the sender/upstream PE times 145 out, which, as estimated in [PORT], is roughly 3 minutes. That has 146 negative implications on the efficient use of bandwidth within the 147 Service Provider(s). 149 Moreover, if the last PIM Prune sent by a PE to another (upstream) PE 150 is lost, then this results in the upstream PE maintaining the 151 corresponding multicast state until that state times out, which as 152 estimated in [PORT] is roughly 3 minutes. 154 Additional issue of increased Join latency when switching to S-PMSIs 155 is described in the next section. 157 4. Possible packet losses when switching to S-PMSI 159 Signaling switching to S-PMSI is done by periodically (every 60 secs) 160 sending a UDP message that contains the identity of the provider 161 multicast tree used by an S-PMSI as well as the customer multicast 162 stream bound to that S-PMSI. 164 One consequence of using unreliable transport (UDP) for signaling 165 switching to S-PMSI is that if the first S-PMSI advertisement is 166 lost, then this results in losses of multicast data for up to 57 secs 167 (MDT-INTERVAL - MDT-DATA-DELAY). 169 Moreover, if all the PEs in a given MVPN do not always store all the 170 S-PMSI advertisements for that MVPN, irrespective of whether these 171 PEs have downstream receivers for the multicast traffic carried by 172 these S-PMSIs, then it may result in multicast data losses (Join 173 latency) on average of 30 secs and up to 60 secs (MDT-INTERVAL timer) 174 on the PEs. This is in the absence of any S-PMSI advertisement 175 losses. Losing an S-PMSI advertisement may further increase the 176 duration of the losses (increases this Join latency). 178 5. Limitations when Handling Anycast Customer RP (C-RP) 180 Large enterprises may have multiple data centers where Anycast RP's 181 and sources of multicast traffic are located. Such MVPN customers 182 might require multicast applications to be simultaneously sourced 183 from each data center and delivered via corresponding Anycast RP's to 184 different sets of branch locations. Each data center and each branch 185 location may be in its own MVPN site. 187 When an MVPN uses anycast RP, where several customer's RPs (C-RPs) 188 share the same anycast address and are reachable via more than one 189 PE, then with the mechanisms provided by draft-rosen for a given 190 customer's multicast group (C-G) at any given point in time only one 191 of these C-RPs can be used to deliver (multicast) traffic to 192 receivers in other sites of that MVPN. That eliminates one of the 193 main benefits of anycast RP - the ability to share load among 194 multiple RPs. 196 6. Limitations when Handling Multi-homed Multicast Sources 198 When an MVPN site contains a given multicast source, and the site is 199 connected to two or more PEs, then at any given point in time only 200 one of these PEs could be used to forward multicast traffic from the 201 source to the receivers in other sites of that MVPN. This is in 202 contrast to unicast, where unicast traffic could be forwarded to the 203 source via all of these PEs. 205 7. Mandatory I-PMSI 207 Mechanisms used by draft-rosen mandate that each MVPN must have its 208 own I-PMSI. This is even if most/all of the multicast data is sent 209 using S-PMSIs. The overhead of maintaining I-PMSI, both in the 210 control and in the data plane, is especially significant in the 211 inter-AS scenario, as in this scenario the number of point-to- 212 multipoint tunnels required for a single I-PMSI is equal to the 213 number of PEs that span that I-PMSI. 215 8. QoS 217 If a service provider uses DiffServ based QoS, the service provider 218 needs two different mechanisms for providing such QoS for its VPN 219 customers - one for unicast BGP/MPLS VPNs using MPLS and another for 220 multicast VPNs using draft-rosen. This is because the former uses 221 MPLS based DiffServ mechanisms such as mapping the MPLS EXP bits to 222 forwarding classes while the latter uses IP based DiffServ mechanisms 223 such as mapping the DSCP bits to forwarding classes. 225 Moreover, certain QoS mechanisms that are available for (unicast) 226 BGP/MPLS IP VPNs are not available for draft-rosen. Specifically, 227 MPLS Traffic Engineering and MPLS DiffServ Traffic Engineering that 228 are available for unicast VPN traffic are not available for draft- 229 rosen. 231 9. Protection/Restoration 233 Certain protection/restoration mechanisms that are available for 234 (unicast) BGP/MPLS IP VPNs are not available for draft-rosen. 235 Specifically, none of the MPLS Fast Re-route mechanisms that could be 236 used in conjunction with unicast VPN traffic are available for draft- 237 rosen. 239 10. Security Considerations 241 The Security Considerations section of [RFC4797] discusses security 242 issues in the context of unicast BGP/MPLS IP VPNs when PE-PE tunnels 243 are realized via GRE. These considerations are applicable in the 244 context of [draft-rosen] as well. However, draft-rosen presents 245 additional security considerations, above and beyond of what is 246 covered in [RFC4797]. The following describes some of them. 248 Inability to restrict joining an I-PMSI (Default MDT) of a given MVPN 249 to only the PEs that have VRFs of that MVPN may result in (a) leaking 250 multicast traffic originated within that MVPN to the receivers that 251 are not suppose to be part of that MVPN, and (b) various forms of 252 packet spoofing, as described below. Once an attacker joins an I-PMSI 253 of a given MVPN, the attacker, in addition to the ability to receive 254 multicast traffic originated within that MVPN, can also create 255 attacks based on packet spoofing. 257 The implications of packet spoofing in the context of draft-rosen are 258 more significant than in the context of [RFC4797], as in the context 259 of [RFC4797] spoofing can impact only the data traffic, while in the 260 context of draft-rosen spoofing can impact not only the data, but 261 also the control traffic associated with the exchange of MVPN routing 262 information among PEs. This is because in the context of draft-rosen 263 the same GRE tunnels that are used to exchange MVPN data traffic 264 among PEs are also used to exchange MVPN multicast routing 265 information among PEs. 267 Securing control traffic associated with the exchange of MVPN routing 268 information among PEs by applying security mechanisms specified in 269 [RFC4601] to PIM that is used to exchange MVPN routing information 270 among PEs is problematic for the following reasons. 272 One option specified in [RFC4601] states that "A PIM router SHOULD 273 provide an option to limit the set of neighbors from which it will 274 accept Join/Prune, Assert, and Hello messages. Either static 275 configuration of IP addresses or an IPsec security association may be 276 used.". Use of the first option, static configuration, in the context 277 of draft-rosen to authenticate PIM messages used to exchange MVPN 278 routing information among PEs may be problematic, as it would require 279 a given PE for each MVPN present on the PE to have an apriori 280 knowledge of all the other PEs with whom the PE has at least one MVPN 281 in common. That gets especially problematic in the inter-provider 282 scenario where PEs in different providers may need to become PIM 283 neighbors, as it would require a provider to share this information 284 with other providers. 286 Another option specified in [RFC4601] is to use IPsec. As stated in 287 [RFC4601] "To use IPsec, the administrator of a PIM network 288 configures each PIM router with one or more security associations 289 (SAs) and associated Security Parameter Indexes (SPIs) that are used 290 by senders to authenticate PIM protocol messages and are used by 291 receivers to authenticate received PIM protocol messages." However, 292 neither [RFC4601], nor draft-rosen provide an automated mechanism for 293 establishing such security associations. In fact [RFC4601] "assumes 294 that manual configuration of SAs is performed". Use of this option 295 in the context of draft-rosen to authenticate PIM messages used to 296 exchange MVPN routing information among PEs is problematic, as it 297 involves manual configuration of SAs on PEs that have at least one 298 MVPN in common. It is especially problematic in the inter-provider 299 scenario where it may involve PEs in different providers. 301 At the CE-PE interfaces each PE must install packet filters to filter 302 out any UDP traffic on port 3232 that the PE may receive from any of 303 its attached CEs, as UDP port 3232 is used for the S-PMSI messages 304 exchanged among PEs. Failure to filter out such traffic can cause the 305 creation of extra multicast states on the Service Providers routers. 307 Additional security considerations that are applicable in the context 308 of draft-rosen are described in [RFC4023]. 310 11. IANA Considerations 312 This document does not require any action on the part of IANA. 314 12. Intellectual Property Statement 316 The IETF takes no position regarding the validity or scope of any 317 Intellectual Property Rights or other rights that might be claimed to 318 pertain to the implementation or use of the technology described in 319 this document or the extent to which any license under such rights 320 might or might not be available; nor does it represent that it has 321 made any independent effort to identify any such rights. Information 322 on the procedures with respect to rights in RFC documents can be 323 found in BCP 78 and BCP 79. 325 Copies of IPR disclosures made to the IETF Secretariat and any 326 assurances of licenses to be made available, or the result of an 327 attempt made to obtain a general license or permission for the use of 328 such proprietary rights by implementers or users of this 329 specification can be obtained from the IETF on-line IPR repository at 330 http://www.ietf.org/ipr. 332 The IETF invites any interested party to bring to its attention any 333 copyrights, patents or patent applications, or other proprietary 334 rights that may cover technology that may be required to implement 335 this standard. Please address the information to the IETF at ietf- 336 ipr@ietf.org. 338 13. Copyright Notice 340 Copyright (C) The IETF Trust (2008). 342 This document is subject to the rights, licenses and restrictions 343 contained in BCP 78, and except as set forth therein, the authors 344 retain all their rights. 346 This document and the information contained herein are provided on an 347 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 348 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 349 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 350 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 351 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 352 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 354 14. Disclaimer of validity: 356 The IETF takes no position regarding the validity or scope of any 357 Intellectual Property Rights or other rights that might be claimed to 358 pertain to the implementation or use of the technology described in 359 this document or the extent to which any license under such rights 360 might or might not be available; nor does it represent that it has 361 made any independent effort to identify any such rights. Information 362 on the procedures with respect to rights in RFC documents can be 363 found in BCP 78 and BCP 79. Copies of IPR disclosures made to the 364 IETF Secretariat and any assurances of licenses to be made available, 365 or the result of an attempt made to obtain a general license or 366 permission for the use of such proprietary rights by implementers or 367 users of this specification can be obtained from the IETF on-line IPR 368 repository at http://www.ietf.org/ipr. 370 The IETF invites any interested party to bring to its attention any 371 copyrights, patents or patent applications, or other proprietary 372 rights that may cover technology that may be required to implement 373 this standard. Please address the information to the IETF at ietf- 374 ipr@ietf.org. 376 15. Acknowledgements 378 We would like to thank Maria Napierala for pointing to the problems 379 with draft-rosen of supporting MVPN customers who use Anycast RP, and 380 MVPN customers who have (multicast) sources in multihomed sites. 382 Many thanks to Leonard Giuliano for his review and comments. 384 16. Normative References 386 [RFC2119] "Key words for use in RFCs to Indicate Requirement 387 Levels.", Bradner, RFC2119, March 1997. 389 17. Non-normative References 391 [BGP-MPLS-MVPN] Aggarwal, R., Rosen, E., Morin, T., Rekhter, Y., "BGP 392 Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", draft- 393 ietf-l3vpn-2547bis-mcast-bgp-04.txt 395 [MVPN-ARCH] Rosen, E., Aggarwal, R., "Multicast in MPLS/BGP IP VPNs" 396 draft-ietf-l3vpn-2547bis-mcast-06.txt 398 [PORT] Farinacci, D., et al., "A Reliable Transport Mechanism for 399 PIM", draft-farinacci-pim-port-01.txt 401 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS 402 in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005. 404 [RFC4110] Callon, R., Suzuki, M., "A Framework for Layer 3 Provider- 405 Provisioned Virtual Private Networks (PPVPNs)", RFC4110, July 2005 407 [RFC4364] Rosen, E., Rekhter, Y., "BGP/MPLS IP Virtual Private 408 Networks (VPNs)", RFC4364, February 2006 410 [RFC4601], Fenner. B., et. al, "Protocol Independent Multicast - 411 Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC4601, 412 August 2006 414 [RFC4797] Rekhter, Y., Bonica, R., Rosen, E., "Protocol Independent 415 Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", 416 RFC4797, January 2007 418 18. Author Information 420 Rahul Aggarwal 421 Juniper Networks, Inc. 422 e-mail: rahul@juniper.net 424 Yakov Rekhter 425 Juniper Networks, Inc. 426 e-mail: yakov@juniper.net