[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03                                                   
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]