Network Working Group T. Morin Internet-Draft France Telecom R&D Intended status: Informational B. Niven-Jenkins Expires: July 19, 2007 BT Y. Kamite NTT Communications R. Zang BT N. Leymann T-Systems February 28, 2007 Considerations about Multicast BGP/MPLS Standardization draft-morin-l3vpn-mvpn-considerations-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 19, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract The current proposal for multicast in BGP/MPLS includes multiple Morin, et al. Expires July 19, 2007 [Page 1] Internet-Draft Multicast VPN Considerations January 2007 alternative mechanisms for some of the required building blocks of the solution. The aim of this document is to leverage requirements to identify the key elements and help move forward solution design, toward the definition of a standard having a well defined set of mandatory procedures. The different proposed alternative mechanisms are examined in the light of requirements identified for multicast in L3VPNs, and suggestions are made about which of these mechanisms standardization should favor. Issues related to existing deployments of early implementations are also addressed. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Examining alternatives mechanisms for MVPN functions . . . . . 3 3.1. MVPN auto-discovery . . . . . . . . . . . . . . . . . . . 3 3.2. S-PMSI Signaling . . . . . . . . . . . . . . . . . . . . . 5 3.3. PE-PE Transmission of C-Multicast Routing . . . . . . . . 7 3.4. Encapsulation techniques for P-multicast trees . . . . . . 10 3.5. Inter-AS deployments options . . . . . . . . . . . . . . . 11 4. Existing deployments . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. Informative References . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Morin, et al. Expires July 19, 2007 [Page 2] Internet-Draft Multicast VPN Considerations January 2007 1. Introduction The current proposal for multicast in BGP/MPLS [I-D.ietf-l3vpn-2547bis-mcast] includes multiple alternative mechanisms for some of the required building blocks of the solution. However, it does not identify the core set of mechanisms which must be implemented in order to ensure interoperability. This may lead to a situation where implementations may support different subsets of the available optional mechanisms leading to implementations that do not interoperate. The aim of this document is to leverage the already expressed requirements [I-D.ietf-l3vpn-ppvpn-mcast-reqts] to identify the mechanisms that the authors believe are good candidates for being part of a core set of mandatory mechanisms which can be used to provide a base for interoperable solutions. This document will go through the different building blocks of the solution and provide the authors' recommendations as to which mechanisms the authors' favor for each building block, while considering the requirements already defined and the goal of a fully- interoperable standard. Considering the history of the multicast VPN proposals and implementations, the authors also consider it useful to depict how existing deployments of early implementations [I-D.rosen-vpn-mcast][I-D.raggarwa-l3vpn-2547-mvpn] can fit in the picture, and provide suggestions in this respect. 2. Terminology Please refer to [I-D.ietf-l3vpn-2547bis-mcast] and [I-D.ietf-l3vpn-ppvpn-mcast-reqts]. 3. Examining alternatives mechanisms for MVPN functions 3.1. MVPN auto-discovery Section 5.2.10 of [I-D.ietf-l3vpn-ppvpn-mcast-reqts] states "The operation of a multicast VPN solution SHALL be as light as possible and providing automatic configuration and discovery SHOULD be a priority when designing a multicast VPN solution. Particularly the operational burden of setting up multicast on a PE or for a VR/VRF SHOULD be as low as possible". The current solution document [I-D.ietf-l3vpn-2547bis-mcast] Morin, et al. Expires July 19, 2007 [Page 3] Internet-Draft Multicast VPN Considerations January 2007 addresses this requirement by proposing two different mechanisms for MVPN auto-discovery: 1. BGP-based auto-discovery (described in section 4). 2. Discovery using PIM running on a MI-PMSI implemented with a shared tree using multicast ASM, or MP2MP LDP with the same common tree identifier configured in all VRFs of an MVPN. It is the recommendation of the authors that BGP-based auto-discovery is the preferred solution for auto-discovery and should be supported by all implementations while PIM/shared-tree based auto-discovery should be optionally considered for migration purpose only. Part of the rationale for this recommendation is also based on section 5.2.10 of [I-D.ietf-l3vpn-ppvpn-mcast-reqts] which states "as far as possible, the design of a solution SHOULD carefully consider the number of protocols within the core network: if any additional protocols are introduced compared with the unicast VPN service, the balance between their advantage and operational burden SHOULD be examined thoroughly". BGP is indeed the auto-discovery protocol used in unicast (RFC4364) VPNs and therefore the use of BGP-based auto-discovery within multicast VPNs avoids the introduction of an additional auto- discovery protocol that would require additional OAM processes and tools. Service providers with deployed unicast (RFC4364) VPNs already have extensive deployment and operations experience of using BGP as an auto-discovery protocol including OAM processes and tools. Such processes and tools will require modifications in order to support multicast auto-discovery but those modifications are anticipated to be less than those required to develop new processes and tools for a specific auto-discovery protocol. Additionally, BGP supports MD5 authentication of its peers for additional security. In contrast, there are no obvious authentication mechanisms to secure PIM communications in any known implementation. Furthermore, PIM based discovery is only applicable to deployments using a shared tree on an MI-PMSI, whereas BGP-based auto-discovery does not place any restrictions on the type of multicast trees that can be used. BGP-based auto-discovery is independent of the type of P-multicast tree used thus satisfying the requirement in section 5.2.4.1 of [I-D.ietf-l3vpn-ppvpn-mcast-reqts] that "a multicast VPN solution SHOULD be designed so that control and forwarding planes are not interdependent". Additionaly, it is to be noted that a number of service providers have chosen to use SSM-based trees for the default MDTs within their current deploymentsn, therefore relying already on BGP-based auto-discovery. Morin, et al. Expires July 19, 2007 [Page 4] Internet-Draft Multicast VPN Considerations January 2007 When shared trees are used, the use of BGP autodiscovery would allow inconsistencies in the addresses/identifiers used for the shared trees to be detected (e.g. the same shared tree identifier being used for different VPNs with distinct BGP route targets). This is particularly attractive in the context of inter-AS VPNs where the impact of any misconfiguration could be magnified and where a single service provider may not operate all the ASs. The authors note that, in order to support the coexistence of both protocols (for example during migration scenarios), implementations could support both alternatives by providing a per-VRF configuration knob that would allow recognizing new PIM neighbors based on the reception of PIM hellos on a shared P-multicast tree, even for neighbors that did not advertise a BGP auto discovery route. 3.2. S-PMSI Signaling The current solution document [I-D.ietf-l3vpn-2547bis-mcast] proposes two mechanisms for S-PMSI Signaling: 1. A new UDP-based TLV protocol specifically for S-PMSI signaling (described in section 7.2.1). 2. A BGP-based mechanism for S-PMSI signaling (described in section 7.2.2). It is the recommendation of the authors that BGP is the preferred solution for S-PMSI signaling and should be supported by all implementations while the UDP-based S-PMSI signaling protocol should be considered optional. Part of the rationale for this recommendation is similar to that for BGP-based auto-discovery and is based on section 5.2.10 of [I-D.ietf-l3vpn-ppvpn-mcast-reqts] and the desire to avoid introducing and deploying additional protocols unless strictly necessary. Furthermore: o The BGP-based S-PMSI signaling mechanism can be used within MVPNs using either a UI-PMSI or a MI-PMSI while the UDP-based protocol is restricted to use within MVPNs using an MI-PMSI. o The BGP-based S-PMSI signaling mechanism can be efficiently used in an inter-AS option B deployment context while the use of the UDP-based protocol does not preserve AS routing independence when used in an inter-AS option B context (i.e. the decision by a PE in an AS to use an S-PMSI for a given customer flow will impact Morin, et al. Expires July 19, 2007 [Page 5] Internet-Draft Multicast VPN Considerations January 2007 routing state in other ASes). Co-existence with unicast inter-AS VPN options is strongly encouraged by section 5.2.6 of [I-D.ietf-l3vpn-ppvpn-mcast-reqts]. o The BGP-based S-PMSI signaling supports all the functionality and all the operational contexts that are supported by UDP-based protocol (and more). o BGP supports MD5 authentication of its peers for additional security. In contrast, there are no obvious authentication mechanisms to secure PIM communications in any known implementation. Therefore, it is the opinion of the authors that BGP is the preferred solution for performing S-PMSI signaling. However, the authors recognize that the UDP-based protocol has been in deployment for some time and would recommend that implementations supporting both protocols optionally provide a per-VRF configuration knob to allow an implementation to use the UDP-based TLV protocol for S-PMSI signaling for specific VRFs in order to support the coexistence of both protocols (for example during migration scenarios). Apart from such migration-facilitating mechanisms, the authors specifically do not recommend extending the already proposed UDP- based TLV protocal to new types of P-multicast trees. Section 7.2.2.3 of [I-D.ietf-l3vpn-2547bis-mcast] proposes two approaches for how a source PE can decide when to start transmitting customer multicast traffic on a S-PMSI: 1. The source PE sends multicast packets for the on both the I-PMSI P-multicast tree and the S-PMSI P-multicast tree simultaneously for a pre-configured period of time, letting the receiver PEs select the new tree for reception, before switching to only the S-PMSI. 2. The source PE waits for a pre-configured period of time after advertising the entry bound to the S-PMSI before fully switching the traffic onto the S-PMSI-bound P-multicast tree. The first alternative has essentially two drawbacks: o traffic is sent twice for some periode of time, for a stream for which bandwidth optimization just happen to be considered useful Morin, et al. Expires July 19, 2007 [Page 6] Internet-Draft Multicast VPN Considerations January 2007 o it is unlikely that the switch can happen without packet loss or duplicates, as soon as the transit delay of the I-PMSI P-multicast tree and the S-PMSI P-multicast tree are different By contrast, the second alternative has none of these drawbacks, and would meet the requirement made in section 5.1.3 of requirements stating that "[...] a multicast VPN solution SHOULD as much as possible ensure that client multicast traffic packets are neither lost nor duplicated, even when changes occur in the way a client multicast data stream is carried over the provider network". The second alternative also happen to be the one used in existing deployments. For these reasons, it is the author recomandation to mandate the implementation of this second alternative for switching to S-PMSI. 3.3. PE-PE Transmission of C-Multicast Routing The current solution document [I-D.ietf-l3vpn-2547bis-mcast] proposes multiple mechanisms for PE-PE transmission of customer multicast routing information: 1. Full per-MVPN PIM peering across an MI-PMSI (described in section 5.2.1). 2. Lightweight PIM peering across an MI-PMSI (described in section 5.2.2) 3. The unicasting of PIM C-Join/Prune messages (described in section 5.2.3) 4. The use of BGP for carrying C-Multicast routing (described in section 5.3). The first mechanism (full per-MVPN PIM peering across an MI-PMSI) is the mechanism used by [I-D.rosen-vpn-mcast] and therefore it is deployed and operating in MVPNs today. The authors recognize that because full per-MVPN PIM peering has been in deployment for some time support for this mechanism may be required for backwards compatibility and in order to facilitate migration towards alternative PE-PE protocols. Section 4.2.4 of [I-D.ietf-l3vpn-ppvpn-mcast-reqts] recommends that "a multicast VPN solution SHOULD support several hundreds of PEs per multicast VPN, and MAY usefully scale up to thousands" and section 4.2.5 states that "a solution SHOULD scale up to thousands of PEs having multicast service enabled". Morin, et al. Expires July 19, 2007 [Page 7] Internet-Draft Multicast VPN Considerations January 2007 At those scales of multicast deployment within a large VPN, the first and third mechanisms require PEs to maintain a large number of PIM adjacencies with other PEs within the same MVPN and to regularly exchange PIM hellos with each other and refresh C-Join/Prune state. The third mechanism would reduce the amount of C-Join/Prune processing by PEs when they are not the upstream neighbor for a given multicast flow, but would : a. require explicit tracking related state to be maintained by PEs when they are the upstream PE for a said customer flow, and b. require refresh reduction mechanisms to be used to be applicable. The second mechanism (lightweight PIM peering across an MI-PMSI) would operate in a similar manner to full per-MVPN PIM peering except that PIM hellos are not transmitted and PIM C-Join/Prune refresh reduction would be used, thereby improving scalability. The fourth mechanism (the use of BGP for carrying C-Multicast routing) has to solve roughly the same intrinsic scalability related difficulties as the other three mechanisms, but because it is based on TCP it has no refresh-related scalability limit, and inherits some BGP features that are expected to improve scalability through, for instance, providing a means to offload some of the processing burden associated with client multicast routing onto BGP route reflectors. Furthermore, co-existence with unicast inter-AS VPN options, and an equal level of security for multicast and unicast including in an inter-AS context, are specifically mentioned in sections 5.2.6, 5.2.8 and 5.2.12 of [I-D.ietf-l3vpn-ppvpn-mcast-reqts]. The first three mechanisms impose direct PE to PE communications which means that they do not apply well to an inter-AS option B context, because of security and robustness issues that are involved by such a level of reachability and interaction between PEs in different ASes. Their use in an inter-AS context is possible, but not without limitations or additional engineering design trade-offs depending upon the interconnect types. By comparison, the fourth option (the use of BGP for carrying C-Multicast routing) does not have any of the above limitations related to inter-AS deployments, and also provides an additional alternative to facilitate such deployments through the possibility of using segmented inter-AS trees. Moreover, mechanisms one and two are restricted to use within MVPNs using an MI-PMSI, thereby necessitating: Morin, et al. Expires July 19, 2007 [Page 8] Internet-Draft Multicast VPN Considerations January 2007 a. The use of a P-multicast tree technique that allows shared trees (for example PIM-SM in ASM mode or MP2MP LDP). b. The use of one P-multicast tree per PE per VPN, even for PEs that do not have sources in their directly attached sites for that VPN. By comparision, the fourth mechanism doesn't impose either of these restrictions. Additionally, the fourth mechanism (the use of BGP for carrying C-Multicast routing) would appear to fit well with the current unicast architecture as BGP is the customer routing distribution protocol used in unicast VPNs and therefore using BGP for customer routing distribution within multicast VPNs avoids the introduction of an additional protocol that would require additional OAM processes and tools. Service provider's with deployed unicast (RFC4364) VPNs already have extensive deployment and operations experience of using BGP as a customer routing distribution protocol including OAM processes and tools. Such processes and tools will require modification in order to support customer multicast routing but those modifications are anticipated to be less than those required to develop new processes and tools for a distinct customer routing protocol. It should be noted that because PIM will be used as the CE-PE customer routing distribution protocol, service providers will still need OAM processes and tools in order to manage the PIM protocol, so this rationale only applies to a subset of the tools and processes already in place. Additionally, BGP supports MD5 authentication of its peers for additional security. In contrast, there are no obvious authentication mechanisms to secure PIM communications in any known implementation. An illustrative example of the benefit brought by consistency with unicast design is how the "extranet" feature can be implemented : when BGP-based mechanisms are used, the well defined and well understood BGP route target import/export semantics are just reused. By contrast, it is not specified how implementing the same feature would be done in the context of other alternative mechanism, and unclear if this is possible without significant engineering trade- offs. Note that the support for such a feature is stated as a MUST in sections 5.1.6 of [I-D.ietf-l3vpn-ppvpn-mcast-reqts]. Section 5.2.10 of requiremnts [I-D.ietf-l3vpn-ppvpn-mcast-reqts] states that "as far as possible, the design of a solution SHOULD carefully consider the number of protocols within the core network: if any additional protocols are introduced compared with the unicast VPN service, the balance between their advantage and operational burden SHOULD be examined thoroughly". Considering that the Morin, et al. Expires July 19, 2007 [Page 9] Internet-Draft Multicast VPN Considerations January 2007 recommendation of the authors would be BGP for auto-discovery and S-PMSI signalling, the choice of BGP for customer multicast routing would be consistent with the protocol choice for unicast VPNs and would adequately address this requirement. BGP-based customer multicast routing clearly presents some advantages over the PIM-based alternatives. However it has yet to be deployed within an operational MVPN, and service providers currently lack experience of its implementation. By contrast, experience proves that PIM-based mechanisms are operationaly viable, but with well identified limitations. Some of those limitations may be improved upon (although there is currently no clearly defined proposal to do this), however some of the limitations appear to be intrinsic to the approach. Moreover to improve the clarity of the proposed specifications, considering that neither hello suppression nor refresh reduction procedures are currently specified or documented and that it is not clear what the impact to the PIM state machine of these additional procedures may be, the authors recommend that the proposals for lightweight PIM peering across an MI-PMSI (the second mechanism) and for the unicasting of PIM C-Join/Prune messages (the third mechanism) be removed from the current solution document [I-D.ietf-l3vpn-2547bis-mcast] until the additional PIM hello and refresh reduction procedures have been well specified and both their impact and benefit on an MPVN deployment is understood. Consequently, at the present time and until there is experience with all of the proposed mechanisms it is not clear which of the above mechanisms should be recommended as the preferred solution to implementers. However, it would appear prudent for implementations to consider supporting both the fourth (BGP-based) and first (full per-MPVN PIM peering) mechanisms. Further experience on both implementation is likely to be required before some best practice can be defined. 3.4. Encapsulation techniques for P-multicast trees In this section the authors will not make any restricting recommendations as the appropriateness of a specific core (P) data plane technology will depend on a large number of factors, for example the service provider's currently deployed unicast data plane, many of which are service provider specific. However, implementations should not unreasonably restrict the data plane technology that can be used, and should not force the use of the same technology for different VPNs attached to a single PE. Initial implementations may only support a reduced set of Morin, et al. Expires July 19, 2007 [Page 10] Internet-Draft Multicast VPN Considerations January 2007 encapsulation techniques and data plane technologies but this should not be considered a limiting factor that hinders future support for other encapsulation techniques, data plane technologies or interoperability. Section 5.2.4.1 of [I-D.ietf-l3vpn-ppvpn-mcast-reqts] states "In a multicast VPN solution extending a unicast L3 PPVPN solution, consistency in the tunneling technology has to be favored: such a solution SHOULD allow the use of the same tunneling technology for multicast as for unicast. Deployment consistency, ease of operation and potential migrations are the main motivations behind this requirement." Current unicast VPN deployments use a variety of LDP, RSVP-TE and GRE/IP for encapsulating customer packets for transport across the provider core of VPN services. It is recommended that implementations support the three corresponding multicast tree encapsulations techniques, namely: mLDP, P2MP RSVP-TE and GRE/IP multicast in order to allow the same encapsulations to be used for unicast and multicast traffic as well as facilitating migration from [I-D.rosen-vpn-mcast] to an MPLS label based encapsulation. 3.5. Inter-AS deployments options Section 5.2.6 of [I-D.ietf-l3vpn-ppvpn-mcast-reqts] states "A solution MUST support inter-AS multicast VPNs, and SHOULD support inter-provider multicast VPNs. Considerations about coexistence with unicast inter-AS VPN Options A, B and C (as described in section 10 of [RFC4364]) are strongly encouraged." and "A multicast VPN solution SHOULD provide inter-AS mechanisms requiring the least possible coordination between providers, and keep the need for detailed knowledge of providers' networks to a minimum - all this being in comparison with corresponding unicast VPN options." Section 8 of [I-D.ietf-l3vpn-2547bis-mcast] addresses these requirements by proposing two approaches for mVPN inter-AS deployments: 1. Segmented inter-AS tunnels where each AS constructs its own separate multicast tunnels which are then 'stitched' together by the ASBRs (described in section 8.2). 2. Non-segmented inter-AS tunnels where the multicast tunnels are end-to-end across ASes, so even though the PEs belonging to a given MVPN may be in different ASes the ASBRs play no special role and function merely as P routers (described in section 8.1). Section 5.2.6 of [I-D.ietf-l3vpn-ppvpn-mcast-reqts] also states Morin, et al. Expires July 19, 2007 [Page 11] Internet-Draft Multicast VPN Considerations January 2007 "Within each service provider the service provider SHOULD be able on its own to pick the most appropriate tunneling mechanism to carry (multicast) traffic among PEs (just like what is done today for unicast)". However, the applicability of segmented or non-segmented inter-AS tunnels to a given deployment or inter-provider interconnect will depend on a number of factors specific to each service provider. It is therefore the recommendation of the authors that implementation should support both segmented and non-segmented inter-AS tunnels, although it is recognised that initial implementations may only support one or the other. Additionally, the authors note that the proposed BGP-based approaches for S-PMSI signaling and C-multicast routing information distribution provide a good fit with both segmented and non-segmented inter-AS tunnels. In contrast the UDP-TLV based approach for S-PSMI signaling appears to be incompatible with segmented inter-AS tunnels, and it is unclear if the proposed PIM-based approaches for C-multicast routing information distribution would be fully applicable to segmented inter-AS tunnels. 4. Existing deployments Some suggestions provided in this document can be used to incrementally modify currently deployed implementations without hindering these deployments, and without hindering the consistency of the standardized solution : optionnaly providing a per-VRF tunable to support a mode of operation compatible with currently deployed implementations, while using at the same time the recommended approach with implementation supporting the standard. In cases where this may not be easily doable, a recommended approach would be to provide a per-VRF tunable allowing incremental per-VPN migration of the mechanisms used by a PE device, which would allow migration with some per-VPN interruption of service (e.g. on non-peak hours). Mechanisms allowing "live" migration by providing concurrent use of multiple alternatives for a said PE and a said VPN, is not seen as a priority considering the expected associated implementation complexity. However, if there happen to be cases where they could be relatively simple and viable, such mechanisms may help improve migration management. Morin, et al. Expires July 19, 2007 [Page 12] Internet-Draft Multicast VPN Considerations January 2007 5. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 6. Security Considerations This document does not by itself raise any particular security issue. 7. Acknowledgements [To be completed] 8. Informative References [I-D.ietf-l3vpn-2547bis-mcast] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-03 (work in progress), October 2006. [I-D.ietf-l3vpn-ppvpn-mcast-reqts] Morin, T., "Requirements for Multicast in L3 Provider- Provisioned VPNs", draft-ietf-l3vpn-ppvpn-mcast-reqts-10 (work in progress), November 2006. [I-D.raggarwa-l3vpn-2547-mvpn] Aggarwal, R., "Base Specification for Multicast in BGP/ MPLS VPNs", draft-raggarwa-l3vpn-2547-mvpn-00 (work in progress), June 2004. [I-D.rosen-vpn-mcast] Rosen, E., "Multicast in MPLS/BGP VPNs", draft-rosen-vpn-mcast-08 (work in progress), December 2004. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Morin, et al. Expires July 19, 2007 [Page 13] Internet-Draft Multicast VPN Considerations January 2007 Authors' Addresses Thomas Morin France Telecom R&D 2 rue Pierre Marzin Lannion 22307 France Email: thomas.morin@orange-ftgroup.com Ben Niven-Jenkins BT 208 Callisto House, Adastral Park Ipswich, Suffolk IP5 3RE UK Email: benjamin.niven-jenkins@bt.com Yuji Kamite NTT Communications Corporation Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku Tokyo 163-1421 Japan Email: y.kamite@ntt.com Raymond BT 2160 E. Grand Ave. El Segundo CA 90025 USA Email: raymond.zhang@bt.com Nicolai Leymann T-Systems International GmbH Goslarer Ufer Berlin 3510589 Germany Email: nicolai.leymann@t-systems.com Morin, et al. Expires July 19, 2007 [Page 14] Internet-Draft Multicast VPN Considerations January 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Morin, et al. Expires July 19, 2007 [Page 15]