idnits 2.17.00 (12 Aug 2021) /tmp/idnits15068/draft-ycai-mboned-mvpn-pim-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 469. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 462. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 478. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 485. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 491. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** An RFC 3978, Section 5.1 paragraph was found, but not on the first page, as required. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 65 instances of too long lines in the document, the longest one being 1 character in excess of 72. 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.) -- The document date (November 2007) is 5300 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-l3vpn-2547bis-mcast has been published as RFC 6513 == Outdated reference: A later version (-03) exists of draft-sdry-bmwg-mvpnscale-02 -- Obsolete informational reference (is this intentional?): RFC 4601 (ref. 'Fenner') (Obsoleted by RFC 7761) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Yiqun Cai 3 Internet Draft Mike McBride 4 Intended Status: Informational Chris Hall 5 Expires: May 2008 Maria Napierala 7 November 2007 9 PIM Based MVPN Deployment Recommendations 11 draft-ycai-mboned-mvpn-pim-deploy-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 Multicast VPN, based on pre-standard drafts, has been in operation in 43 production networks for many years. This document describes some of 44 the practices and experiences gained from implementation and 45 deployment of MVPN using PIM with GRE tunnels. It is informational 46 only. 48 Table of Contents 50 1 Introduction ....................................... 3 51 2 Implementation ..................................... 3 52 2.1 RPF ................................................ 3 53 2.2 MTU ................................................ 4 54 2.3 EIBGP Load Balancing ............................... 4 55 2.4 MTRACE ............................................. 5 56 3 Operational Experience ............................. 5 57 3.1 Multicast VPN Design Considerations ................ 5 58 3.2 PIM Modes For MI-PMSI .............................. 6 59 3.2.1 PIM-SSM for MI-PMSI ................................ 6 60 3.2.2 ASM for MI-PMSI .................................... 6 61 3.3 PIM Modes For S-PMSI ............................... 7 62 3.4 CE to PE PIM Modes ................................. 7 63 3.5 Timer Alignment .................................... 8 64 3.6 Addressing ......................................... 8 65 3.7 Filtering .......................................... 8 66 3.8 Scalability ........................................ 9 67 3.9 QOS ................................................ 9 68 4 Security Considerations ............................ 10 69 5 Iana Considerations ................................ 10 70 6 Acknowledgments .................................... 10 71 7 Normative References ............................... 10 72 8 Informative References ............................. 11 73 9 Authors' Addresses ................................. 11 74 10 Full Copyright Statement ........................... 11 75 11 Intellectual Property .............................. 12 77 1. Introduction 79 Multicast support for L3VPN based on RFC2547 [2547bis] was first 80 presented in San Diego IETF, 2000. It had not been included in the 81 charter of L3VPN (formerly PPVPN) working group until San Diego IETF 82 in 2004 and stayed on as an individual submission. During the time, 83 the draft, known as "rosen-draft", continued to evolve as pre- 84 standards work. Several vendors provided implementations based on 85 this draft. Service providers began deploying this mvpn solution in 86 production networks. 88 Once the working group officially accepted the challenge to define a 89 solution or solutions to support multicast, several proposals have 90 been suggested. They are now captured in [MVPN] which forms a base 91 for future standards work. 93 This document provides MVPN deployment experience based solely on the 94 original PIM and GRE based MVPN solution. This solution is now 95 outlined as one of the options in the standards track [MVPN] 96 document. 98 In this document, we describe some of the lessons learned from 99 implementing and deploying MVPN. We hope it will benefit 100 implementors as well network operators looking to deploy MVPN 101 services. Throughout the document, where the term "MVPN" is used, the 102 reference is to the original MVPN deployment based upon the Rosen-08 103 GRE tunnels. 105 2. Implementation 107 There are two known MVPN implementations: IOS from Cisco and JunOS 108 from Juniper Networks. Contact these vendors for implementation 109 details beyond what is provided in this draft. The following sections 110 describe common mvpn deployment considerations. 112 2.1. RPF 114 [MVPN] specifies that the source address of any PIM packets that a PE 115 router generates over the MDT tunnel must be the same as the BGP 116 nexthop for updates originated by the PE router for all multicast 117 traffic sources existing in the site. Otherwise, a PE router will not 118 resolve the RPF neighbour towards the source connected to a remote PE 119 router. 121 A PE needs to have a particular IP address which it uses in both the 122 IP source address field of the PIM packet and the next hop field of 123 the BGP updates. If this requirement is overlooked, RPF 124 determination may fail. This has caused interoperability problems in 125 the past and implementors should be careful about it in the future. 127 2.2. MTU 129 When GRE encapsulation is used in the core, 24 bytes are added to the 130 IP packets generated in the VPNs. Due to the lack of a path MTU 131 discovery mechanism for multicast, a PE router may have to fragment 132 the incoming packets. 134 The best practice is to fragment the packets before performing any 135 GRE encapsulation. This spares the egress PE routers from 136 reassembling the fragments, and leaves that for the end-systems. 137 This doesn't work if the "DF" bit is set in the original packet since 138 the packet will be dropped. Its best to ensure that the backbone does 139 not have any links with a 1500 byte MTU. 141 It is further recommended to read Section 5.1 of [Worster] for a more 142 detailed look at preventing fragmentation and reassembly. 144 2.3. EIBGP Load Balancing 146 External and Internal Border Gateway Protocol (eiBGP) load sharing is 147 an enhancement to BGP that enables load sharing over parallel links 148 between CE and PE routers. EIBGP enables service providers to share 149 customer traffic loads over parallel paths within an MPLS core 150 network. 152 When EIBGP load balancing is enabled on all PE routers, we have seen 153 that multicast RPF check, inside the VRF, may be affected if the path 154 towards the source resolves via iBGP. The best practice is to ensure 155 that, when both eBGP and iBGP routes are present, multicast RPF 156 selects eBGP paths only. 158 Example: 160 ------ PE1 161 / 162 source -- CE 163 \ 164 ------ PE2 166 With EIBGP configured, PE1 will have two paths towards the source, 167 one directly via the CE using eBGP, and one via PE2 using iBGP. 169 By default PIM will pick the neighbor with the highest IP address. If 170 this happens to be PE2, the RPF check will fail as it will use the 171 global table. 173 A workaround would be either a static mroute on PE1 pointing towards 174 the CE router, or make sure that CE has a higher ip address than PE2. 175 The better solution is additional logic in the RPF code that where 176 EIBGP is used the EBGP link is preferred. 178 2.4. MTRACE 180 MTRACE is a tool that allows a network operator to obtain multicast 181 routing information from routers and to explore a path to the source 182 of the traffic or the RP. 184 Since there is no security mechanism embedded in MTRACE, some service 185 providers express concern when the mtrace packet has to traverse the 186 PE routers in order to obtain the full information. 188 Vendors have their own mechanisms to remove, or hide, certain fields 189 in the MTRACE packets in order to satisfy the needs of their 190 customers. We need to define a better mechanism for MTRACE in an MVPN 191 environment. 193 3. Operational Experience 195 3.1. Multicast VPN Design Considerations 197 When deploying a multicast VPN service, providers try to optimize 198 multicast traffic distribution and delays while reducing the amount 199 of state. The following considerations have given MVPN providers 200 direction in their MVPN deployment: 202 + Core multicast routing states should typically be kept to a 203 minimum 205 + MVPN packet delays should typically be the same as unicast 206 traffic 208 + Data should typically be sent only to PEs with interested 209 receivers 211 3.2. PIM Modes For MI-PMSI 213 The MI-PMSI ("Default-MDT" of pre-standard drafts) is used to build 214 an overlay network connecting all PE routers attaching to the same 215 MVPN. 217 Service providers have implemented PIM-SM and PIM-SSM instantiated 218 MI-PMSI in production networks. The majority of MI-PMSI deployments 219 are using PIM-SM using static Anycast RP with MSDP assignment. But a 220 dynamic RP discovery protocol, such as BSR, is also being used. 222 The decision to deploy either PIM-SM or PIM-SSM is based on the 223 following concerns, 225 + the number of multicast routing states 227 + the overhead of managing the RP if PIM-SM is used 229 + the difference of forwarding delay between shared tree and source 230 trees 232 3.2.1. PIM-SSM for MI-PMSI 234 Optimal MVPN forwarding is most easily achievable when there is a 235 single multicast tree per MVPN per PE. Such trees are naturally built 236 with PIM-SSM since it permits the PE to directly join a source tree 237 for an MDT. With PIM-SSM, no Rendezvous Points are required. With 238 SSM, however, all PEs on an MVPN tree need to maintain source state. 239 Each PE, which is participating in MVPN, is a source. Unless VPN 240 customers locate their multicast sources within a constrained set of 241 sites, SSM may become a scalability concern in the service providers 242 network. 244 3.2.2. ASM for MI-PMSI 246 One solution to minimize the amount of multicast state in an MVPN 247 environment is to configure PIM-SM or BIDIR PIM to stay on the shared 248 tree. With shared trees, multicast state scalability is no longer a 249 function of the number of PE's but rather of the number of VPNs. 251 The scale benefit of shared trees comes at the cost of less efficient 252 multicast distribution. MVPN providers use the MI-PMSI to achieve 253 bandwidth optimality. MVPN providers may address the sub-optimality 254 of shared tree forwarding by deploying an RP at the best location for 255 each VPN. Such an assignment would be based on the VPN source 256 locations, something which may be difficult to maintain. 258 3.3. PIM Modes For S-PMSI 260 The S-PMSI ("Data MDT" of pre-standard drafts) has also been widely 261 deployed by service providers. While both PIM-SM and PIM-SSM are 262 used, PIM-SSM is the more widely deployed, and recommended, S-PMSI 263 tree building model. The majority of S-PMSI deployments today are 264 using SSM since the source address is included in the PIM Hello 265 packet sent from the source PE. 267 MVPN providers deploy the S-PMSI to achieve optimal bandwidth usage, 268 especially when SSM is deployed as well. S-PMSIs are optimized for 269 active sources and receivers and triggered per (S,G) for a subset of 270 (S,G) of a given VPN. Since S-PMSIs are triggered by (S,G) states in 271 a VPN, they could increase the amount of multicast states in an MVPN 272 network. 274 The decision to switch from MI-PMSI to S-PMSI is always made by the 275 ingress PE based upon the traffic load exceeding a configurable 276 threshold. 278 3.4. CE to PE PIM Modes 280 The PIM protocols that are deployed within the customer VPN are 281 independent of the PIM Protocols in use within the Provider core. 282 Customers can choose to deploy PIM-DM, PIM-SM, Bidir, or SSM. 284 With SM or Bidir, customers may choose to deploy the RP on either a 285 PE or CE router. It is generally recommended to have a CE router 286 serve as the RP. This is done primarily to avoid an increase in 287 customer/provider interaction on matters such as the integration of 288 the PE/RP into the customer chosen RP discovery mechanism and to 289 avoid any additional burden on a busy PE router. While RP deployment 290 is most commonly performed on CE routers, we have seen RPs deployed 291 successfully on PE as well as CE routers. 293 If a customer desires to have a provider managed RP, they should 294 consider requesting the service provider manage a CE and have it 295 serve as the RP. To avoid managing an RP altogether, SSM should be 296 deployed. 298 3.5. Timer Alignment 300 When PIM-SM is used in an SP's core MVPN environment, some 301 interesting observations were made. When BSR, for example, is used in 302 the service provider network, to discover RPs in the provider tunnel, 303 it takes more than 3 minutes to detect the failure of the RP if the 304 default timer is used. During the window, PIM Hellos originated by 305 C-PIM instances will be dropped, which cause PIM adjacencies to be 306 torn down. But since the default PIM Hello timer is 30 seconds, C- 307 PIM instance on a PE router detects an outage much faster than the 308 P-PIM instance on the same PE router. 310 This is a factor to be considered when choosing the protocol for RP 311 redundancy and fast failover. One option, for fast failover, is to 312 use BSR only for RP discovery and then utilize Anycast-RP for RP 313 redundancy. 315 3.6. Addressing 317 It has become general practice to use 239/8 private address space 318 when assigning address space to mvpn's. This helps to prevent vpn 319 traffic from being sent outside the mvpn core. When SSM is used, 320 239.232/16 addressing is the common practice according to [Meyer], 321 Administratively Scoped IP Multicast. Operators typically deploy an 322 addressing tool to manage their addresses. 324 This addressing practice can also be used to prevent non-VPN traffic, 325 originating outside the SP boundaries, from entering a VPN. 327 The reader should also reference section 11.5.4 of the [MVPN] draft 328 entitled "Avoiding Conflict with Internet Multicast". 330 3.7. Filtering 332 Filtering at the SP boundaries is needed to prevent VPN security 333 violations. It may be necessary to modify these deployed filters to 334 permit GRE and possibly UDP port 3232. UDP port 3232 is the UDP port 335 used for the S-PMSI Join messages. 337 3.8. Scalability 339 PIM retransmission overhead on a given MI-PMSI increases in linear 340 proportion to any increase in the number of PEs that join the MI- 341 PMSI. The overhead also increases in linear proportion with an 342 increase in the number of J/P messages received from the CEs. 344 There have been no scaling issues with current deployments of MVPN. 345 Current MVPN deployments consist of up to a few hundred sites per 346 MVPN. The number of PE's participating in a MI-PMSI continues to 347 increase as customers extend the multicast group participation to 348 additional VPN sites. There are unicast VPN customers with several 349 thousand sites. These sites are gradually becoming multicast enabled. 350 The number of J/P messages received from CEs will also increase over 351 time. 353 At some level of scaling of the MI-PMSI, PIM Hello's and J/P messages 354 will become a scaling issue. The scaling point at which these 355 messages become a real operational problem is not clear. Empirical 356 field data shows they do not affect the broad range of MVPN 357 deployments today. MVPN is scalable as specified across a wide range 358 of deployments. 360 Some analysis is needed to clarify at what operational level PIM 361 messages do become a problem. The L3VPN WG has gathered requirements 362 information in [MORIN]. A benchmarking draft [DRY] has been submitted 363 to the BMWG to provide consistent MVPN test methodology. The PIM WG 364 is evaluating methods to decrease PIM messages when this becomes of 365 operational value. Extensions to PIM such as PIM J/P Acks and TCP 366 based approaches are being evaluated by the working group. 368 Increasing the Hello timer and increasing the periodic join/prune 369 timer may also help in future MVPN scaling. Doing so, however, may 370 affect join and leave latency in times when control messages are 371 lost. OAM, to verify the health of the data and control paths, would 372 also be affected if the Hello timer were increased or removed 373 altogether. 375 3.9. QOS 377 Deployments of MVPN, that have deployed QOS, typicall use the same 378 QOS mechanisms for the MVPN GRE header that they would use for their 379 other data traffic. VPN customers may want to separate the queuing of 380 multicast data from unicast data. Service Providers are extending 381 their QOS portfolio to support more classes of service to allow for 382 better separation of multicast and unicast traffic. Enhanced QOS 383 mechanisms support applications with short bursts but which require 384 bounded delay (such as video streaming). Since multicast (UDP) 385 traffic might not be subject to the same drop behavior as TCP 386 traffic, QOS profiles support Weighted Random Early Detection (WRED) 387 treatment. 389 4. Security Considerations 391 The use of GRE encapsulations and IP Multicast has certain security 392 implications. As discussed in [Farinacci], security in a network 393 using GRE should be relatively similar to security in a normal IPv4 394 network. And Section 6 of [Fenner] clearly outlines the various 395 security concerns related to PIM and how to use IPsec to secure the 396 protocol. 398 5. Iana Considerations 400 This document does not require any action on the part of IANA. 402 6. Acknowledgments 404 We'd like to thank Dino Farinacci, Yuji Kamite, Hitoshi Fukuda and 405 Eric Rosen for their feedback on this draft. 407 7. Normative References 409 [2547bis] "BGP/MPLS VPNs", Rosen, Rekhter, et. al., February 2006, 410 RFC 4364 412 [MVPN] "Multicast in MPLS/BGP IP VPNs", Rosen, Aggarwal, July 2007, 413 draft-ietf-l3vpn-2547bis-mcast-05.txt 415 8. Informative References 417 [MORIN] T. Morin, "Requirements for Multicast in L3 Provider- 418 Provisioned VPNs", RFC 4834 420 [DRY] S. Dry, "Multicast VPN Scalability Benchmarking", draft-sdry- 421 bmwg-mvpnscale-02.txt 423 [Meyer] D. Meyer, "Administratively Scoped IP Multicast". RFC 2365 425 [Farinacci] D. Farinacci, "Generic Routing Encapsulation (GRE)". RFC 426 2784 428 [Fenner] B. Fenner, "Protocol Independent Multicast - Sparse Mode 429 (PIM-SM)". RFC 4601. 431 [Worster] T. Worster, "Encapsulating MPLS in IP or Generic Routing 432 Encapsulation (GRE)" RFC 4023. 434 9. Authors' Addresses 436 Yiqun Cai 437 ycai@cisco.com 439 Mike McBride 440 mmcbride@cisco.com 442 Chris Hall 443 chall@sprint.net 445 Maria Napierala 446 mnapierala@att.com 448 10. Full Copyright Statement 450 Copyright (C) The IETF Trust (2007). 452 This document is subject to the rights, licenses and restrictions 453 contained in BCP 78, and except as set forth therein, the authors 454 retain all their rights. 456 This document and the information contained herein are provided on an 457 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 458 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 459 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 460 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 461 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 462 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 464 11. Intellectual Property 466 By submitting this Internet-Draft, each author represents that any 467 applicable patent or other IPR claims of which he or she is aware 468 have been or will be disclosed, and any of which he or she becomes 469 aware will be disclosed, in accordance with Section 6 of BCP 79. 471 The IETF takes no position regarding the validity or scope of any 472 Intellectual Property Rights or other rights that might be claimed to 473 pertain to the implementation or use of the technology described in 474 this document or the extent to which any license under such rights 475 might or might not be available; nor does it represent that it has 476 made any independent effort to identify any such rights. Information 477 on the procedures with respect to rights in RFC documents can be 478 found in BCP 78 and BCP 79. 480 Copies of IPR disclosures made to the IETF Secretariat and any 481 assurances of licenses to be made available, or the result of an 482 attempt made to obtain a general license or permission for the use of 483 such proprietary rights by implementers or users of this 484 specification can be obtained from the IETF on-line IPR repository at 485 http://www.ietf.org/ipr. 487 The IETF invites any interested party to bring to its attention any 488 copyrights, patents or patent applications, or other proprietary 489 rights that may cover technology that may be required to implement 490 this standard. Please address the information to the IETF at ietf- 491 ipr@ietf.org.