"Multicast in MPLS/BGP IP VPNs", Rahul Aggarwal, Sarveshwar Bandi, Yiqun Cai, Thomas Morin, Yakhov Rekhter, Eric Rosen, IJsbrand Wijnands, Seisho Yasukawa, 5-Mar-09. ( bytes)
In order for IP multicast traffic within a BGP/MPLS IP VPN (Virtual Private Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN Service Provider. These protocols and procedures are specified in this document.
"BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", Rahul Aggarwal, Eric Rosen, Thomas Morin, Yakhov Rekhter, 27-Apr-09. ( bytes)
This document describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in [MVPN].
"Requirements for supporting Customer RSVP and RSVP-TE over a BGP/MPLS IP-VPN", Kenji Kumaki, Yuji Kamite, Raymond Zhang, 4-Aug-09. ( bytes)
Today, customers expect to run triple play services through BGP/MPLS IP-VPNs. Some Service Providers will deploy services that request QoS guarantees from a local CE to a remote CE across the network. As a result, the application (e.g., voice, video, bandwidth-guaranteed data pipe, etc.) requirements for end-to-end QOS and reserving adequate bandwidth continue to increase. Service Providers can use both MPLS and an MPLS-TE LSP to meet the service objectives. This document describes service provider requirements for supporting customer RSVP and RSVP-TE over a BGP/MPLS IP-VPN.
"Four-octet AS Specific BGP Extended Community", Yakhov Rekhter, Srihari Sangli, Dan Tappan, 26-Mar-09. ( bytes)
This document defines a new type of a BGP extended community - four- octet AS specific extended community. This community allows to carry 4 octet autonomous system numbers.
"IPv6 Address Specific BGP Extended Communities Attribute", Yakhov Rekhter, 26-Mar-09. ( bytes)
Current specifications of BGP Extended Communities [RFC4360] support IPv4 Address Specific Extended Community, but do not support IPv6 Address Specific Extended Community. The lack of IPv6 Address Specific Extended Community may be a problem when an application uses IPv4 Address Specific Extended Community, and one wants to use this application in a pure IPv6 environment. This document defines a new BGP attribute, IPv6 Address Specific Extended Community that addresses this problem. The IPv6 Address Specific Extended Community is similar to the IPv4 Address Specific Extended Community, except that it carries an IPv6 address rather than an IPv4 address.
"BGP ACCEPT_OWN Standards Action Community Attribute", James Uttaro, Pradosh Mohapatra, David Smith, Robert Raszuk, John Scudder, 18-Jun-09. ( bytes)
Under certain conditions it is desirable for a BGP route reflector to be able to modify the Route Target list of a VPN route that is distributed by the route reflector, enabling the route reflector to control how a route originated within one VRF is imported into other VRFs. This technique works effectively as long as the VRF that exports the route is not on the same PE as the VRF(s) that import the route. However, due to the constraints of the BGP protocol, it does not work if the two are on the same PE. This document describes a modification to the BGP protocol allowing this technique to work when the VRFs are on the same PE, allowing the technique to be used in a standard manner throughout an autonomous system.
"OSPFv3 as a PE-CE routing protocol", Padma Pillay-Esnault, Peter Moyer, Jeff Doyle, Emre Ertekin, Michael Lundberg, 10-Jul-09. ( bytes)
Many Service Providers (SPs) offer Virtual Private Network (VPN) services to their customers using a technique in which Customer Edge (CE) routers are routing peers of Provider Edge (PE) routers. The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. This is known as a "BGP/MPLS IP VPN". Originally only IPv4 was supported and it was later extended to support IPv6 VPNs as well. Extensions were later added for the support of the Open Shortest Path First protocol version 2 (OSPFv2) as a PE-CE routing protocol for the IPv4 VPNs. This document extends those specifications to support OSPF version 3 (OSPFv3) as a PE-CE routing protocol. The OSPFv3 PE-CE functionality is identical to that of OSPFv2 except for the differences described in this document.
"Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN Solution", Thomas Morin, Ben Niven-Jenkins, Yuji Kamite, Raymond Zhang, Nicolai Leymann, Nabil Bitar, 10-Jul-09. ( bytes)
More that one set of mechanisms to support multicast in a layer 3 BGP/MPLS VPN has been defined. These are presented in the documents that define them as optional building blocks. To enable interoperability between implementations, this document defines a subset of features that is considered mandatory for a multicast BGP/MPLS VPN implementation. This will help implementers and deployers understand which L3VPN multicast requirements are best satisfied by each option.

IETF Secretariat - Please send questions, comments, and/or suggestions to ietf-web@ietf.org.

Return to Internet-Draft directory.

Return to IETF home page.