idnits 2.17.1 draft-morin-l3vpn-mvpn-considerations-02.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 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1072. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1083. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1090. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1096. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 407 has weird spacing: '... or the us...' -- 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 25, 2008) is 5877 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC4364' is mentioned on line 746, but not defined == Outdated reference: A later version (-10) exists of draft-ietf-l3vpn-2547bis-mcast-06 == Outdated reference: A later version (-15) exists of draft-rosen-vpn-mcast-08 == Outdated reference: A later version (-10) exists of draft-ietf-pim-sm-linklocal-02 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Morin, Ed. 3 Internet-Draft France Telecom R&D 4 Intended status: Informational B. Niven-Jenkins, Ed. 5 Expires: August 28, 2008 BT 6 Y. Kamite 7 NTT Communications 8 R. Zhang 9 BT 10 N. Leymann 11 Deutsche Telekom 12 February 25, 2008 14 Considerations about Multicast for BGP/MPLS VPN Standardization 15 draft-morin-l3vpn-mvpn-considerations-02 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on August 28, 2008. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2008). 46 Abstract 48 The current proposal for multicast in BGP/MPLS includes multiple 49 alternative mechanisms for some of the required building blocks of 50 the solution. The aim of this document is to leverage previously 51 documented requirements to identify the key elements and help move 52 forward solution design, toward the definition of a standard having a 53 well defined set of mandatory procedures. The different proposed 54 alternative mechanisms are examined in the light of requirements 55 identified for multicast in L3VPNs, and suggestions are made about 56 which of these mechanisms standardization should favor. Issues 57 related to existing deployments of early implementations are also 58 addressed. 60 Requirements Language 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in [RFC2119]. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Examining alternatives mechanisms for MVPN functions . . . . . 4 71 3.1. MVPN auto-discovery . . . . . . . . . . . . . . . . . . . 4 72 3.2. S-PMSI Signaling . . . . . . . . . . . . . . . . . . . . . 6 73 3.3. PE-PE Transmission of C-Multicast Routing . . . . . . . . 8 74 3.3.1. PE-PE signalling scalability . . . . . . . . . . . . . 8 75 3.3.2. P-routers scalability . . . . . . . . . . . . . . . . 10 76 3.3.3. Impact of C-multicast routing on Inter-AS 77 deployments . . . . . . . . . . . . . . . . . . . . . 10 78 3.3.4. Security and robustness . . . . . . . . . . . . . . . 11 79 3.3.5. C-multicast VPN join latency . . . . . . . . . . . . . 12 80 3.3.6. Architectural considerations . . . . . . . . . . . . . 13 81 3.3.7. Conclusion on C-multicast routing . . . . . . . . . . 14 82 3.4. Encapsulation techniques for P-multicast trees . . . . . . 15 83 3.5. Inter-AS deployments options . . . . . . . . . . . . . . . 16 84 4. Co-located RPs . . . . . . . . . . . . . . . . . . . . . . . . 18 85 5. Existing deployments . . . . . . . . . . . . . . . . . . . . . 19 86 6. Summary of recommendations . . . . . . . . . . . . . . . . . . 20 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 89 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 90 10. Informative References . . . . . . . . . . . . . . . . . . . . 21 91 Appendix A. Handling the PIM routing processing load load . . . . 22 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 93 Intellectual Property and Copyright Statements . . . . . . . . . . 25 95 1. Introduction 97 The current proposal for multicast in BGP/MPLS 98 [I-D.ietf-l3vpn-2547bis-mcast] includes multiple alternative 99 mechanisms for some of the required building blocks of the solution. 100 However, it does not identify the core set of mechanisms which must 101 be implemented in order to ensure interoperability. This may lead to 102 a situation where implementations may support different subsets of 103 the available optional mechanisms leading to implementations that do 104 not interoperate. 106 The aim of this document is to leverage the already expressed 107 requirements [RFC4834] to identify the mechanisms that the authors 108 believe are good candidates for being part of a core set of mandatory 109 mechanisms which can be used to provide a base for interoperable 110 solutions. 112 This document will go through the different building blocks of the 113 solution and provide the authors' recommendations as to which 114 mechanisms the authors' favor for each building block, while 115 considering the requirements already defined and the goal of a fully- 116 interoperable standard. 118 Considering the history of the multicast VPN proposals and 119 implementations, the authors also consider it useful to discuss how 120 existing deployments of early implementations 121 [I-D.rosen-vpn-mcast][I-D.raggarwa-l3vpn-2547-mvpn] can fit in the 122 picture, and provide suggestions in this respect. 124 2. Terminology 126 Please refer to [I-D.ietf-l3vpn-2547bis-mcast] and [RFC4834]. 128 3. Examining alternatives mechanisms for MVPN functions 130 3.1. MVPN auto-discovery 132 Section 5.2.10 of [RFC4834] states "The operation of a multicast VPN 133 solution SHALL be as light as possible and providing automatic 134 configuration and discovery SHOULD be a priority when designing a 135 multicast VPN solution. Particularly the operational burden of 136 setting up multicast on a PE or for a VR/VRF SHOULD be as low as 137 possible". 139 The current solution document [I-D.ietf-l3vpn-2547bis-mcast] 140 addresses this requirement by proposing two different mechanisms for 141 MVPN auto-discovery: 143 1. BGP-based auto-discovery (described in section 4). 145 2. Discovery using PIM running on a MI-PMSI implemented with a 146 shared tree using multicast ASM, or MP2MP LDP with the same 147 common tree identifier configured in all VRFs of an MVPN. 149 It is the recommendation of the authors that BGP-based auto-discovery 150 is the preferred solution for auto-discovery and should be supported 151 by all implementations while PIM/shared-tree based auto-discovery 152 should be optionally considered for migration purpose only. 154 Part of the rationale for this recommendation is also based on 155 section 5.2.10 of [RFC4834] which states "as far as possible, the 156 design of a solution SHOULD carefully consider the number of 157 protocols within the core network: if any additional protocols are 158 introduced compared with the unicast VPN service, the balance between 159 their advantage and operational burden SHOULD be examined 160 thoroughly". 162 BGP is the auto-discovery protocol used in unicast (RFC4364) VPNs and 163 therefore the use of BGP-based auto-discovery within multicast VPNs 164 avoids the introduction of an additional auto-discovery protocol that 165 would require additional OAM processes and tools. Service providers 166 with deployed unicast (RFC4364) VPNs already have extensive 167 deployment and operations experience of using BGP as an auto- 168 discovery protocol including OAM processes and tools. Such processes 169 and tools will require modifications in order to support multicast 170 auto-discovery but those modifications are anticipated to be less 171 than those required to develop new processes and tools for a specific 172 auto-discovery protocol. Additionally, BGP supports MD5 173 authentication of its peers for additional security. In contrast, 174 there are no obvious authentication mechanisms to secure PIM 175 communications in any known implementation. 177 Furthermore, PIM based discovery is only applicable to deployments 178 using a shared tree on an MI-PMSI, whereas BGP-based auto-discovery 179 does not place any restrictions on the type of multicast trees that 180 can be used. BGP-based auto-discovery is independent of the type of 181 P-multicast tree used thus satisfying the requirement in section 182 5.2.4.1 of [RFC4834] that "a multicast VPN solution SHOULD be 183 designed so that control and forwarding planes are not 184 interdependent". Additionally, it is to be noted that a number of 185 service providers have chosen to use SSM-based trees for the default 186 MDTs within their current deployments, therefore relying already on 187 BGP-based auto-discovery. 189 When shared trees are used, the use of BGP auto-discovery would allow 190 inconsistencies in the addresses/identifiers used for the shared 191 trees to be detected (e.g. the same shared tree identifier being used 192 for different VPNs with distinct BGP route targets). This is 193 particularly attractive in the context of inter-AS VPNs where the 194 impact of any misconfiguration could be magnified and where a single 195 service provider may not operate all the ASs. Note that this 196 technique to detect some misconfiguration may not be usable during a 197 transition period from a shared-tree autodiscovery to a BGP-based 198 autodiscovery. 200 Last, the use of the BGP-based autodiscovery is expected to be less 201 prone to spoofing attacks (being based on a connection established 202 with a three-way handshake), to which the PIM Hello over MI-PMSI 203 procedures may be subject to (being datagram-based). 205 ( the authors note that, in order to support the coexistence of both 206 protocols (for example during migration scenarios), implementations 207 could support both alternatives by providing a per-VRF configuration 208 knob that would allow recognizing new PIM neighbors based on the 209 reception of PIM hellos on a shared P-multicast tree, even for 210 neighbors that did not advertise a BGP auto-discovery route ) 212 3.2. S-PMSI Signaling 214 The current solution document [I-D.ietf-l3vpn-2547bis-mcast] proposes 215 two mechanisms for S-PMSI Signaling: 217 1. A new UDP-based TLV protocol specifically for S-PMSI signaling 218 (described in section 7.2.1). 220 2. A BGP-based mechanism for S-PMSI signaling (described in section 221 7.2.2). 223 It is the recommendation of the authors that BGP is the preferred 224 solution for S-PMSI signaling and should be supported by all 225 implementations while the UDP-based S-PMSI signaling protocol should 226 be considered optional. 228 Part of the rationale for this recommendation is similar to that for 229 BGP-based auto-discovery and is based on section 5.2.10 of [RFC4834] 230 and the desire to avoid introducing and deploying additional 231 protocols unless strictly necessary. 233 Furthermore: 235 o The BGP-based S-PMSI signaling mechanism can be used within MVPNs 236 using either a UI-PMSI or a MI-PMSI while the UDP-based protocol 237 is restricted to use within MVPNs using an MI-PMSI. 239 o The BGP-based S-PMSI signaling mechanism can be efficiently used 240 in an inter-AS option B deployment context while the use of the 241 UDP-based protocol does not preserve AS routing independence when 242 used in an inter-AS option B context (i.e. the decision by a PE in 243 an AS to use an S-PMSI for a given customer flow will impact 244 routing state in other ASes). Co-existence with unicast inter-AS 245 VPN options is strongly encouraged by section 5.2.6 of [RFC4834]. 247 o The BGP-based S-PMSI signaling supports all the functionality and 248 all the operational contexts that are supported by UDP-based 249 protocol (and more). 251 o BGP supports MD5 authentication of its peers for additional 252 security. In contrast, there are no obvious authentication 253 mechanisms to secure PIM communications in any known 254 implementation. 256 Therefore, it is the opinion of the authors that BGP is the preferred 257 solution for performing S-PMSI signaling. 259 However, the authors recognize that the UDP-based protocol has been 260 in deployment for some time and would recommend that implementations 261 supporting both protocols optionally provide a per-VRF configuration 262 knob to allow an implementation to use the UDP-based TLV protocol for 263 S-PMSI signaling for specific VRFs in order to support the 264 coexistence of both protocols (for example during migration 265 scenarios). 267 Apart from such migration-facilitating mechanisms, the authors 268 specifically do not recommend extending the already proposed UDP- 269 based TLV protocol to new types of P-multicast trees. 271 Section 7.2.2.3 of [I-D.ietf-l3vpn-2547bis-mcast] proposes two 272 approaches for how a source PE can decide when to start transmitting 273 customer multicast traffic on a S-PMSI: 275 1. The source PE sends multicast packets for the on both 276 the I-PMSI P-multicast tree and the S-PMSI P-multicast tree 277 simultaneously for a pre-configured period of time, letting the 278 receiver PEs select the new tree for reception, before switching 279 to only the S-PMSI. 281 2. The source PE waits for a pre-configured period of time after 282 advertising the entry bound to the S-PMSI before fully 283 switching the traffic onto the S-PMSI-bound P-multicast tree. 285 The first alternative has essentially two drawbacks: 287 o traffic is sent twice for some period of time, which 288 would appear to be at odds with the motivation for switching to an 289 S-PMSI in order to optimize the bandwidth used by the multicast 290 tree for that stream. 292 o It is unlikely that the switchover can occur without packet loss 293 or duplication if the transit delays of the I-PMSI P-multicast 294 tree and the S-PMSI P-multicast tree differ. 296 By contrast, the second alternative has none of these drawbacks, and 297 satisfy the requirement in section 5.1.3 of [RFC4834], which states 298 that "[...] a multicast VPN solution SHOULD as much as possible 299 ensure that client multicast traffic packets are neither lost nor 300 duplicated, even when changes occur in the way a client multicast 301 data stream is carried over the provider network". The second 302 alternative also happen to be the one used in existing deployments. 304 For these reasons, it is the authors' recommendation to mandate the 305 implementation of the second alternative for switching to S-PMSI. 307 3.3. PE-PE Transmission of C-Multicast Routing 309 The current solution document [I-D.ietf-l3vpn-2547bis-mcast] proposes 310 multiple mechanisms for PE-PE transmission of customer multicast 311 routing information: 313 1. Full per-MVPN PIM peering across an MI-PMSI (described in section 314 5.2.1). 316 2. Lightweight PIM peering across an MI-PMSI (described in section 317 5.2.2) 319 3. The unicasting of PIM C-Join/Prune messages (described in section 320 5.2.3) 322 4. The use of BGP for carrying C-Multicast routing (described in 323 section 5.3). 325 3.3.1. PE-PE signalling scalability 327 Scalability being one of the core requirements for multicast VPN, it 328 is useful to compare the proposed C-multicast routing mechanisms from 329 this perspective : Section 4.2.4 of [RFC4834] recommends that "a 330 multicast VPN solution SHOULD support several hundreds of PEs per 331 multicast VPN, and MAY usefully scale up to thousands" and section 332 4.2.5 states that "a solution SHOULD scale up to thousands of PEs 333 having multicast service enabled". 335 At such scales of multicast deployment, the first and third 336 mechanisms require the PEs to maintain a large number of PIM 337 adjacencies with other PEs of the same multicast VPN (which implies 338 the regular exchange PIM Hellos with each other) and to refresh 339 C-Join/Prune states, thus limiting the scalability of these 340 approaches. 342 The third mechanism would reduce the amount of C-Join/Prune 343 processing for a given multicast flow for PEs that are not the 344 upstream neighbor for this flow, but would require "explicit 345 tracking" state to be maintained by the upstream PE, and would 346 require refresh-reduction mechanisms to be used to mitigate the fact 347 that PIM "Join suppression" cannot be used (what such a refresh- 348 reduction mechanism would be has not been described yet). For these 349 reasons, it seems that this approach is not suitable for higher scale 350 scenarios. 352 The second mechanism would operate in a similar manner to full per- 353 MVPN PIM peering except that PIM hellos are not transmitted and PIM 354 C-Join/Prune refresh-reduction would be used, thereby improving 355 scalability, but this approach has been further developed and it is 356 unclear if it is applicable. 358 The first and second mechanisms can leverage the "Join suppression" 359 behavior and thus improve the processing burden of an upstream PE, 360 sparing the processing of one Join message for each remote PE joined 361 to a multicast stream, but this improvement comes at the price of 362 requiring all PEs of a multicast VPN to process all PIM Joins sent by 363 any PE participating in the same multicast VPN whether they are the 364 upstream PE or not. 366 The fourth mechanism (the use of BGP for carrying C-Multicast 367 routing) would have a comparable drawback of requiring all PEs to 368 process a BGP C-multicast route only interesting a specific upstream 369 PE. For this reason the C-multicast routing approach leverages the 370 Route-Target constraint mechanisms, which specifically allows only 371 the interested upstream PE to receive a BGP C-multicast route. When 372 RT constraints are used the fourth mechanism reduces the processing 373 load put on the provider infrastructure for customer multicast 374 routing to the minimum (by avoiding any processing by "unrelated" 375 PEs, that are nor the joining PE nor the upstream PE), and inherits 376 BGP features that are expected to improve scalability (through, for 377 instance, providing a means to offload some of the processing burden 378 associated with client multicast routing onto BGP route-reflectors), 379 and being based on TCP has no refresh-related scalability limit. 380 (Please refer to Handling the PIM routing processing load load, for a 381 detailed explanation of the differences in ways of handling the 382 C-multicast routing load, between the PIM-based approaches and the 383 BGP-based approach) 385 However, it is to be noted that offloading customer multicast routing 386 processing onto BGP route-reflectors will increase the processing 387 load placed on the route-reflector infrastructure, which, in the 388 higher scale scenarios, is expected to call for adaptations such as: 390 o a separation of resources for unicast and multicast VPN routing : 391 using mvpn-dedicated BGP sessions and/or mvpn-dedicated BGP 392 instances on route-reflectors, and/or mvpn-dedicated route- 393 reflectors ; 395 o the deployment of additional route-reflectors resources : 396 increased processing resources on existing route reflectors or 397 additional route-reflectors. 399 3.3.2. P-routers scalability 401 Mechanisms (1) and (2) are restricted to use within multicast VPNs 402 that use an MI-PMSI, thereby necessitating: 404 the use of a P-multicast tree technique that allows shared trees 405 (for example PIM-SM in ASM mode or MP2MP LDP) 407 or the use of one P-multicast tree per PE per VPN, even for PEs 408 that do not have sources in their directly attached sites for that 409 VPN. 411 By comparison, the fourth mechanism doesn't impose either of these 412 restrictions, and when P2MP trees are used only necessitates the use 413 of one tree per VPN per PE attached to a site with a multicast source 414 or RP (or with a candidate BSR, if BSR is used), thereby improving 415 the amount of state maintained by P-routers compared to the amount 416 required to build an MI-PMSI with P2MP trees. 418 3.3.3. Impact of C-multicast routing on Inter-AS deployments 420 Furthermore, co-existence with unicast inter-AS VPN options, and an 421 equal level of security for multicast and unicast including in an 422 inter-AS context, are specifically mentioned in sections 5.2.6, 5.2.8 423 and 5.2.12 of [RFC4834]. 425 The first three mechanisms impose direct PE to PE communications : 426 this does not apply well to an inter-AS option B context, because of 427 security and robustness issues that are involved by such a level of 428 reachability and interaction between PEs in different ASes. 430 Their use in an inter-AS context is possible, but not without 431 limitations or additional engineering design trade-offs depending 432 upon the interconnect types. 434 By comparison, the fourth option (the use of BGP for carrying 435 C-Multicast routing) does not have any of the above limitations 436 related to inter-AS deployments, and also provides an additional 437 alternative to facilitate such deployments through the possibility of 438 using segmented inter-AS trees. 440 3.3.4. Security and robustness 442 BGP supports MD5 authentication of its peers for additional security, 443 thereby possibly benefit directly to multicast VPN customer multicast 444 routing, whether for intra-AS or inter-AS communications. By 445 contrast, with a PIM-based approach, no mechanism providing a 446 comparable level of security to authenticate communications between 447 remote PEs has been yet fully described yet 448 [I-D.ietf-pim-sm-linklocal][], and in any case would require 449 significant additional operations for the provider to be usable in a 450 multicast VPN context. 452 The robustness of the infrastructure, especially the existing 453 infrastructure providing unicast VPN connectivity, is key. The 454 C-multicast routing function, especially under load, will compete 455 with the unicast routing infrastructure. With the PIM-based 456 approaches, unicast and multicast VPN routing are expected to only 457 compete in the PE, for routing plane processing resources. In the 458 case of the BGP-based approach, they will compete on the PE for 459 processing resources, and in the route-reflector if they are used. 460 It is identified that in both cases, mechanisms will be required to 461 arbitrate resources (e.g. processing priorities). In the case of 462 PIM-based procedures, between the different control plane routing 463 instances in the PE. And in the case of the BGP-based approach, this 464 is likely to require using distinct BGP sessions for multicast and 465 unicast, possibly toward distinct route-reflectors. 467 Multicast routing is dynamic by nature, and multicast VPN routing has 468 to follow the VPN customers multicast routing events. The different 469 approaches can be compared on how they are expected to behave in 470 scenarios where multicast routing in the VPNs is subject to an 471 intense activity. Such a load would be comparable to the higher 472 scale scenarios described in xx (Section 3.3.1) and the fourth (BGP- 473 based) approach - when deployed to handle a significant multicast VPN 474 routing load - is expected to be the most efficient approach in a 475 such case. On the other hand, while the BGP-based approach is likely 476 to suffer a slowdown under a load raising beyond processing resources 477 (because of possibly congested TCP sockets), the PIM-based approaches 478 would react to such a load by dropping messages, with later failure 479 recovery through message refreshes, this being at the expense of some 480 predictability. 482 In fact both situations are problematic, and what seems important is 483 the ability for the VPN backbone operator to (a) limit the amount of 484 multicast routing activity that can be triggered by a multicast VPN 485 customer, and to (b) provide the best possible independence between 486 distinct VPNs. It seems that both of these can be addressed through 487 local implementation improvements, and that both the BGP-based and 488 PIM-based approach could be engineered to provide (a) and (b). It 489 can be noted though that the BGP approach proposes ways to dampen 490 C-multicast route withdrawals and/or advertisements, and thus already 491 describes a way to provide (a), while nothing hasn't been yet 492 described for the PIM-based approach, though these type of approaches 493 rely on a per VPN dataplane to carry the mvpn control plane, and thus 494 might naturally benefit from this first level of separation to solve 495 (b). 497 3.3.5. C-multicast VPN join latency 499 Section 5.1.3 of [RFC4834] states that "the group join delay [...] is 500 also considered one important QoS parameter. It is thus RECOMMENDED 501 that a multicast VPN solution be designed appropriately in this 502 regard.". In a multicast VPN context, the "group join delay"of 503 interest is the time between a CE sending a PIM Join to its PE and 504 the first packet of the corresponding multicast stream being received 505 by the CE. 507 The different approaches proposed seem to have different 508 characteristics in how they are expected to impact join latency: 510 o the PIM-based approaches minimize the number of control plane 511 processing hops between the PE of a new receiver and the PE of the 512 multicast source, and being datagram based introduce minimal 513 delay, thereby possibly having a best-case join latency as good as 514 possible depending on implementation efficiency 516 o the BGP-based approach uses TCP exchanges, that may introduce an 517 additional delay depending on BGP implementation performances, but 518 are expected to control the worst-case join latency under load 520 o the BGP-based approaches is designed to allow the introduction of 521 route-reflectors which will introduce an additional processing 522 delay between the receiver-PE and the source-PE 524 o in higher scale scenarios, the BGP-based approach is expected to 525 provide some control of the worst-case join latency whereas the 526 PIM-based approaches may behave less efficiently if PIM messages 527 are lost 529 o in higher scale scenarios, the introduction of route-reflectors in 530 the BGP architecture are expected to provide processing efficiency 531 which is expected to improve latency compared to the PIM-based 532 approaches 534 This qualitative comparison of approaches tend to highlight that the 535 BGP based approach is designed for controlling the "worst-case" join 536 latency whereas for the PIM-based approaches seem to structurally be 537 able to reach the shorter "best-case" group join latency (especially 538 compared to deployment of the BGP-based approach where route- 539 reflectors are used). Doing a quantitative comparison is not 540 possible without referring to specific implementations and 541 benchmarking procedures, and would possibly expose different 542 conclusions, especially for best-case group join latency for which 543 performance is expected vary with implementations. We can also note 544 that improving a BGP implementation for reduced latency of route 545 processing would not only benefit multicast VPN group join latency, 546 but the whole BGP-based routing. 548 Last, it is to be noted that the C-multicast routing procedures will 549 only impact the group join latency of a said multicast stream for the 550 first receiver that is located across the provider backbone from the 551 multicast source. 553 3.3.6. Architectural considerations 555 The fourth mechanism (the use of BGP for carrying C-Multicast 556 routing) would appear to fit well with the current unicast 557 architecture as BGP is the customer routing distribution protocol 558 used in unicast VPNs and therefore using BGP for customer routing 559 distribution within multicast VPNs avoids the introduction of an 560 additional protocol that would require additional OAM processes and 561 tools. Service provider's with deployed unicast (RFC4364) VPNs 562 already have extensive deployment and operations experience of using 563 BGP as a customer routing distribution protocol including OAM 564 processes and tools. Such processes and tools will require 565 modification in order to support customer multicast routing but those 566 modifications are anticipated to be less than those required to 567 develop new processes and tools for a distinct customer routing 568 protocol. 570 It should be noted that because PIM will be used as the CE-PE 571 customer routing distribution protocol, service providers will still 572 need OAM processes and tools in order to manage the PIM protocol, so 573 this rationale only applies to a subset of the tools and processes 574 already in place. 576 An illustrative example of the benefit brought by consistency with 577 unicast design is how the "extranet" feature can be implemented : 578 when BGP-based mechanisms are used, the already defined and well 579 understood BGP route target import/export semantics are just reused 580 and applied to BGP mVPN routes. By contrast, it is not specified how 581 implementing the same feature would be done in the context of other 582 alternative mechanisms, and unclear if this is possible without 583 significant engineering trade-offs given that their control plane is 584 tied to a specific MI-PMSI tunnel. Note that the support for the 585 Extranet feature is stated as a MUST in sections 5.1.6 of [RFC4834]. 587 Section 5.2.10 of [RFC4834] states that "as far as possible, the 588 design of a solution SHOULD carefully consider the number of 589 protocols within the core network: if any additional protocols are 590 introduced compared with the unicast VPN service, the balance between 591 their advantage and operational burden SHOULD be examined 592 thoroughly". Considering that the recommendation of the authors 593 would be BGP for auto-discovery and S-PMSI signaling, the choice of 594 BGP for customer multicast routing would be consistent with the 595 protocol choice for unicast VPNs and would adequately address this 596 requirement. 598 3.3.7. Conclusion on C-multicast routing 600 The fourth approach (BGP-based) for customer multicast routing 601 clearly presents some advantages over the PIM-based alternatives. 602 However it has yet to be deployed within an operational MVPN, and 603 only limited experience exists with its implementations. By 604 contrast, PIM-based mechanisms lack many of these benefits and have 605 identified limitations in how they can handle customer multicast 606 routing load in higher-scale scenarios. Despite these, experience 607 showed that the "Full PIM peering" approach is operationally viable. 609 Consequently, at the present time and until there is experience with 610 all of the proposed mechanisms it is not clear which of the above 611 mechanisms should be recommended as the preferred solution to 612 implementers. However, it would appear prudent for implementations 613 to consider supporting both the fourth (BGP-based) and first (full 614 per-MPVN PIM peering) mechanisms. Further experience on both 615 implementations is likely to be required before some best practice 616 can be defined. 618 The first mechanism (full per-MVPN PIM peering across an MI-PMSI) is 619 the mechanism used by [I-D.rosen-vpn-mcast] and therefore it is 620 deployed and operating in MVPNs today. The authors recognize that 621 because full per-MVPN PIM peering has been in deployment for some 622 time, the support for this mechanism may be helpful for backwards 623 compatibility and in order to facilitate migration towards the BGP- 624 based approach. 626 Moreover to improve the clarity of the proposed specifications, 627 considering that neither hello suppression nor refresh-reduction 628 procedures are currently specified or documented and that it is not 629 clear what the impact to the PIM state machine of these additional 630 procedures may be, the authors recommend that the proposals for 631 lightweight PIM peering across an MI-PMSI (the second mechanism) and 632 for the unicasting of PIM C-Join/Prune messages (the third mechanism) 633 be removed from the current solution document 634 [I-D.ietf-l3vpn-2547bis-mcast] (at least until they have been further 635 specified and both their impact and benefit on a multicast VPN 636 deployment is spelled out). 638 3.4. Encapsulation techniques for P-multicast trees 640 In this section the authors will not make any restricting 641 recommendations since the appropriateness of a specific provider core 642 data plane technology will depend on a large number of factors, for 643 example the service provider's currently deployed unicast data plane, 644 many of which are service provider specific. 646 However, implementations should not unreasonably restrict the data 647 plane technology that can be used, and should not force the use of 648 the same technology for different VPNs attached to a single PE. 649 Initial implementations may only support a reduced set of 650 encapsulation techniques and data plane technologies but this should 651 not be a limiting factor that hinders future support for other 652 encapsulation techniques, data plane technologies or 653 interoperability. 655 Section 5.2.4.1 of [RFC4834] states "In a multicast VPN solution 656 extending a unicast L3 PPVPN solution, consistency in the tunneling 657 technology has to be favored: such a solution SHOULD allow the use of 658 the same tunneling technology for multicast as for unicast. 659 Deployment consistency, ease of operation and potential migrations 660 are the main motivations behind this requirement." 662 Current unicast VPN deployments use a variety of LDP, RSVP-TE and 663 GRE/IP-Multicast for encapsulating customer packets for transport 664 across the provider core of VPN services. It is recommended that 665 implementations support the three corresponding multicast tree 666 encapsulations techniques, namely: mLDP, P2MP RSVP-TE and GRE/ 667 IP-multicast in order to allow the same encapsulations to be used for 668 unicast and multicast traffic as well as facilitating migration from 669 [I-D.rosen-vpn-mcast] to an MPLS label based encapsulation. 671 All three of the above encapsulation techniques support the building 672 of P2MP multicast trees. In addition mLDP and GRE/IP-ASM-Multicast 673 implementations may also support the building of MP2MP multicast 674 trees. The use of MP2MP trees may provide some scaling benefits to 675 the service provider as only a single MP2MP tree need be deployed per 676 VPN, thus reducing the amount of multicast state that needs to be 677 maintained by P routers. This gain in state is at the expect of 678 bandwidth optimization, since sites that do not have multicast 679 receivers for multicast streams sourced behind a said PE group will 680 still receive packets of such streams, leading to non-optimal 681 bandwidth utilization across the VPN core. One thing to consider is 682 that the use of MP2MP multicast tree will require configuring the 683 same tree identifier or multicast ASM group address in all PEs, and 684 will not provide the kind of autoconfiguration possible with P2MP 685 trees. 687 MVPN services can also be supported over a unicast VPN core through 688 the use of ingress PE replication whereby the ingress PE replicates 689 any multicast traffic over the P2P tunnels used to support unicast 690 traffic. While this option does not require the service provider to 691 modify their existing P routers (in terms of protocol support) and 692 does not require maintaining multicast-specific state on the P 693 routers in order for the service provider to be able deploy a 694 multicast VPN service, the use of ingress PE replication obviously 695 leads to non-optimal bandwidth utilization and it is therefore 696 unlikely to be the long term solution chosen by service providers. 697 However ingress PE replication may be useful during some migration 698 scenarios or where a service provider considers the level of 699 multicast traffic on their network to be too low to justify deploying 700 multicast specific support within their VPN core. 702 All proposed approaches for control plane and dataplane can be used 703 to provide aggregation amongst multicast groups within a VPN and 704 amongst different multicast VPNs, and potentially reduce the amount 705 of state to be maintained by P routers. However the latter -- the 706 aggregation amongst different multicast VPNs will require support for 707 upstream-assigned labels on the PEs. Support for upstream-assigned 708 labels may require changes to the data plane processing of the PEs 709 and this should be taken into consideration by service providers 710 considering the use of aggregate S-PMSI tunnels for the specific 711 platforms that the service provider has deployed. 713 3.5. Inter-AS deployments options 715 There are a number of scenarios that lead to the requirement for 716 inter-AS multicast VPNs, including: 718 1. A service provider may have a large network that they have 719 segmented into a number of ASs. 721 2. A service provider's multicast VPN may consist of a number of ASs 722 due to acquisitions and mergers with other service providers. 724 3. A service provider may wish to interconnect their multicast VPN 725 platform with that of another service provider. 727 The first scenario can be considered the "simplest" because the 728 network is wholly managed by a single service provider under a single 729 strategy and is therefore likely to use a consistent set of 730 technologies across each AS. 732 The second scenario may be more complex than the first because the 733 strategy and technology choices made for each AS may have been 734 different due to their differing history and the service provider may 735 not have (or may be unwilling to) unified the strategy and technology 736 choices for each AS. 738 The third scenario is the most complex because in addition to the 739 complexity of the second scenario, the ASs are managed by different 740 service providers and therefore may be subject to a different trust 741 model than the other scenarios. 743 Section 5.2.6 of [RFC4834] states "A solution MUST support inter-AS 744 multicast VPNs, and SHOULD support inter-provider multicast VPNs. 745 Considerations about coexistence with unicast inter-AS VPN Options A, 746 B and C (as described in section 10 of [RFC4364]) are strongly 747 encouraged." and "A multicast VPN solution SHOULD provide inter-AS 748 mechanisms requiring the least possible coordination between 749 providers, and keep the need for detailed knowledge of providers' 750 networks to a minimum - all this being in comparison with 751 corresponding unicast VPN options." 753 Section 8 of [I-D.ietf-l3vpn-2547bis-mcast] addresses these 754 requirements by proposing two approaches for mVPN inter-AS 755 deployments: 757 1. Segmented inter-AS tunnels where each AS constructs its own 758 separate multicast tunnels which are then 'stitched' together by 759 the ASBRs (described in section 8.2). 761 2. Non-segmented inter-AS tunnels where the multicast tunnels are 762 end-to-end across ASes, so even though the PEs belonging to a 763 given MVPN may be in different ASs the ASBRs play no special role 764 and function merely as P routers (described in section 8.1). 766 Section 5.2.6 of [RFC4834] also states "Within each service provider 767 the service provider SHOULD be able on its own to pick the most 768 appropriate tunneling mechanism to carry (multicast) traffic among 769 PEs (just like what is done today for unicast)". Segmented inter-AS 770 tunnels is the only solution that is capable of meeting this 771 requirement. 773 The segmented inter-AS solution would appear to offer the largest 774 degree of deployment flexibility to operators, however the non- 775 segmented inter-AS solution can simplify deployment in a restricted 776 number of scenarios and [I-D.rosen-vpn-mcast] only supports the non- 777 segmented inter-AS solution and therefore the non-segmented inter-AS 778 solution is likely to be required by some operators for backward 779 compatibility and during migration from [I-D.rosen-vpn-mcast] to 780 [I-D.ietf-l3vpn-2547bis-mcast]. 782 The applicability of segmented or non-segmented inter-AS tunnels to a 783 given deployment or inter-provider interconnect will depend on a 784 number of factors specific to each service provider. However, due to 785 the additional deployment flexibility offered by segmented inter-AS 786 tunnels, it is the recommendation of the authors that all 787 implementations should support the segmented inter-AS model. 788 Additionally, the authors recommend that implementations should 789 consider supporting the non-segmented inter-AS model in order to 790 facilitate co-existence with existing deployments, and as a feature 791 to provide a lighter engineering in a restricted set of scenarios, 792 although it is recognized that initial implementations may only 793 support one or the other. 795 Additionally, the authors note that the proposed BGP-based approaches 796 for S-PMSI signaling and C-multicast routing information distribution 797 provide a good fit with both segmented and non-segmented inter-AS 798 tunnels. In contrast the UDP-TLV based approach for S-PMSI signaling 799 appears to be incompatible with segmented inter-AS tunnels, and it is 800 unclear if the proposed PIM-based approaches for C-multicast routing 801 information distribution would be fully applicable to segmented 802 inter-AS tunnels. 804 4. Co-located RPs 806 Section 5.1.10.1 of [RFC4834] states "In the case of PIM-SM in ASM 807 mode, engineering of the RP function requires the deployment of 808 specific protocols and associated configurations. A service provider 809 may offer to manage customers' multicast protocol operation on their 810 behalf. This implies that it is necessary to consider cases where a 811 customer's RPs are outsourced (e.g., on PEs). Consequently, a VPN 812 solution MAY support the hosting of the RP function in a VR or VRF." 813 Co-locating a customer's RP on a PE can provide some benefits to the 814 customer as outlined in section 5.1.10.3 of [RFC4834] which states 815 "In the case of PIM-SM, when a source starts to emit traffic toward a 816 group (in ASM mode), if sources and receivers are located in VPN 817 sites that are different than that of the RP, then traffic may 818 transiently flow twice through the SP network and the CE-PE link of 819 the RP (from source to RP, and then from RP to receivers). This 820 traffic peak, even short, may not be convenient depending on the 821 traffic and link bandwidth. 823 However, customers who have already deployed multicast within their 824 networks and have therefore already deployed their own internal RPs 825 are often reluctant to hand over the control of their RPs to their 826 service provider and make use of a co-located RP model. 828 Also, providing collocating the RP on PE will require the activation 829 of MSDP or the processing of PIM Registers on the PE. Securing the 830 PE routers for such activity requires special care, additional work, 831 and will likely rely on specific features to be provided by the 832 routers themselves. 834 The applicability of the co-located RP model to a given MVPN will 835 thus depend on a number of factors specific to each customer and 836 service provider. It is therefore the recommendation of the authors 837 that implementations should support a co-located RP model, but that 838 support for a co-located RP model within an implementation should not 839 restrict deployments to using a co-located RP model : implementations 840 MUST support deployments when activation of a PIM RP function (PIM 841 Register processing and RP-specific PIM procedures) or VRF MSDP 842 instance is not required on any PE router and where all the RPs are 843 deployed within the customers' networks or CEs. 845 5. Existing deployments 847 Some suggestions provided in this document can be used to 848 incrementally modify currently deployed implementations without 849 hindering these deployments, and without hindering the consistency of 850 the standardized solution by providing optional per-VRF configuration 851 knobs to support modes of operation compatible with currently 852 deployed implementations, while at the same time using the 853 recommended approach on implementations supporting the standard. 855 In cases where this may not be easily achieved, a recommended 856 approach would be to provide a per-VRF configuration knob that allows 857 incremental per-VPN migration of the mechanisms used by a PE device, 858 which would allow migration with some per-VPN interruption of service 859 (e.g. during a maintenance window). 861 Mechanisms allowing "live" migration by providing concurrent use of 862 multiple alternatives for a given PE and a given VPN, is not seen as 863 a priority considering the expected implementation complexity 864 associated with such mechanisms. However, if there happen to be 865 cases where they could be viably implemented relatively simply, such 866 mechanisms may help improve migration management. 868 6. Summary of recommendations 870 The following list summarizes the authors' recommendations. These 871 recommendations are not intended to prevent the implementation of 872 alternative solutions, rather they are the authors' recommendations 873 for the mechanisms that should be made mandatory in 874 [I-D.ietf-l3vpn-2547bis-mcast] and therefore be supported by all 875 implementations. 877 It is the authors' recommendation: 879 o that BGP-based auto-discovery be the mandated solution for auto- 880 discovery ; 882 o that BGP be the mandated solution for S-PMSI signaling ; 884 o that the mandated solution for S-PMSI switch-over be the mechanism 885 based on the source-connected PE switching traffic from the I-PMSI 886 tunnel to the S-PMSI tunnel, without transmitting traffic on both 887 at the time ; 889 o that implementations support both the BGP-based and the full per- 890 MPVN PIM peering solutions for PE-PE transmission of customer 891 multicast routing until further operational experience is gained 892 with both solutions ; 894 o that implementations support the following multicast tree 895 encapsulations: mLDP, P2MP RSVP-TE and GRE/IP-Multicast ; 897 o that implementations support segmented inter-AS tunnels and 898 consider supporting non-segmented inter-AS tunnels (in order to 899 maintain backwards compatibility and for migration) ; 901 o implementations MUST support deployments when activation of a PIM 902 RP function (PIM Register processing and RP-specific PIM 903 procedures) or VRF MSDP instance is not required on any PE router. 905 7. IANA Considerations 907 This document makes no request to IANA. 909 [ Note to RFC Editor: this section may be removed on publication as 910 an RFC. ] 912 8. Security Considerations 914 This document does not by itself raise any particular security 915 considerations. 917 9. Acknowledgements 919 We would like to thank Adrian Farrel, Eric Rosen, Yakov Rekhter, and 920 Maria Napierala for their feedback that helped shape this document. 922 10. Informative References 924 [RFC4834] Morin, T., "Requirements for Multicast in L3 Provider- 925 Provisioned Virtual Private Networks (PPVPNs)", RFC 4834, 926 April 2007. 928 [I-D.ietf-l3vpn-2547bis-mcast] 929 Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 930 VPNs", draft-ietf-l3vpn-2547bis-mcast-06 (work in 931 progress), October 2006. 933 [I-D.rosen-vpn-mcast] 934 Rosen, E., "Multicast in MPLS/BGP VPNs", 935 draft-rosen-vpn-mcast-08 (work in progress), 936 December 2004. 938 [I-D.raggarwa-l3vpn-2547-mvpn] 939 Aggarwal, R., "Base Specification for Multicast in BGP/ 940 MPLS VPNs", draft-raggarwa-l3vpn-2547-mvpn-00 (work in 941 progress), June 2004. 943 [I-D.ietf-pim-sm-linklocal] 944 Atwood, J., "Authentication and Confidentiality in PIM-SM 945 Link-local Messages", draft-ietf-pim-sm-linklocal-02 (work 946 in progress), November 2007. 948 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 949 Requirement Levels", BCP 14, RFC 2119, March 1997. 951 Appendix A. Handling the PIM routing processing load load 953 The main role of multicast routing is to let routers determine that 954 they should start or stop forwarding a said multicast stream on a 955 said link. In the multicast VPN context, this has to be made for 956 each VPN, and the associated function is thus named "customer- 957 multicast routing" or "C-multicast routing" and its role is to let PE 958 routers determine that they should start of stop forwarding the 959 traffic of a said multicast stream toward the remote PEs, on some 960 S-PMSI tunnel. 962 When some "join" message is received by a PE, this PE knows that it 963 should be sending traffic for the corresponding multicast group of 964 the corresponding VPN. But the reception of a "prune" message from a 965 remote PE is not enough by itself for a PE to know that it should 966 stop forwarding the corresponding multicast traffic : it has to make 967 sure that they aren't any other PEs that still have receivers for 968 this traffic. 970 There are many ways that the "C-multicast routing" building block can 971 be designed so that a PE can determine when it can stop forwarding a 972 said multicast stream toward other PEs: 974 PIM LAN Procedures, by default 975 By default when PIM LAN procedures are used, when a PE Prunes 976 itself from a multicast tree, all other PEs check their own state 977 to known if they are on the tree, in which case they send a PIM 978 Join message to override the Prune. The "did the last receiver 979 leave?" question is thus implicitly replied to by all PE routers, 980 for each PIM Prune message. 982 PIM LAN Procedures, with explicit tracking : 983 PIM LAN procedures can use an "explicit tracking" approach, where 984 a PE which is the upstream router for a multicast stream maintains 985 an updated list of all neighbors who are joined to the tree. 986 Thus, when it receives a Leave message from a PIM neighbor, it 987 instantly knows the answer to the "did the last receiver leave?" 988 question. 989 In this case, the question is replied to by the upstream router 990 alone. The side effect of this "explicit tracking" is that "Join 991 suppression" is not used : the downstream PEs will always send 992 Joins toward the upstream PE, which will have to process them all. 994 BGP-based C-multicast routing 995 When BGP-based procedures are used for C-multicast routing, if no 996 BGP route reflector is used, the "did the last receiver leave?" 997 question is answered like in the PIM "explicit tracking" approach. 998 But, when a BGP route-reflector is used (which is expected to be 999 the recommended approach), the role of maintaining an updated list 1000 of the PE part of a said multicast tree is taken care of by the 1001 route-reflector(s). Using plain BGP route selection procedures, 1002 the route-reflector will withdraw a C-multicast Source Tree Join 1003 for a said (C-S,C-G) when there is no PE advertising one anymore. 1004 In this context, the "did the last receiver leave?" question can 1005 be said to be answered by the route-reflector alone. 1006 Furthermore, the BGP route distribution can leverage more than one 1007 route-reflector : if a hierarchy of Route Reflectors is used, the 1008 "did the last receiver leave?" question is partly answered by each 1009 route-reflector in the hierarchy. 1011 We can see that answering the "last receiver leaves" questions is a 1012 significant proportion of the work that the C-multicast routing 1013 building block has to make, and that there are many ways that the 1014 related load can be spread among the different functions. 1016 Authors' Addresses 1018 Thomas Morin (editor) 1019 France Telecom R&D 1020 2 rue Pierre Marzin 1021 Lannion 22307 1022 France 1024 Email: thomas.morin@orange-ftgroup.com 1026 Ben Niven-Jenkins (editor) 1027 BT 1028 208 Callisto House, Adastral Park 1029 Ipswich, Suffolk IP5 3RE 1030 UK 1032 Email: benjamin.niven-jenkins@bt.com 1034 Yuji Kamite 1035 NTT Communications Corporation 1036 Tokyo Opera City Tower 1037 3-20-2 Nishi Shinjuku, Shinjuku-ku 1038 Tokyo 163-1421 1039 Japan 1041 Email: y.kamite@ntt.com 1042 Raymond Zhang 1043 BT 1044 2160 E. Grand Ave. 1045 El Segundo CA 90025 1046 USA 1048 Email: raymond.zhang@bt.com 1050 Nicolai Leymann 1051 Deutsche Telekom 1052 Goslarer Ufer 35 1053 10589 Berlin 1054 Germany 1056 Email: nicolai.leymann@t-systems.com 1058 Full Copyright Statement 1060 Copyright (C) The IETF Trust (2008). 1062 This document is subject to the rights, licenses and restrictions 1063 contained in BCP 78, and except as set forth therein, the authors 1064 retain all their rights. 1066 This document and the information contained herein are provided on an 1067 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1068 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1069 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1070 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1071 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1072 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1074 Intellectual Property 1076 The IETF takes no position regarding the validity or scope of any 1077 Intellectual Property Rights or other rights that might be claimed to 1078 pertain to the implementation or use of the technology described in 1079 this document or the extent to which any license under such rights 1080 might or might not be available; nor does it represent that it has 1081 made any independent effort to identify any such rights. Information 1082 on the procedures with respect to rights in RFC documents can be 1083 found in BCP 78 and BCP 79. 1085 Copies of IPR disclosures made to the IETF Secretariat and any 1086 assurances of licenses to be made available, or the result of an 1087 attempt made to obtain a general license or permission for the use of 1088 such proprietary rights by implementers or users of this 1089 specification can be obtained from the IETF on-line IPR repository at 1090 http://www.ietf.org/ipr. 1092 The IETF invites any interested party to bring to its attention any 1093 copyrights, patents or patent applications, or other proprietary 1094 rights that may cover technology that may be required to implement 1095 this standard. Please address the information to the IETF at 1096 ietf-ipr@ietf.org. 1098 Acknowledgment 1100 Funding for the RFC Editor function is provided by the IETF 1101 Administrative Support Activity (IASA).