Network Working Group Eric C. Rosen (Editor)
Internet Draft Arjen Boers
Intended Status: Proposed Standard Yiqun Cai
Expires: December 29, 2009 IJsbrand Wijnands
Cisco Systems, Inc.
June 29, 2009
MVPN Profiles Using PIM Control Plane
draft-rosen-l3vpn-mvpn-profiles-03.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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.
Copyright and License Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Rosen, et al. [Page 1]
Internet Draft draft-rosen-l3vpn-mvpn-profiles-03.txt June 2009
Abstract
The MVPN (Multicast Virtual Private Network) architecture is divided
into a number of functional "layers". At each layer, multiple
options are allowed. It is necessary to allow multiple options at
each layer because "one size doesn't fit all." However, it is not
expected that any particular implementation will support all the
possible combinations of options. To ensure multi-vendor
interoperability, it is useful to specify "profiles", where each
profile is a particular combination of options. The number of
specified profiles will be much less than the total number of
possible combination, and a given implementation can be characterized
by saying which profiles it supports. This document describes two
profiles that use a PIM control plane.
Rosen, et al. [Page 2]
Internet Draft draft-rosen-l3vpn-mvpn-profiles-03.txt June 2009
Table of Contents
1 Specification of requirements ......................... 4
2 Introduction .......................................... 4
3 The PIM+GRE Profile ................................... 5
3.1 Auto-discovery ........................................ 5
3.2 MI-PMSI Instantiation ................................. 5
3.2.1 Source Specific Multicast Mode ........................ 6
3.2.2 Any System Multicast Mode, Unidirectional ............. 6
3.2.3 Bidir ................................................. 7
3.3 Distribution of C-Multicast Routing Information ....... 7
3.4 Encapsulation ......................................... 7
3.5 S-PMSIs ............................................... 7
3.6 Inter-AS support ...................................... 7
3.7 Upstream Multicast Hop Determination .................. 8
4 The PIM+MPLS/MP2MP Profile: PIM over MS-PMSI .......... 8
4.1 Auto-discovery ........................................ 8
4.2 Joining an MP2MP LSP .................................. 9
4.2.1 Joining to Receive BSR Messages ....................... 10
4.2.2 Joining to Send PIM C-Join/Prune Messages ............. 10
4.2.3 Joining to Send Data Without Having Sent a C-J/P ...... 10
4.2.4 Pruning Oneself from a MP2MP LSP ...................... 11
4.3 Sending and Receiving C-Multicast Data ................ 11
4.4 Encapsulation ......................................... 12
4.5 Additional S-PMSIs .................................... 12
4.6 Inter-AS Support ...................................... 12
4.7 Upstream Multicast Hop Determination .................. 13
4.8 Extensions of this Profile ............................ 13
5 IANA Considerations ................................... 13
6 Security Considerations ............................... 13
7 Authors' Addresses .................................... 14
8 Normative References .................................. 15
9 Informative References ................................ 16
Rosen, et al. [Page 3]
Internet Draft draft-rosen-l3vpn-mvpn-profiles-03.txt June 2009
1. Specification of requirements
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].
2. Introduction
The MVPN (Multicast Virtual Private Network) architecture, as
specified in [MVPN] and [MVPN-MSPMSI], allows Service Providers (SPs)
to offer IP multicast service over the sort of Virtual Private
Networks (VPNs) that are specified in [VPN]. The MVPN architecture
contains a number of functional layers, and at each layer, multiple
options are allowed.
For example, one of the "functional layers" is the control protocol
which a Provider Edge (PE) router uses to distribute
Customer-multicast (C-multicast) routing to other PE routers. Two
options are allowed for this: (a) PIM and (b) BGP. Several
different variations of PIM are accommodated by the architecture as
well.
Another functional layer is the encapsulation which a PE router uses
to transmit a customer's multicast data to other PE routers. Both
MPLS and IP-based encapsulations are allowed by the architecture.
When MPLS encapsulation is used, transmission of user data is done
over Multipoint LSPs. There are however three very different kinds
of Multipoint LSPs that can be used. The LSPs can be MP2MP
(Multipoint-to-multipoint) LSPs set up by mLDP [MLDP], P2MP
(Point-to-Multipoint) LSPs set up by mLDP, or P2MP LSPs set up by
RSVP-TE [MP-RSVP-TE].
Although the architecture allows any option at one layer to be used
with any option at another, it is not expected that any given
implementation will actually support the full set of options at each
layer, and in fact not all arbitrary combinations of options are
sensible. It is useful therefore to describe a set of MVPN
"Profiles", where each profile contains a single mandatory option at
each layer. Implementations can then be characterized by the set of
profiles they support.
The intention is that each profile be fully conformant to the [MVPN]
standard.
The profiles are described in the terminology of [MVPN], which is
presupposed by this document.
Rosen, et al. [Page 4]
Internet Draft draft-rosen-l3vpn-mvpn-profiles-03.txt June 2009
Deployments of MVPN based on the "PIM+GRE" profile (most precisely,
on a pre-standards version of that profile described in
[ORIGINAL-MVPN]) have existed since the turn of the century. The use
of PIM for distributing C-multicast routes has thus been proven in
deployment. Issues have been raised about whether this will be
adequate in the future if MVPN deployments greatly increase in scale.
However, the alternative of using BGP for distributing C-multicast
routes has not been proven in deployment, and the authors believe
that that alternative has a number of issues having to do with
functionality, scaling, and dynamic behavior that are not yet fully
understood. Until those are better understood, it does not seem
prudent to migrate quickly from PIM to BGP for distributing
C-multicast routes. The authors also believe that the ability to
deploy MPLS encapsulation for multicast VPN traffic should not be
gated by the need to deploy BGP as the C-multicast routing control
plane. Therefore we also specify a "PIM+MPLS" profile.
3. The PIM+GRE Profile
The PIM+GRE Profile corresponds closely to the "pre-standards" MVPN
deployments from Cisco Systems [ORIGINAL-MVPN], that have existed for
many years. The specification [ORIGINAL-MVPN] contains the precise
details of how the pre-standards version deviates slightly from the
later standard.
3.1. Auto-discovery
Auto-discovery is done by means of BGP, using the "Intra-AS I-PMSI
A-D routes" described in section 4 of [MVPN] and sections 4.1 and 8.1
of [MVPN-BGP]. Each PE attached to a particular MPVN is configured
with a PIM group address for that MVPN. The group address with which
a given PE is configured is carried in the PMSI Tunnel Attribute (see
[MVPN] section 4 and [MVPN-BGP] section 5) of the Intra-AS I-PMSI A-D
route originated by that PE. This PIM group address is used to
create the P-tunnels that instantiate the MVPN's MI-PMSI (see section
2.2).
3.2. MI-PMSI Instantiation
In the PIM+GRE profile, the PEs attached to a given MVPN are
connected via an MI-PMSI (see [MVPN] sections 3.3.1 and 3.3.2). The
P-tunnels that instantiate the MI-PMSIs are multicast distribution
trees constructed with PIM. Each MVPN VRF is configured with a PIM
Group P-address. The Intra-AS A-D route sent by each PE specifies
this group address. The P-tunnels may be created using the
Rosen, et al. [Page 5]
Internet Draft draft-rosen-l3vpn-mvpn-profiles-03.txt June 2009
Source-Specific Mode (SSM) service model, or the Any Source Mode
(ASM) service model. In the latter case, P-tunnels may be a mixture
of source-specific trees with unidirectional shared trees rooted at
Rendezvous Points (RPs) (this mixture is the normal result of
applying PIM "sparse mode" procedures). Alternatively, each MI-PMSI
may be instantiated by a single bidirectional tree (created by
BIDIR-PIM). The Intra-AS I-PMSI A-D route sent by each PE specifies
a PIM group address. Other PEs use PIM to join the specified group,
thereby creating the P-tunnels. The P-tunnels are thus created
automatically as a result of the auto-discovery process.
This profile does NOT require support for the capability to have a
single P-tunnel carry traffic from multiple VPNs.
Note that if the group address G used for the P-tunnels is an ASM
group, the BGP-based auto-discovery process is not strictly needed;
each PE MAY join the requisite set of P tunnels for a given MVPN just
by joining the (*,G) tree for the P-group address G that has been
configured for that VPN. However, for consistency, the
auto-discovery process SHOULD always take place.
3.2.1. Source Specific Multicast Mode
Consider the set of PEs that support a given MVPN. Each <PE, MVPN>
pair is associated with a source specific mode PIM group address. If
the set of PEs supporting the given MVPN is PE1, ..., PEn, and the
corresponding set of group addresses is G1, ..., Gn, then PEk joins
each <PEi, Gi> source tree for which 1 <= i <= n and i != k. That
is, the MI-PMSI is instantiated as a "full mesh" (i.e., containing
all the PEs attached to the MVPN) of source trees. The normal PIM
procedures specified in [PIM-SM] are used.
3.2.2. Any System Multicast Mode, Unidirectional
Each MVPN is associated with a non-SSM PIM group address. Each PE
attached to the MVPN joins the group, using the PIM sparse mode
procedures. If there are n PEs, the MI-PMSI is thus instantiated as
a shared tree plus a set of up to n source trees. The normal PIM
procedures specified in [PIM-SM] are used.
Rosen, et al. [Page 6]
Internet Draft draft-rosen-l3vpn-mvpn-profiles-03.txt June 2009
3.2.3. Bidir
Each MVPN is associated with a bidirectional mode PIM group address.
Each PE attached to the MVPN joins the group, using the BIDIR-PIM
procedures. If there are n PEs, the MI-PMSI is thus instantiated as
a shared tree plus a set of up to n source trees. The procedures for
setting up a BIDIR-PIM tree are specified in [PIM-BIDIR].
3.3. Distribution of C-Multicast Routing Information
As already specified, an MI-PMSI is automatically created, containing
all the PEs belonging to a VPN. C-multicast routing information is
distributed by running PIM over the MI-PMSI, using standard PIM LAN
procedures. See sections 3.4.1.1, 5.1, and 5.2 of [MVPN].
3.4. Encapsulation
All C-multicast data messages, and all C-PIM messages (i.e., PIM
messages carrying C-multicast routing information) are encapsulated
in GRE [GRE], precisely as specified in section 11.1.1 of the [MVPN].
3.5. S-PMSIs
This profile supports non-aggregated S-PMSIs, where each S-PMSI is
instantiated as a PIM source tree in SSM mode.
The assignment of a particular C-multicast data stream to a
particular S-PMSI is done via the protocol specified in section 7.2.1
of [MVPN].
3.6. Inter-AS support
Inter-AS support is provided via the non-segmented inter-as tunnels
described in section 8.1 of [MVPN]. Intra-AS A-D routes must
(despite their name) be distributed across AS boundaries.
To set up the inter-AS P-tunnels instantiating a PMSI, it is
necessary for a PE in one AS to send PIM control messages which
identify PEs in other ASes. In order to construct the multicast
distribution trees, P routers processing these messages need to
determine the (IGP) route to the identified PE router. However, in
inter-AS VPNs constructed according to option b of section 10 of RFC
4364, a given AS does not necessarily have routes to PEs in the other
ASes. Therefore, the PIM messages contain the "PIM MVPN Join
Rosen, et al. [Page 7]
Internet Draft draft-rosen-l3vpn-mvpn-profiles-03.txt June 2009
Attribute". This allows the multicast distribution tree to be
properly constructed even if routes to PEs in other ASes do not exist
in the given AS's IGP, and even if the routes to those PEs do not
exist in BGP. The use of an PIM MVPN Join Attribute in the PIM
messages allows the inter-AS trees to be built. The basic format of
a PIM Join Attribute is specified in [PIM-ATTRIB]. The details of
the PIM MVPN Join Attribute are specified in [MVPN].
3.7. Upstream Multicast Hop Determination
According to section 5 of [MVPN], where the selected "Upstream
Multicast Hop" (UMH) route is the installed UMH route. The
procedures of section 5 for single forwarder selection are not
applied. Multicast data packets arriving from the "wrong" upstream
PE are not discarded. However, since PIM LAN procedures are run over
the MI-PMSI, the standard PIM "Assert" procedures will result in a
single choice of forwarder. Packet duplication is possible during
the Assert convergence period.
Although a given source will end up having a single PE as forwarder.
Load balancing is possible within that constraint. That is, if S1
and S2 are two different sources, and each source has both PE1 and
PE2 as an eligible UMH, and if PE3 needs to join the C-trees (S1, G1)
and (S2, G2), a form of load balancing can be providing by having PE3
join (S1, G1) via PE1 but having it join (S2, G2) via PE2.
4. The PIM+MPLS/MP2MP Profile: PIM over MS-PMSI
In this profile, as in the PIM+GRE profile, the PEs use PIM to convey
multicast routing information to each other. However, PIM is not
used to instantiate the P-tunnels. Rather, mLDP is used to create
Multipoint-to-Multipoint (MP2MP, or bidirectional) LSPs to serve as
the P-tunnels. Furthermore, an MI-PMSI is not used at all. PIM is
run over one or more MS-PMSIs (as specified in MVPN-MSPMSI), and
P-tunnels are only created if they are actually needed for carrying
multicast data.
4.1. Auto-discovery
Each PE that attaches to a given MVPN MUST originate an Intra-AS
I-PMSI A-D route that does NOT contain a PMSI Tunnel Attribute (PTA)
or a PE Distinguisher Labels Attribute. (I.e., there is no MI-PMSI.)
After the Intra-AS I-PMSI A-D route is originated, each such PE MUST
originate an S-PMSI A-D route whose PTA specifies a MP2MP LSP rooted
Rosen, et al. [Page 8]
Internet Draft draft-rosen-l3vpn-mvpn-profiles-03.txt June 2009
at the originating PE. The Tunnel Identifier for the MP2MP LSP
consists of an MLDP MP2MP FEC element [MLDP], which itself consists
of an IP address of the originating PE router, followed by an "opaque
value" identifying the MP2MP LSP in the context of that PE router.
This opaque value may be configured or autogenerated, and there is no
need for different PEs attached to a given MVPN to use the same
opaque value. The IP address which appears in the tunnel identifier
field of the PTA MUST be the same IP address that the PE uses for
sending and receiving PIM control messages.
The S-PMSI A-D route originated by PE1 specifies an MS-PMSI of which
PE1 is the root.
The S-PMSI A-D route MUST bind the LSP to the "double wildcard"
(*,*). Use and interpretation of the double wildcard when the PTA
specifies a MP2MP LSP is specified in section 4.1.4 [MVPN-MSPMSI].
Per [MVPN-MSPMSI], the specified MS-PMSI becomes the default PMSI
that its root node uses to send a C-flow to the other PEs, as long as
the C-flow is traveling along a unidirectional C-tree. For C-flows
traveling along a bidirectional C-tree, the MS-PMSI is the default
PMSI for that any PE uses to transmit to other PEs, as long as the
root node is the selected upstream PE for the C-RPA.
The MS-PMSI is associated with a particular MVPN by means of the RTs
carried by the S-PMSI A-D route, exactly as specified in [MVPN] and
[MVPN-BGP].
When PE1 is the root of an MS-PMSI, we will sometimes refer to the
MS-PMSI as "PE1's MS-PMSI". (Of course, a given PE may be the root
for more than one MS- PMSI, for the same or different MVPNs. Rules
governing the association of an S-PMSI A-D route with a given MVPN
are as specified in [MVPN] and [MVPN-BGP].)
This profile does not require support for the use of non-zero values
in the MPLS label field of the PTA, nor does this profile require the
use of the PE Distinguisher Labels attribute.
4.2. Joining an MP2MP LSP
When a PE receives one of the S-PMSI A-D routes mentioned in the
previous section, it may or may not need to invoke MLDP signaling
procedures to join the specified MP2MP LSP. In particular, a PE MUST
NOT join the specified MP2MP LSP unless and until it has a need to do
so. This is discussed in subsequent sub-sections.
Rosen, et al. [Page 9]
Internet Draft draft-rosen-l3vpn-mvpn-profiles-03.txt June 2009
4.2.1. Joining to Receive BSR Messages
Each PE attached to an MVPN needs to know the RP or RPA that
corresponds to each C-group address for which it may need to send or
receive traffic. This information may be preconfigured, but more
likely is known through some automated procedure such as BSR
(Bootstrap Routing Protocol for PIM [BSR]).
If a PE, say PE1, receives a BSR message from a CE which belongs to a
particular MVPN, it needs to transmit BSR messages to the other PEs
attached to that MVPN. It does so by sending the BSR messages over
the MS-PMSI for that MVPN of which it is the root. However, it MUST
also originate another S-PMSI A-D route, with the same PTA, but whose
C-source field specifies the address of the PE itself, and whose
C-group field specifies the ALL-PIM-ROUTERS address (224.0.0.13).
See section 5 of [MVPN]. When this S-PMSI A-D route is received by
the other PEs attached to the MVPN, those other PEs MUST as soon as
possible initiate the LDP signaling necessary to join the MP2MP LSP,
so that they can receive the BSR messages from PE1. of the LSP.
4.2.2. Joining to Send PIM C-Join/Prune Messages
If PE1 needs to direct a PIM C-Join/Prune message to PE2, PE1 MUST
join the LSP advertised in PE2's S-PMSI A-D route. The PIM J/P
messages MUST be sent over that LSP.
Note that multicast data cannot be received over a given LSP unless a
C-Join/Prune message has been sent over that LSP. (Except in the
case of BSR messages discussed previously.) Therefore these
procedures cause a PE to join a particular MP2MP LSP ONLY if the PE
needs to receive data on it. Thus the number of LSPs that actually
get created for a given MVPN is equal to the number of PEs that serve
as ingress PEs for the multicast traffic of that MVPN. In an MVPN
which has its multicast transmitters at a single site, only one LSP
would be required.
Any PIM Hellos that PE1 sends MUST be sent on the LSP advertised in
PE1's own S-PMSI A-D route (i.e., on PE1's MS-PMSI). Thus the need
to send Hellos does not trigger the joining of an LSP.
4.2.3. Joining to Send Data Without Having Sent a C-J/P
If a particular PE is on a "sender only" branch of a C-bidir tree,
then it may need to send C-data that is traveling on the C-bidir tree
without having previously sent a corresponding C-Join. A given PE,
PE1, still sends the data on PE2's LSP if and only if PE1 has
Rosen, et al. [Page 10]
Internet Draft draft-rosen-l3vpn-mvpn-profiles-03.txt June 2009
selected PE2 as the upstream PE for the RPA of the C-bidir tree. PE1
MAY join that tree when it first has data to send on it, or it MAY
join the tree when first recognizes that PE2 is the selected upstream
PE for some RPA of which it knows.
4.2.4. Pruning Oneself from a MP2MP LSP
A PE SHOULD prune itself from an MP2MP LSP whenever it no longer has
a need to send or receive data on that LSP.
4.3. Sending and Receiving C-Multicast Data
When a PE receives multicast data from a CE, it may need to forward
that data to the other PEs. If the data is traveling on a
unidirectional C-tree, the PE sends the data on its own MS-PMSI.
When PE1 receives, from PE2's MS-PMSI, C-multicast data that is
traveling on a unidirectional C-tree, PE MUST discard the data
(without PIM processing) if PE2 is not the PE from which the data was
expected (i.e., if PE2 is not the PE1's selected upstream PE for the
C-root of the C-tree on which the data is traveling).
If PE1 needs to send data traveling on a bidirectional C-tree, it
does so using the procedures specified in [MVPN] section 12.2.3. The
procedures specified therein also detail the conditions under which a
PE must discard data from a bidirectional group when that data is
received on the LSP.
Since data arriving on the "wrong LSP" is always discarded, Assert
processing will never occur. Since Assert processing does not occur,
"single forwarder selection" need not be used (see sections 9 and 5.1
of [MVPN]). That is, PE1 can receive, e.g., (S,G) traffic from PE2
while PE3 receives (S,G) traffic from PE4. This enables the use of
enhanced load balancing procedures. Also, the PIM+GRE profile, this
profile can support the use of anycast source address (e.g.,
anycast-RP).
The Join Suppression and Prune Override procedures still operate as
they normally do on LANs.
Rosen, et al. [Page 11]
Internet Draft draft-rosen-l3vpn-mvpn-profiles-03.txt June 2009
4.4. Encapsulation
The encapsulation specified in [MVPN] section 11.1.3 is used. (See
also [MPLS-MCAST-ENCAPS]). Aggregation of multiple VPNs onto a
single set of P-tunnels is not required by this profile.
4.5. Additional S-PMSIs
This profile REQUIRES support for the use of additional,
"non-default", S-PMSIs, where each S-PMSI is instantiated as an
mLDP-created P2MP or MP2MP LSP.
P2MP LSPs MAY be used for carrying C-multicast traffic that is
traveling along unidirectional shared or source-specific C-trees.
MP2MP LSPs MAY used for carrying C-multicast that is traveling along
bidirectional C-trees.
Multiple data streams MAY be aggregated on a single MP2MP LSP, but
the profile does not require mandatory support for aggregation of
data streams from different VPNs.
The assignment of a particular C-flow or set of C-flows to a
particular S-PMSI MAY be done via the protocol specified in section
7.2.1 of [MVPN]. The protocol will be suitably extended so that it
can identify an mLDP-created MP2MP LSP, and can support the wild card
selectors defined in [MVPN-MSPMSI]. The assignment MAY also be done
by the use of S-PMSI A-D routes. Any given deployment MUST, by
configuration, choose one of these methods.
4.6. Inter-AS Support
Inter-AS support is provided via the non-segmented inter-as tunnels
described in section 8.1 of [MVPN]. Intra-AS I-PMSI A-D routes must
(despite their name) be distributed across AS boundaries.
To set up the inter-AS P-tunnels instantiating a PMSI, it is
necessary for a PE to send mLDP control messages which identify PEs
in other ASes. In order to construct the multicast distribution
trees, P routers processing these messages need to determine the
(IGP) route to the identified PE router. However, In inter-AS VPNs
constructed according to option b of section 10 of RFC 4364, a given
AS does not necessarily have routes to PEs in the other ASes.
Therefore, the mLDP messages will be extended along the lines of the
"PIM MVPN Join Attribute" discussed in section 2.9. This allows the
multicast distribution tree to be properly constructed even if routes
Rosen, et al. [Page 12]
Internet Draft draft-rosen-l3vpn-mvpn-profiles-03.txt June 2009
to PEs in other ASes do not exist in the given AS's IGP, and even if
the routes to those PEs do not exist in BGP.
4.7. Upstream Multicast Hop Determination
Upstream multicast hop determination is exactly as specified in
section 5 of [MVPN].
4.8. Extensions of this Profile
This profile may be extended in the future to add the following
options:
1. Aggregation of traffic from multiple VPNs onto a single
MS-PMSI. This requires support for MPLS upstream-assigned
labels [MPLS-UPSTREAM-LABEL].
2. Support for Segmented Inter-AS P-Tunnels, as described in
section 8.2 of [MVPN]. This will require support for the
"Inter-AS A-D Routes" described in section 8.2.1 of [MVPN].
3. The use of RSVP-TE P2MP LSPs for instantiating S-PMSIs carrying
traffic which is traveling on a unidirectional shared or
source-specific C-tree. (With support of MPLS
upstream-assigned labels, traffic traveling on bidirectional
C-tree from the customer could also be carried over an RSVP-TE
P2MP LSP.)
5. IANA Considerations
This document does not require any actions of IANA.
6. Security Considerations
[VPN] discusses in general the security considerations that pertain
to when the RFC4364 type of VPN is deployed.
[PIM-SM] discusses the security considerations that pertain to the
use of PIM.
[MLDP] discusses the security considerations that pertain to the use
of LDP.
When the PIM+GRE profile is used, the security considerations of
Rosen, et al. [Page 13]
Internet Draft draft-rosen-l3vpn-mvpn-profiles-03.txt June 2009
[MPLS-in-GRE] and [VPN-GRE] also apply.
The security considerations of [MVPN] and [MVPN-BGP] apply.
7. Authors' Addresses
Arjen Boers
Cisco Systems, Inc.
170 Tasman Drive
San Jose, CA, 95134
E-mail: aboers@cisco.com
Yiqun Cai
Cisco Systems, Inc.
170 Tasman Drive
San Jose, CA, 95134
E-mail: ycai@cisco.com
Eric C. Rosen (Editor)
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA, 01719
E-mail: erosen@cisco.com
IJsbrand Wijnands
Cisco Systems, Inc.
De kleetlaan 6a
Diegem 1831
Belgium
E-mail: ice@cisco.com
Rosen, et al. [Page 14]
Internet Draft draft-rosen-l3vpn-mvpn-profiles-03.txt June 2009
8. Normative References
[GRE] RFC 2784, "Generic Routing Encapsulation", D. Farinacci, et.
al., March 2000
[MLDP] "LDP Extensions for P2MP and MP2MP LSPs", I. Minei, K.
Kompella, I. Wijnands, B. Thomas, draft-ietf-mpls-ldp-p2mp-06.txt,
April 2009
[MPLS-MCAST-ENCAPS] "MPLS Multicast Encapsulations", T. Eckert, E.
Rosen, R. Aggarwal, Y. Rekhter, RFC 5332, August 2008
[MVPN] "Multicast in MPLS/BGP IP VPNs", E. Rosen, R. Aggarwal, et.
al., draft-ietf-l3vpn-2547bis-mcast-08.txt, March 2009
[MVPN-BGP] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, C. Kodeboniya,
draft-ietf-l3vpn-2547bis-mcast-bgp-07.txt, April 2009
[MVPN-MSPMSI] "MVPN: Optimized use of PIM, Wild Card Selectors,
Bidirectional Tunnels", draft-rosen-l3vpn-mvpn-mspmsi-04.txt, June
2009
[PIM-ATTRIB] "The PIM Join Attribute Format", A. Boers, IJ. Wijnands,
E. Rosen, RFC 5384, November 2008
[PIM-BIDIR] RFC 5015, "Bidirectional Protocol Independent Multicast
(BIDIR-PIM)", M. Handley, I. Kouvelas, T. Speakman, L. Vicisano,
October 2007
[PIM-SM] RFC 4601 "Protocol Independent Multicast - Sparse Mode
(PIM-SM)", Fenner, Handley, Holbrook, Kouvelas, August 2006
[RFC2119] "Key words for use in RFCs to Indicate Requirement
Levels.", Bradner, March 1997
[VPN] RFC 4364, "BGP/MPLS IP VPNs", Rosen, Rekhter, et. al., February
2006
Rosen, et al. [Page 15]
Internet Draft draft-rosen-l3vpn-mvpn-profiles-03.txt June 2009
9. Informative References
[BSR], RFC 5059, "Bootstrap Router Mechanism for PIM", N. Bhaskar, A.
Gall, J. Lingard, S. Venaas, January 2008.
[MPLS-UPSTREAM-LABEL] "MPLS Upstream Label Assignment and
Context-Specific Label Space", R. Aggarwal, Y. Rekhter, E. Rosen, RFC
5331, August 2008
[MP-RSVP-TE] RFC 4875, "Extensions to RSVP-TE P2MP TE LSPs" R.
Aggarwal, Ed., D. Papadimitriou, Ed., S. Yasukawa, Ed.. May 2007
[MPLS-in-GRE] RFC 4023, "Encapsulating MPLS in IP or Generic Routing
Encapsulation (GRE)", T. Worster, Y. Rekhter, E. Rosen, March 2005
[VPN-GRE] RFC 4797, "Use of PE-PE GRE or IP in BGP/MPLS IP VPNs", Y.
Rekhter, R. Bonica, E. Rosen, January 2007
[ORIGINAL-MVPN] "Multicast in MPLS/BGP IP VPNs", E. Rosen, Y. Cai,
IJ. Wijnands, draft-rosen-vpn-mcast-11.txt, June 2009
Rosen, et al. [Page 16]