[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-raggarwa-l3vpn-2547bis-mcast-bgp) 00 01 02 03 04 05 06 07 08 RFC 6514

Network Working Group                                        R. Aggarwal
Internet Draft                                          Juniper Networks
Expiration Date: January 2008
Intended Status: Proposed Standard
                                                                E. Rosen
                                                     Cisco Systems, Inc.

                                                                T. Morin
                                                          France Telecom

                                                              Y. Rekhter
                                                        Juniper Networks

                                                           C. Kodeboniya


                                                               July 2007


     BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs


               draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt

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.






Raggarwa                                                        [Page 1]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


Abstract

   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].














































Raggarwa                                                        [Page 2]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


Table of Contents

 1          Specification of requirements  .........................   4
 2          Introduction  ..........................................   5
 3          Terminology  ...........................................   5
 4          MCAST-VPN NLRI  ........................................   6
 4.1        Intra-AS I-PMSI auto-discovery route  ..................   7
 4.2        Inter-AS I-PMSI auto-discovery route  ..................   8
 4.3        S-PMSI auto-discovery route  ...........................   8
 4.4        Leaf auto-discovery route  .............................   9
 4.5        Source Active auto-discovery route  ....................   9
 4.6        C-multicast route  .....................................  10
 5          P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute  11
 6          Source AS Extended Community  ..........................  13
 7          VRF Route Import Extended Community  ...................  14
 8          MVPN Auto-Discovery/Binding  ...........................  15
 8.1        MVPN Auto-Discovery/Binding - Intra-AS Operations  .....  15
 8.1.1      Originating (intra-AS) auto-discovery routes  ..........  15
 8.1.2      When not to originate (intra-AS) auto-discovery routes .  17
 8.1.3      Receiving (intra-AS) auto-discovery routes  ............  17
 8.2        MVPN Auto-Discovery/Binding - Inter-AS Operations  .....  19
 8.2.1      Originating inter-AS auto-discovery routes  ............  20
 8.2.2      When not to originate inter-AS auto-discovery routes  ..  21
 8.2.3      Propagating inter-AS auto-discovery routes  ............  21
 8.2.3.1    Propagating inter-AS auto-discovery routes - Overview  .  21
 8.2.3.2    Inter-AS auto-discovery route received via EBGP  .......  22
 8.2.3.3    Leaf auto-discovery route received via EBGP  ...........  24
 8.2.3.4    Inter-AS auto-discovery route received via IBGP  .......  24
 8.2.3.5    Leaf auto-discovery route received via IBGP  ...........  27
 9          Non-congruent Unicast and Multicast Connectivity  ......  27
10          VPN C-Multicast Routing Information Exchange among PEs .  29
10.1        Originating C-multicast routes by a PE  ................  29
10.1.1      Originating routes with PIM as the C-Multicast protocol.  29
10.1.1.1    Originating Source Tree Join C-multicast route  ........  29
10.1.1.2    Originating Shared Tree Join C-multicast route  ........  29
10.1.2      Originating routes with mLDP as the C-Multicast protocol  30
10.1.3      Constructing the rest of the C-multicast route  ........  30
10.1.4      Unicast Route Changes  .................................  32
10.2        Propagating C-multicast routes by an ASBR  .............  32
10.3        Receiving C-multicast routes by a PE  ..................  33
10.3.1      Receiving routes with PIM as the C-Multicast protocol  .  33
10.3.1.1    Receiving Source Tree Join C-multicast route  ..........  34
10.3.1.2    Receiving Shared Tree Join C-multicast route  ..........  34
10.3.2      Receiving routes with mLDP as the C-Multicast protocol  . 34



Raggarwa                                                        [Page 3]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


10.4        C-multicast routes aggregation  ........................  35
11          Switching to S-PMSI  ...................................  36
11.1        Originating S-PMSI auto-discovery routes  ..............  36
11.2        Handling S-PMSI auto-discovery routes by ASBRs  ........  37
11.3        Receiving S-PMSI auto-discovery routes by PEs  .........  37
12          Carrier's Carrier  .....................................  38
13          Choosing a single forwarder PE when switching from RPT to SPT  38
13.1        Source Within a Site - Source Active Advertisement  ....  39
13.2        Receiving Source Active auto-discovery route  ..........  39
13.2.1      Pruning Sources off the Shared Tree  ...................  40
14          Supporting PIM-SM without inter-site Shared Trees  .....  41
14.1        Multicast Source Within a Site - Source Active Advertisement  41
14.2        Receiver(s) Within a Site  .............................  42
14.3        Receiving C-multicast routes by a PE  ..................  43
15          Scalability Considerations  ............................  43
16          Dampening C-multicast routes  ..........................  44
16.1        Dampening withdrawals of C-multicast routes  ...........  45
16.2        Dampening Source/Shared Tree Join C-multicast routes  ..  45
17          Dampening withdrawals of leaf auto-discovery routes  ...  46
18          IANA Consideration  ....................................  46
19          Security Considerations  ...............................  46
20          Acknowledgement  .......................................  46
21          References  ............................................  46
21.1        Normative References  ..................................  46
21.2        Informative References  ................................  47
22          Author Information  ....................................  48
23          Intellectual Property Statement  .......................  48
24          Copyright Notice  ......................................  49






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].












Raggarwa                                                        [Page 4]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


2. Introduction

   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]. This document assumes a thorough
   familiarity with procedures, concepts and terms described in [MVPN].

   This document defines a new NLRI, MCAST-VPN NLRI. The MCAST-VPN NLRI
   is used for MVPN auto-discovery, advertising MVPN to I-PMSI tunnel
   binding, advertising <C-S, C-G> to S-PMSI tunnel binding, VPN
   customer multicast routing information exchange among PEs, choosing a
   single forwarder PE, and for procedures in support of co-locating a
   C-RP on a PE.

   This document specifies a new BGP attribute, P-Multicast Service
   Interface Tunnel (PMSI Tunnel) attribute.

   This document also defines two new BGP Extended Communities, Source
   AS Extended Community and VRF Route Import Extended Community.


3. Terminology

   In the context of this document we will refer to the MVPN auto-
   discovery/binding information carried in BGP as "auto-discovery
   routes". For a given MVPN there are the following types of auto-
   discovery routes:

     + intra-AS auto-discovery route (auto-discovery route);

     + inter-AS auto-discovery route;

     + S-PMSI auto-discovery route;

     + intra-AS segment leaf auto-discovery route (leaf auto-discovery
       route);

     + Source Active auto-discovery route.

   In the context of this document we will refer to the MVPN customers
   multicast routing information carried in BGP as "C-multicast routes".
   For a given MVPN there are the following types of C-multicast routes:

     + Shared Tree Join route;







Raggarwa                                                        [Page 5]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


     + Source Tree Join route;


   For each MVPN present on a PE, the PE maintains a Tree Information
   Base (MVPN-TIB). This is the same as TIB defined in [RFC4601], except
   that instead of a single TIB a PE maintains multiple MVPN-TIBs, one
   per each MVPN.


4. MCAST-VPN NLRI

   This document defines a new BGP NLRI, called the MCAST-VPN NLRI.

   Following is the format of the MCAST-VPN NLRI:

                +-----------------------------------+
                |    Route Type (1 octet)           |
                +-----------------------------------+
                |     Length (1 octet)              |
                +-----------------------------------+
                | Route Type specific (variable)    |
                +-----------------------------------+


   The Route Type field defines encoding of the rest of MCAST-VPN NLRI
   (Route Type specific MCAST-VPN NLRI).

   The Length field indicates the length in octets of the Route Type
   specific field of MCAST-VPN NLRI.

   This document defines the following Route Types for auto-discovery
   routes:

     + 1 - Intra-AS I-PMSI auto-discovery route (or just auto-discovery
       route);
     + 2 - Inter-AS I-PMSI auto-discovery route (or just inter-AS auto-
       discovery route);
     + 3 - S-PMSI auto-discovery route;
     + 4 - Intra-AS segment leaf auto-discovery route (or just leaf
       auto-discovery route).
     + 5 - Source Active auto-discovery route.

   This document defines the following Route Types for C-multicast
   routes:







Raggarwa                                                        [Page 6]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


     + 6 - Shared Tree Join route;
     + 7 - Source Tree Join route;

   The MCAST-VPN NLRI is carried in BGP [RFC4271] using BGP
   Multiprotocol Extensions [RFC4760] with an AFI of 1 or 2 and an SAFI
   of MCAST-VPN.  The NLRI field in the MP_REACH_NLRI/MP_UNREACH_NLRI
   attribute contains the MCAST-VPN NLRI (encoded as specified above).
   The value of the AFI field in the MP_REACH_NLRI/MP_UNREACH_NLRI
   attribute that carries the MCAST-VPN NLRI determines whether the
   Multicast Source and Multicast Group addresses carried in the S-PMSI
   auto-discovery routes, Source Active auto-discovery routes, and C-
   multicast routes are IPv4 or IPv6 addresses (AFI 1 indicates IPv4
   addresses, AFI 2 indicates IPv6 addresses).

   In order for two BGP speakers to exchange labeled MCAST-VPN NLRI,
   they must use BGP Capabilities Advertisement to ensure that they both
   are capable of properly processing such NLRI. This is done as
   specified in [RFC4760], by using capability code 1 (multiprotocol
   BGP) with an AFI of 1 or 2 and an SAFI of MCAST-VPN.

   The following describes the format of the Route Type specific MCAST-
   VPN NLRI for various Route Types defined in this document.


4.1. Intra-AS I-PMSI auto-discovery route

   An intra-AS I-PMSI auto-discovery route type specific MCAST-VPN NLRI
   consists of the following:

                +-----------------------------------+
                |      RD   (8 octets)              |
                +-----------------------------------+
                |   Originating Router's IP Addr    |
                +-----------------------------------+

   The RD is encoded as described in [RFC4364].

   Usage of intra-AS I-PMSI auto-discovery routes is described in
   Section "MVPN Auto-Discovery/Binding - Intra-AS Operations".












Raggarwa                                                        [Page 7]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


4.2. Inter-AS I-PMSI auto-discovery route

   An inter-AS I-PMSI auto-discovery route type specific MCAST-VPN NLRI
   consists of the following:

                +-----------------------------------+
                |      RD   (8 octets)              |
                +-----------------------------------+
                |      Source AS (4 octets)         |
                +-----------------------------------+

   The RD is encoded as described in [RFC4364].

   The Source AS contains an Autonomous System number.  Two octets AS
   numbers are encoded in the low order two octets of the Source AS
   field.

   Usage of inter-AS I-PMSI auto-discovery routes is described in
   Section "MVPN Auto-Discovery/Binding - Inter-AS Operations".


4.3. S-PMSI auto-discovery route

   An S-PMSI auto-discovery route type specific MCAST-VPN NLRI consists
   of the following:

                +-----------------------------------+
                |      RD   (8 octets)              |
                +-----------------------------------+
                | Multicast Source Length (1 octet) |
                +-----------------------------------+
                |  Multicast Source (Variable)      |
                +-----------------------------------+
                |  Multicast Group Length (1 octet) |
                +-----------------------------------+
                |  Multicast Group   (Variable)     |
                +-----------------------------------+
                |   Originating Router's IP Addr    |
                +-----------------------------------+

   The RD is encoded as described in [RFC4364].

   The Multicast Source field contains the C-S address. If the Multicast
   Source field contains an IPv4 address, then the value of the
   Multicast Source Length field is 32. If the Multicast Source field
   contains an IPv6 address, then the value of the Multicast Source
   Length field is 128.




Raggarwa                                                        [Page 8]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


   The Multicast Group field contains the C-G address or C-Generic LSP
   Identifier Value. If the Multicast Group field contains an IPv4
   address or a C-Generic LSP Identifier Value, then the value of the
   Multicast Group Length field is 32. If the Multicast Group field
   contains an IPv6 address, then the value of the Multicast Group
   Length field is 128.

   Usage of S-PMSI auto-discovery routes is described in Section
   "Switching to S-PMSI".


4.4. Leaf auto-discovery route

   A leaf auto-discovery route type specific MCAST-VPN NLRI consists of
   the following:

                +-----------------------------------+
                |      Route Key (variable)         |
                +-----------------------------------+
                |   Originating Router's IP Addr    |
                +-----------------------------------+

   Usage of Leaf auto-discovery routes is described in Section "MVPN
   Auto-Discovery/Binding - Inter-AS Operations".


4.5. Source Active auto-discovery route

   A Source Active auto-discovery route type specific MCAST-VPN NLRI
   consists of the following:

                +-----------------------------------+
                |      RD   (8 octets)              |
                +-----------------------------------+
                | Multicast Source Length (1 octet) |
                +-----------------------------------+
                |   Multicast Source (Variable)     |
                +-----------------------------------+
                |  Multicast Group Length (1 octet) |
                +-----------------------------------+
                |  Multicast Group   (Variable)     |
                +-----------------------------------+

   The RD is encoded as described in [RFC4364].

   The Multicast Source field contains the C-S address. If the Multicast
   Source field contains an IPv4 address, then the value of the
   Multicast Source Length field is 32. If the Multicast Source field



Raggarwa                                                        [Page 9]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


   contains an IPv6 address, then the value of the Multicast Source
   Length field is 128.

   The Group Address field contains the C-G address. If the Multicast
   Group field contains an IPv4 address, then the value of the Multicast
   Group Length field is 32. If the Multicast Group field contains an
   IPv6 address, then the value of the Multicast Group Length field is
   128.

   Source Active auto-discovery routes with a Multicast group belonging
   to the Source Specific Multicast (SSM) range (as defined in
   [RFC4607], and potentially extended locally on a router) MUST NOT be
   advertised by a router and MUST be discarded if received.

   Usage of Source Active auto-discovery routes is described in Sections
   "Choosing a single forwarder PE when switching from RPT to SPT", and
   "Supporting PIM-SM without inter-site Shared Trees".


4.6. C-multicast route

   A Shared Tree Join route and a Source Tree Join route type specific
   MCAST-VPN NLRI consists of the following:

                +-----------------------------------+
                |      RD   (8 octets)              |
                +-----------------------------------+
                |    Source AS (4 octets)           |
                +-----------------------------------+
                | Multicast Source Length (1 octet) |
                +-----------------------------------+
                |   Multicast Source (Variable)     |
                +-----------------------------------+
                |  Multicast Group Length (1 octet) |
                +-----------------------------------+
                |  Multicast Group   (Variable)     |
                +-----------------------------------+

   The RD is encoded as described in [RFC4364].

   The Source AS contains an Autonomous System number. Two octets AS
   numbers are encoded in the low order two octets of the Source AS
   field.

   For a Shared Tree Join route the Multicast Source field contains the
   C-RP address; for a Source Tree Join route the Multicast Source field
   contains the C-S address. If the Multicast Source field contains an
   IPv4 address, then the value of the Multicast Source Length field is



Raggarwa                                                       [Page 10]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


   32. If the Multicast Source field contains an IPv6 address, then the
   value of the Multicast Source Length field is 128.

   The Group Address field contains the C-G address or C-Generic LSP
   Identifier Value. If the Multicast Group field contains an IPv4
   address or C-Generic LSP Identifier Value, then the value of the
   Multicast Group Length field is 32. If the Multicast Group field
   contains an IPv6 address, then the value of the Multicast Group
   Length field is 128.

   Usage of C-multicast routes is described in Section "VPN C-multicast
   Routing Information Exchange among PEs".


5. P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute

   This document defines and uses a new BGP attribute, called P-
   Multicast Service Interface Tunnel (PMSI Tunnel) attribute. This is
   an optional transitive BGP attribute. The format of this attribute is
   defined as follows:

                +---------------------------------+
                |  Flags (1 octet)                |
                +---------------------------------+
                |  Tunnel Type (1 octets)         |
                +---------------------------------+
                |  MPLS Label (3 octets)          |
                +---------------------------------+
                |  Tunnel Identifier (variable)   |
                +---------------------------------+

   The Flags field has the following format:

                 0 1 2 3 4 5 6 7
                +-+-+-+-+-+-+-+-+
                |  reserved   |L|
                +-+-+-+-+-+-+-+-+

   This document defines the following flags:

     + Leaf Information Required (L)

   The Tunnel Type identifies the type of the tunneling technology used
   to establish the PMSI tunnel. The type determines the syntax and
   semantics of the Tunnel Identifier field. This document defines the
   following Tunnel Types:





Raggarwa                                                       [Page 11]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


     + 1 - RSVP-TE P2MP LSP
     + 2 - LDP P2MP LSP
     + 3 - PIM-SSM Tree
     + 4 - PIM-SM Tree
     + 5 - PIM-Bidir Tree
     + 6 - Ingress Replication
     + 7 - LDP MP2MP LSP

   If the MPLS Label field is non-zero, then it contains an MPLS label
   encoded as 3 octets, where the high-order 20 bits contain the label
   value. Absence of MPLS Label is indicated by setting the MPLS Label
   field to zero.

   When the type is set to RSVP-TE P2MP LSP, the Tunnel Identifier is
   <Extended Tunnel ID, P2MP ID> as carried in the RSVP-TE P2MP LSP
   SESSION Object [RSVP-TE-P2MP].

   When the type is set to LDP P2MP LSP, the Tunnel Identifier is <Root
   Node Address, Generic LSP Identifier Value>, as carried in the P2MP
   FEC [mLDP].

   When the type is set to PIM-SM Tree, the Tunnel Identifier is <Sender
   Address, P-Multicast Group>. The node that originated the attribute
   MUST use the address carried in the Sender Address as the source IP
   address for the IP/GRE encapsulation of the MVPN data.

   When the type is set to PIM-SSM Tree, the Tunnel Identifier is <P-
   Root Node Address, P-Multicast Group>. The node that originates the
   attribute MUST use the address carried in the P-Root Node Address as
   the source IP address for the IP/GRE encapsulation of the MVPN data.
   The P-Multicast Group element of the Tunnel identifier of the Tunnel
   attribute MUST NOT expected to be the same group for all intra-AS
   auto-dicovery routes for the same MVPN. According to [RFC4607], the
   group address can be locallty allocated by the originating PE without
   any consideration for the group address used by other PE on the same
   MVPN.

   When the type is set to PIM-Bidir Tree, the Tunnel Identifier is
   <Sender Address, P-Multicast Group>. The node that originated the
   attribute MUST use the address carried in the Sender Address as the
   source IP address for the IP/GRE encapsulation of the MVPN data.

   When the type is set to  PIM-SM or PIM-Bidir tree, then the P-
   Multicast group element of the Tunnel identifier of the Tunnel
   attribute SHOULD be the same multicast group address for all intra-AS
   auto-discovery routes for the same MVPN originated by PEs within a
   given AS. How this multicast group address is chosen is outside the
   scope of this specification.



Raggarwa                                                       [Page 12]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


   When the type is set to Ingress Replication the Tunnel Identifier
   carries the unicast tunnel endpoint IP address.

   When the type is set to LDP MP2MP LSP, the Tunnel Identifier is <P-
   Root Node Address, Generic LSP Identifier Value>, as carried in the
   MP2MP FEC [mLDP]. The Generic LSP Identifier Value SHOULD be the same
   for all intra-AS auto-discovery routes for the same MVPN originated
   by PEs within a given AS. How this Value is chosen is outside the
   scope of this specification.

   If LDP MP2MP LSPs are used as PMSI tunnels, the router that
   transmitted a given packet into the tunnel cannot be identified.  As
   a result, LDP MP2MP LSPs do not support aggregation, and therefore
   can only be used as unaggregated tunnels. Support of aggregation with
   LDP MP2MP LSPs is a matter for further study. In addition, if an LDP
   MP2MP LSP is used within a given AS as an intra-AS segment of an
   inter-AS tunnel, a single ASBR within that AS must be chosen to be
   the one which transmits packets to and from the upstream segment of
   the inter-AS tunnel. In the absence of the procedures for doing this,
   LDP MP2MP LSPs can not be used for intra-AS segments of inter-AS
   tunnels. Procedures for choosing a single ASBR are a matter for
   further study. Finally, use of LDP MP2MP LSPs makes choosing a single
   forwarder PE (see Section "Choosing a single forwarder PE when
   switching from RPT to SPT") mandatory.

   The PMSI Tunnel attribute is used in conjunction with intra-AS and
   inter-AS I-PMSI auto-discovery routes, with S-PMSI auto-discovery
   routes, and with leaf auto-discovery routes.


6. Source AS Extended Community

   This document defines a new BGP extended community called Source AS.

   The Source AS is an AS specific extended community, of an extended
   type, and is transitive across AS boundaries [RFC4360].

   To support MVPN a PE that originates a (unicast) route to VPN-IP
   addresses MUST include in the BGP Update message that carries this
   route the Source AS extended community, except if it is known a
   priori that none of these addresses will act as multicast sources
   and/or RP, in which case the (unicast) route need not carry the
   Source AS extended community. The Global Administrator field of this
   community MUST be set to the autonomous system number of the PE. The
   Local Administrator field of this community MUST be set to 0.

   Usage of the Source AS extended community is described in Section
   "Constructing the rest of the C-multicast route".



Raggarwa                                                       [Page 13]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


7. VRF Route Import Extended Community

   This document defines a new BGP extended community called VRF Route
   Import.

   The VRF Route Import is an IP address specific extended community, of
   an extended type, and is transitive across AS boundaries [RFC4360].

   To support MVPN in addition to the import/export Route Target(s)
   extended communities used by the unicast routing, each VRF on a PE
   MUST have an import Route Target extended community, except if it is
   known a priori that none of the (local) MVPN sites associated with
   the VRF contain multicast source(s) and/or RP, in which case the VRF
   need not have this import Route Target. This Router Target extended
   community MUST be unique to this VRF, and MUST be an IP address
   specific extended community. It is constructed as follows:

     + The Global Administrator field of the Route Target MUST be set to
       an IP address of the PE. This address SHOULD be common for all
       the VRFs on the PE (e.,g., this address may be PE's loopback
       address).

     + The Local Administrator field of the Route Target associated with
       a given VRF contains a 2 octets long number that uniquely
       identifies that VRF within the PE that contains the VRF
       (procedures for assigning such numbers are purely local to the
       PE, and outside the scope of this document).

   A PE that originates a (unicast) route to VPN-IP addresses MUST
   include in the BGP Updates message that carries this route the VRF
   Route Import extended community that has the value of this Route
   Target, except if it is known a priori that none of these addresses
   will act as multicast sources and/or RP, in which case the (unicast)
   route need not carry the VRF Route Import extended community.

   If a PE uses Route Target Constrain [RT-CONSTRAIN], the PE SHOULD
   advertise all such import Route Targets using Route Target Constrains
   (note that doing this requires just a single Route Target Constraint
   advertisement by the PE). This allows each C-multicast route to reach
   only the relevant PE. To constrain distribution of the Route Target
   Constrain routes to the AS of the advertising PE these routes SHOULD
   carry the NO_EXPORT Community ([RFC1997]).

   Usage of VRF Route Import extended community is described in Section
   "Constructing the rest of the C-multicast route".






Raggarwa                                                       [Page 14]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


8. MVPN Auto-Discovery/Binding

   This section specifies procedures for the auto-discovery of MVPN
   memberships and the distribution of information used to instantiate
   I-PMSIs.

   MVPN auto-discovery/binding consists of two components: intra-AS and
   inter-AS. The former provides MVPN auto-discovery/binding within a
   single AS. The latter provides MVPN auto-discovery/binding across
   multiple ASes.

   Note that the inter-AS component applies only to the ASes that use
   either option (b) or (c) for unicast inter-AS operations, as
   specified in Section "Multi-AS Backbones" of [RFC4364]. ASes that use
   option (a) need only the intra-AS component.


8.1. MVPN Auto-Discovery/Binding - Intra-AS Operations

   This section describes exchanges of auto-discovery routes
   originated/received by PEs within the same AS.


8.1.1. Originating (intra-AS) auto-discovery routes

   To participate in the MVPN auto-discovery/binding a PE router that
   has a given VRF of a given MVPN MUST, except for the cases specified
   in Section "When not to originate (intra-AS) auto-discovery route",
   originate an auto-discovery route and advertises this route in IBGP.
   The route is constructed as follows.

   The route carries a single MCAST-VPN NLRI with the RD set to the RD
   of the VRF, and the Originating Router's IP Address field set to the
   IP address that the PE places in the Global Administrator field of
   the VRF Route Import extended community of the VPN-IP routes
   advertised by the PE. Note that the <RD, Originating Router's IP
   address> tuple uniquely identifies a given multicast VRF.

   The route carries the PMSI Tunnel attribute if and only if a default
   I-PMSI is used for the MVPN.  Depending on the technology used to
   instantiate the provider tunnel for the MVPN on the PE, the PMSI
   Tunnel attribute of the intra-AS auto-discovery route is constructed
   as follows.

     + If the PE that originates the advertisement uses a P-Multicast
       tree to instantiate the provider tunnel for the MVPN, the PMSI
       Tunnel attribute MUST contain the identity of the tree that is
       used to instantiate the tunnel (note that the PE could create the



Raggarwa                                                       [Page 15]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


       identity of the tree prior to the actual instantiation of the
       tunnel). If in order to instantiate the provider tunnel the PE
       needs to know the leaves of the tree, then the PE obtains this
       information from the intra-AS auto-discovery routes received from
       other PEs.

     + A PE that uses a P-Multicast tree to instantiate the provider
       tunnel MAY aggregate two or more MVPNs present on the PE onto the
       same tree. If the PE already advertises intra-AS auto-discovery
       routes for these MVPNs, then aggregation requires the PE to re-
       advertise these routes. The re-advertised routes MUST be the same
       as the original ones, except for the PMSI Tunnel attribute. If
       the PE has not previously advertised intra-AS auto-discovery
       routes for these MVPNs, then the aggregation requires the PE to
       advertise (new) intra-AS auto-discovery routes for these MVPNs.
       The PMSI Tunnel attribute in the newly advertised/re-advertised
       routes MUST carry the identity of the P-Multicast tree that
       aggregates the MVPNs, as well as an MPLS upstream assigned label
       [MPLS-UPSTREAM]. Each re-advertised route MUST have a distinct
       label.

     + If the PE that originates the advertisement uses ingress
       replication to instantiate the provider tunnel for the MVPN, the
       route MUST include the PMSI Tunnel attribute with the Tunnel Type
       set to Ingress Replication and Tunnel Identifier set to a
       routable address of the PE. The PMSI Tunnel attribute MUST carry
       a downstream assigned MPLS label. This label is used to
       demultiplex the MVPN traffic received over a unicast tunnel by
       the PE.

   Discovery of PE capabilities in terms of what tunnels types they
   support is outside the scope of this document. Within a given AS PEs
   participating in an MVPN are expected to advertise tunnel bindings
   whose tunnel types are supported by all other PEs that are
   participating in this MVPN and are part of the same AS.

   The Next Hop field of the MP_REACH_NLRI attribute of the route SHOULD
   be set to the same IP address as the one carried in the Originating
   Router's IP Address field.

   By default the distribution of the auto-discovery routes is
   controlled by the same Route Targets as the ones used for the
   distribution of VPN-IP unicast routes. That is, by default the auto-
   discovery route MUST carry the export Route Target used by the
   unicast routing.  If any other PE has one of these Route Targets
   configured as an import Route Target for a VRF present on the PE, it
   treats the advertising PE as a member in the MVPN to which the VRF
   belongs.  The default could be modified via configuration by having a



Raggarwa                                                       [Page 16]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


   set of Route Targets used for the auto-discovery routes being
   distinct from the ones used for the VPN-IP unicast routes (see also
   Section "Non-congruent Unicast and Multicast Connectivity").

   To constrain distribution of the intra-AS membership/binding
   information to the AS of the advertising PE the BGP Update message
   originated by the advertising PE SHOULD carry the NO_EXPORT Community
   ([RFC1997]).


8.1.2. When not to originate (intra-AS) auto-discovery routes

   If for a given MVPN all of its sites connected to a given PE are
   known a priori to have no multicast sources, then this PE is NOT
   REQUIRED to originate an auto-discovery route for that MVPN at all,
   unless either

     + (a) some other PEs that have VRFs in that MVPN and are in the
       same AS as the original PE use RSVP TE P2MP LSPs for that MVPN,
       in which case the PE originates an auto-discovery route, but with
       no PMSI Tunnel attribute, or

     + (b) the PE uses ingress replication for incoming multicast
       traffic of that MVPN, in which case the PE originates an auto-
       discovery route with the PMSI Tunnel attribute indicating ingress
       replication.

   If for a given MVPN all of its sites connected to a given PE are
   known a priori to have no multicast receivers, and the PE uses
   ingress replication for that MVPN then this PE is NOT REQUIRED to
   originate an auto-discovery route for that MVPN at all.


8.1.3. Receiving (intra-AS) auto-discovery routes

   When a PE receives a BGP Update message that carries an auto-
   discovery route such that (a) the route was originated by some other
   PE within the same AS as the local PE, (b) at least one of the Route
   Targets of the route matches one of the import Route Targets
   configured for a particular VRF on the local PE, and (c) the BGP
   route selection determines that this is the best route with respect
   to the NLRI carried by the route, the PE performs the following.

   If the route carries the PMSI Tunnel attribute then:







Raggarwa                                                       [Page 17]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


     + If the Tunnel Type in the PMSI Tunnel attribute is set to Ingress
       Replication, then the MPLS label and the address carried in the
       Tunnel Identifier field of the PMSI Tunnel attribute should be
       used when the local PE sends multicast traffic to the PE that
       originated the route.

     + If the Tunnel Type in the PMSI Tunnel attribute is set to LDP
       P2MP LSP, or PIM-SSM tree, or PIM-SM tree, or PIM-Bidir tree, the
       PE SHOULD join the P-Multicast tree whose identity is carried in
       the Tunnel Identifier.

     + If the Tunnel Type in the PMSI Tunnel attribute is set to RSVP-TE
       P2MP LSP, the receiving PE has to establish the appropriate state
       to properly handle the traffic received over that LSP. The PE
       that originated the route MUST establish an RSVP-TE P2MP LSP with
       the local PE as a leaf. This LSP MAY have been established before
       the local PE receives the route, or MAY be established after the
       local PE receives the route.

     + If the PMSI Tunnel attribute does not carry a label, then all
       packets that are received on the P-Multicast tree, as identified
       by the PMSI Tunnel attribute, are forwarded using the VRF that
       has at least one of its import Route Targets that matches one of
       the Route Targets of the received auto-discovery route.

     + If the PMSI Tunnel attribute has the Tunnel Type set to LDP P2MP
       LSP, or PIM-SSM tree, or PIM-SM tree, or PIM-Bidir tree, or RSVP-
       TE P2MP LSP, and the attribute also carries an MPLS label, then
       this is an upstream assigned label, and all packets that are
       received on the P-Multicast tree, as identified by the PMSI
       Tunnel attribute, with that upstream assigned label are forwarded
       using the VRF that has at least one of its import Route Target
       that matches one of the Route Targets of the received auto-
       discovery route.

   Irrespective of whether the route carries the PMSI Tunnel attribute,
   if the local PE uses RSVP-TE P2MP LSP for sending (multicast) traffic
   from the VRF to the sites attached to other PEs, then the local PE
   uses the Originating Router's IP address information carried in the
   route to add the PE that originated the route as a leaf node to the
   LSP.










Raggarwa                                                       [Page 18]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


8.2. MVPN Auto-Discovery/Binding - Inter-AS Operations

   An Autonomous System Border Router (ASBR) may be configured to
   support a particular MVPN as follows:

     + An ASBR MUST be be configured with a set of (import) Route
       Targets (RTs) that specifies the set of MVPNs supported by the
       ASBR. These Route Targets control acceptance of intra-AS/inter-AS
       auto-discovery routes by the ASBR. As long as unicast and
       multicast connectivity are congruent, this could be the same set
       of Route Targets as the one used for supporting unicast (and
       therefore would not require any additional configuration above
       and beyond of what is required for unicast).

     + The ASBR MUST be configured with an import Route Target that is
       IP address specific. The Global Administrator field of this Route
       Target MUST be set to the IP address carried in the Next Hop of
       all the inter-AS auto-discovery routes and S-PMSI auto-discovery
       routes advertised by this ASBR (if the ASBR uses different Next
       Hops, then the ASBR MUST be configured with multiple import RTs,
       one per each such Next Hop). The Local Administrator field of
       this Route Target MUST be set to 0. If the ASBR supports Route
       Target Constrain [RT-CONSTRAIN], the ASBR SHOULD advertise this
       import Route Target within its own AS using Route Target
       Constrains. Note that this Route Target controls acceptance of
       leaf auto-discovery routes and C-multicast routes by the ASBR,
       and is used to constrain distribution of both leaf auto-discovery
       routes and C-multicast routes (see Section "VPN C-Multicast
       Routing Information Exchange among PEs").  To constrain
       distribution of the Route Target Constrain routes to the AS of
       the advertising ASBR these routes SHOULD carry the NO_EXPORT
       Community ([RFC1997]).

     + The ASBR MUST be configured with the tunnel types for the intra-
       AS segments of the MVPNs supported by the ASBR, as well as
       (depending on the tunnel type) the information needed to create
       the PMSI attribute for these tunnel types.

     + If the ASBR originates an inter-AS auto-discovery route for a
       particular MVPN present on some of the PEs within its own AS, the
       ASBR MUST be configured with an RD for that MVPN. To allow
       aggregation of inter-AS auto-discovery routes it is RECOMMENDED
       that all the ASBRs within an AS that are configured to originate
       an inter-AS auto-discovery route for a particular MVPN be
       configured with the same RD (although for a given MVPN each AS
       may assign this RD on its own, without coordination with other
       ASes).




Raggarwa                                                       [Page 19]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


   If an ASBR is configured to support a particular MVPN, the ASBR MUST
   participate in the intra-AS MVPN auto-discovery/binding procedures
   for that MVPN within the ASBR's own AS, as specified in Section "MVPN
   Auto-Discovery/Binding - Intra-AS Operations".

   Moreover, in addition to the above the ASBR performs the following
   procedures.


8.2.1. Originating inter-AS auto-discovery routes

   For a given MVPN configured on an ASBR when the ASBR determines
   (using the intra-AS auto-discovery procedures) that at least one of
   the PEs of its own AS has (directly) connected site(s) of the MVPN,
   the ASBR originates an inter-AS auto-discovery route and advertises
   it in EBGP. The route is constructed as follows:

     + The route carries a single MCAST-VPN NLRI with the RD set to the
       RD configured for that MVPN on the ASBR, and the Source AS set to
       the Autonomous System number of the ASBR.

     + The route carries the PMSI Tunnel attribute if and only if a
       default I-PMSI is used for the MVPN. The Tunnel Type in the
       attribute is set to Ingress Replication; the attribute carries no
       MPLS labels.

     + The Next Hop field of the MP_REACH_NLRI attribute is set to a
       routable IP address of the ASBR.

     + By default the route MUST carry the export Route Target used by
       the unicast routing of that VPN. The default could be modified
       via configuration by having a set of Route Targets used for the
       inter-AS auto-discovery routes being distinct from the ones used
       by the unicast routing of that VPN (see also Section "Non-
       congruent Unicast and Multicast Connectivity").

   An inter-AS auto-discovery route for a given <AS, MVPN> indicates
   presence of the MVPN sites connected to one or more PEs of the AS.

   An inter-AS auto-discovery route originated by an ASBR aggregates
   (intra-AS) auto-discovery routes originated within the ASBR's own AS.
   Thus while the auto-discovery routes originated within an AS are at
   the granularity of <PE, MVPN> within that AS, outside of that AS the
   (aggregated) inter-AS auto-discovery routes could be at the
   granularity of <AS, MVPN>.






Raggarwa                                                       [Page 20]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


8.2.2. When not to originate inter-AS auto-discovery routes

   If for a given MVPN and a given AS all of its sites connected to the
   PEs within the AS known a priori to have no multicast sources, then
   ASBRs of that AS are NOT REQUIRED to originate an Inter-AS auto-
   discovery route for that MVPN at all.


8.2.3. Propagating inter-AS auto-discovery routes

   An inter-AS auto-discovery route for a given MVPN originated by an
   ASBR within a given AS is propagated via BGP to other ASes.


8.2.3.1. Propagating inter-AS auto-discovery routes - Overview

   Suppose that an ASBR A installs an inter-AS auto-discovery route for
   MVPN V that originated at a particular AS, AS1. The BGP next hop of
   that route becomes A's "upstream multicast hop" on a multicast
   distribution tree for V that is rooted at AS1. When the inter-AS
   auto-discovery routes have been distributed to all the necessary
   ASes, they define a "reverse path" from any AS that supports MVPN V
   back to AS1. For instance, if AS2 supports MVPN V, then there will be
   a reverse path for MVPN V from AS2 to AS1. This path is a sequence of
   ASBRs, the first of which is in AS2, and the last of which is in AS1.
   Each ASBR in the sequence is the BGP next hop of the previous ASBR in
   the sequence on the given inter-AS auto-discovery route.

   This reverse path information can be used to construct a
   unidirectional multicast distribution tree for MVPN V, containing all
   the ASes that support V, and having AS1 at the root. We call such a
   tree an "inter-AS tree". Multicast data originating in MVPN sites
   connected to PEs within a given AS will travel downstream along the
   tree which is rooted at that AS.

   The path along an inter-AS tree is a sequence of ASBRs; it is still
   necessary to specify how the multicast data gets from a given ASBR to
   the set of ASBRs which are immediately downstream of the given ASBR
   along the tree. This is done by creating "segments": ASBRs in
   adjacent ASes will be connected by inter-AS segments, ASBRs in the
   same AS will be connected by "intra-AS segments".

   An ASBR initiates creation of an intra-AS segment when the ASBR
   receives an inter-AS auto-discovery route from an EBGP neighbor.
   Creation of the segment is completed as a result of distributing via
   IBGP this route within the ASBR's own AS.

   For a given inter-AS tunnel each of its intra-AS segments could be



Raggarwa                                                       [Page 21]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


   constructed by its own independent mechanism. Moreover, by using
   upstream assigned labels within a given AS multiple intra-AS segments
   of different inter-AS tunnels of either the same or different MVPNs
   may share the same P-Multicast tree.

   If the P-Multicast tree instantiating a particular segment of an
   inter-AS tunnel is created by a multicast control protocol that uses
   receiver-initiated joins (e.g, mLDP, any PIM variant), and this P-
   Multicast tree does not aggregate multiple segments, then all the
   information needed to create that segment will be present in the
   inter-AS auto-discovery routes. But if the P-Multicast tree
   instantiating the segment is created by a protocol that does not use
   receiver-initiated joins (e.g., RSVP-TE, ingress unicast
   replication), or if this P-Multicast tree aggregates multiple
   segments (irrespective of the multicast control protocol used to
   create the tree), then it is also necessary to use "leaf auto-
   discovery" routes. The precise conditions under which leaf auto-
   discover routes need to be used are described in subsequent sections.

   Since (aggregated) inter-AS auto-discovery routes could have
   granularity of <AS, MVPN>, an MVPN that is present in N ASes could
   have total of N inter-AS tunnels. Thus for a given MVPN the number of
   inter-AS tunnels is independent of the number of PEs that have this
   MVPN.

   The precise rules for distributing and processing the inter-AS auto-
   discovery routes across ASes are given in the following sections.


8.2.3.2. Inter-AS auto-discovery route received via EBGP

   When an ASBR receives from one of its EBGP neighbors a BGP Update
   message that carries an inter-AS auto-discovery route, if (a) at
   least one of the Route Targets carried in the message matches one of
   the import Route Targets configured on the ASBR, and (b) the ASBR
   determines that the received route is the best route to the
   destination carried in the NLRI of the route, the ASBR re-advertises
   this auto-discovery route to other PEs and ASBRs within its own AS
   (handling of this route by other PEs and ASBRs is described in
   Section "Inter-AS auto-discovery route received via IBGP").

   When re-advertising an inter-AS auto-discovery route the ASBR MUST
   set the Next Hop field of the MP_REACH_NLRI attribute to a routable
   IP address of the ASBR.

   If the received inter-AS auto-discovery route carries the PMSI Tunnel
   attribute, then depending on the technology used to instantiate the
   intra-AS segment of the inter-AS tunnel the ASBR constructs the PMSI



Raggarwa                                                       [Page 22]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


   Tunnel attribute of the re-advertised inter-AS auto-discovery route
   as follows.

     + If the ASBR uses ingress replication to instantiate the intra-AS
       segment of the inter-AS tunnel, the re-advertised route MUST
       carry the PMSI Tunnel attribute with the Tunnel Type set to
       Ingress Replication, but no MPLS labels.

     + If the ASBR uses a P-Multicast tree to instantiate the intra-AS
       segment of the inter-AS tunnel, the PMSI Tunnel attribute MUST
       contain the identity of the tree that is used to instantiate the
       segment (note that the ASBR could create the identity of the tree
       prior to the actual instantiation of the segment).  If in order
       to instantiate the segment the ASBR needs to know the leaves of
       the tree, then the ASBR obtains this information from the leaf
       auto-discovery routes received from other PEs/ASBRs in ASBR's own
       AS (as described in Section "Leaf auto-discovery route received
       via IBGP") by setting the Leaf Information Required flag in the
       PMSI Tunnel attribute to 1.

     + An ASBR that uses a P-Multicast tree to instantiate the intra-AS
       segment of the inter-AS tunnel MAY aggregate two or more MVPNs
       present on the ASBR onto the same tree. If the ASBR already
       advertises inter-AS auto-discovery routes for these MVPNs, then
       aggregation requires the ASBR to re-advertise these routes. The
       re-advertised routes MUST be the same as the original ones,
       except for the PMSI Tunnel attribute. If the ASBR has not
       previously advertised inter-AS auto-discovery routes for these
       MVPNs, then the aggregation requires the ASBR to advertise (new)
       inter-AS auto-discovery routes for these MVPN. The PMSI Tunnel
       attribute in the newly advertised/re-advertised routes MUST carry
       the identity of the P-Multicast tree that aggregates the MVPNs,
       as well as an MPLS upstream assigned label [MPLS-UPSTREAM].  Each
       re-advertised route MUST have a distinct label.

   In addition the ASBR MUST send to the EBGP neighbor, from whom it
   receives the inter-AS auto-discovery route, a BGP Update message that
   carries a leaf auto-discovery route constructed as follows.

     + The route carries a single MCAST-VPN NLRI with the Route Key
       field set to the MCAST-VPN NLRI of the inter-AS auto-discovery
       route received from that neighbor and the Originating Router's IP
       address set to the IP address of the ASBR (this MUST be a
       routable IP address).







Raggarwa                                                       [Page 23]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


     + The leaf auto-discovery route MUST include the PMSI Tunnel
       attribute with the Tunnel Type set to Ingress Replication, and
       the Tunnel Identifier set to a routable address of the
       advertising router. The PMSI Tunnel attribute MUST carry a
       downstream assigned MPLS label that is used by the advertising
       router to demultiplex the MVPN traffic received over a unicast
       tunnel from the EBGP neighbor.

     + The ASBR constructs an IP-based Route Target community by placing
       the IP address carried in the next hop of the received inter-AS
       auto-discovery route in the Global Administrator field of the
       community, with the Local Administrator field of this community
       set to 0, and sets the Extended Communities attribute of the leaf
       auto-discovery route to that community.

     + The Next Hop field of the MP_REACH_NLRI attribute of the route
       SHOULD be set to the same IP address as the one carried in the
       Originating Router's IP Address field of the route.

     + To constrain the distribution scope of this route the route MUST
       carry the NO_ADVERTISE BGP community ([RFC1997]).

   Handling of this leaf auto-discovery route by the EBGP neighbor is
   described in Section "Leaf auto-discovery route received via EBGP".


8.2.3.3. Leaf auto-discovery route received via EBGP

   When an ASBR receives via EBGP a leaf auto-discovery route originated
   by its neighbor ASBR, the ASBR accepts the route only if the Route
   Target carried in the Extended Communities attribute of the route
   matches one of the import Route Target configured on the ASBR.

   If the ASBR accepts the leaf auto-discovery route, the ASBR finds an
   inter-AS auto-discovery route whose MCAST-VPN NLRI has the same value
   as the Route Key field of the the leaf auto-discovery route.

   The MPLS label carried in the PMSI Tunnel attribute of the leaf auto-
   discovery route is used to stitch a one hop ASBR-ASBR LSP to the tail
   of the intra-AS tunnel segment associated with the found inter-AS
   auto-discovery route.


8.2.3.4. Inter-AS auto-discovery route received via IBGP

   In the context of this section we use the term "PE/ASBR router" to
   denote either a PE or an ASBR router.




Raggarwa                                                       [Page 24]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


   If a given inter-AS auto-discovery route is received via IBGP by a
   BGP Route Reflector, the BGP Route Reflector MUST NOT modify the Next
   Hop field of the MP_REACH_NLRI attribute when re-advertising the
   route into IBGP (this is because the information carried in the Next
   Hop is used for controling flow of C-multicast routes, as specified
   in Section "Propagating C-multicast routes by an ASBR").

   If a given inter-AS auto-discovery route is advertised within an AS
   by multiple ASBRs of that AS, the BGP best route selection performed
   by other PE/ASBR routers within the AS does not require all these
   PE/ASBR routers to select the route advertised by the same ASBR - to
   the contrary different PE/ASBR routers may select routes advertised
   by different ASBRs.

   When a PE/ASBR router receives from one of its IBGP neighbors a BGP
   Update message that carries an inter-AS auto-discovery route, if (a)
   at least one of the Route Targets carried in the message matches one
   of the import Route Targets configured on the PE/ASBR, and (b) the
   PE/ASBR determines that the received route is the best route to the
   destination carried in the NLRI of the route, the PE/ASBR performs
   the following operations.

   If the router is an ASBR then the ASBR propagates the route to its
   EBGP neighbors. When propagating the route to the EBGP neighbors the
   ASBR MUST set the Next Hop field of the MP_REACH_NLRI attribute to a
   routable IP address of the ASBR. The route MUST carry the PMSI Tunnel
   attribute with the Tunnel Type set to Ingress Replication; the
   attribute carries no MPLS labels.

   If the received inter-AS auto-discovery route carries the PMSI Tunnel
   attribute with the Tunnel Type set to LDP P2MP LSP, or PIM-SSM tree,
   or PIM-SM tree, or PIM-Bidir tree, the PE/ASBR SHOULD join the P-
   Multicast tree whose identity is carried in the Tunnel Identifier.

   If the received inter-AS auto-discovery route carries the PMSI Tunnel
   attribute with the Tunnel Identifier set to RSVP-TE P2MP LSP, then
   the ASBR that originated the route MUST establish an RSVP-TE P2MP LSP
   with the local PE/ASBRas a leaf. This LSP MAY have been established
   before the local PE/ASBR receives the route, or MAY be established
   after the local PE receives the route.

   If the received inter-AS auto-discovery route carries the PMSI Tunnel
   attribute with the Tunnel Type set to LDP P2MP LSP, or RSVP-TE P2MP
   LSP, or PIM-SSM, or PIM-SM tree, or PIM-Bidir tree, but the attribute
   does not carry a label, then the P-Multicast tree, as identified by
   the PMSI Tunnel Attribute, is an intra-AS LSP segment that is part of
   the inter-AS Tunnel for the MVPN advertised by the inter-AS auto-
   discovery route and rooted at the AS that originated the inter-AS



Raggarwa                                                       [Page 25]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


   auto-discovery route. If the PMSI Tunnel attribute carries a
   (upstream assigned) label, then a combination of this tree and the
   label identifies the intra-AS segment. If the received router is an
   ASBR, this intra-AS segment may further be stitched to ASBR-ASBR
   inter-AS segment of the inter-AS tunnel. If the PE/ASBR has local
   receivers in the MVPN, packets received over the intra-AS segment
   must be forwarded to the local receivers using the local VRF.

   If the Leaf Information Required flag in the PMSI Tunnel attribute of
   the received inter-AS auto-discovery route is set to 1, then the
   PE/ASBR MUST originate a new leaf auto-discovery route as follows.

     + The route carries a single MCAST-VPN NLRI with the Route Key
       field set to the MCAST-VPN NLRI of the inter-AS auto-discovery
       route received from that neighbor, and the Originating Router's
       IP address set to the IP address of the ASBR (this MUST be a
       routable IP address).

     + If the received inter-AS auto-discovery route carries the PMSI
       Tunnel attribute with the Tunnel Type set to Ingress Replication,
       then the leaf auto-discovery route MUST carry the PMSI Tunnel
       attribute with the Tunnel Type set to Ingress Replication. The
       Tunnel Identifier MUST carry a routable address of the PE/ASBR.
       The PMSI Tunnel attribute MUST carry a downstream assigned MPLS
       label that is used to demultiplex the MVPN traffic received over
       a unicast tunnel by the PE/ASBR.

     + The PE/ASBR constructs an IP-based Route Target community by
       placing the IP address carried in the next hop of the received
       inter-AS auto-discovery route in the Global Administrator field
       of the community, with the Local Administrator field of this
       community set to 0, and sets the Extended Communities attribute
       of the leaf auto-discovery route to that community.

     + The Next Hop field of the MP_REACH_NLRI attribute of the route
       SHOULD be set to the same IP address as the one carried in the
       Originating Router's IP Address field of the route.

     + To constrain the distribution scope of this route the route MUST
       carry the NO_EXPORT BGP community ([RFC1997]).

     + Once the leaf auto-discovery route is constructed, the PE/ASBR
       advertises this route into IBGP.








Raggarwa                                                       [Page 26]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


8.2.3.5. Leaf auto-discovery route received via IBGP

   When an ASBR receives via IBGP a leaf auto-discovery route, the ASBR
   accepts the route only if the Route Target carried in the Extended
   Communities attribute of the route matches one of the import Route
   Target configured on the ASBR.

   If the ASBR accepts the leaf auto-discovery route, the ASBR finds an
   inter-AS auto-discovery route whose MCAST-VPN NLRI has the same value
   as the Route Key field of the the leaf auto-discovery route.

   The received route may carry either (a) no PMSI Tunnel attribute, or
   (b) the PMSI Tunnel attribute, but only with the Tunnel Type set to
   Ingress Replication.

   If the received route does not carry the PMSI Tunnel attribute, the
   ASBR uses the information from the received route to determine the
   leaves of the P-Multicast tree rooted at the ASBR that would be used
   for the intra-AS segment associated with the found inter-AS auto-
   discovery route. The IP address of a leaf is the IP address carried
   in the Originating Router's IP address field of the received leaf
   auto-discovery route.

   If the received route carries the PMSI Tunnel attribute with the
   Tunnel Type set to Ingress Replication the ASBR uses the information
   carried by the route to construct the intra-AS segment with ingress
   replication.


9. Non-congruent Unicast and Multicast Connectivity

   If the multicast connectivity of a MVPN is congruent to its unicast
   connectivity, the VRF of that MVPN, as referred to by this document,
   means the VRF of that VPN used for unicast routing.

   If the multicast connectivity of a MVPN is non-congruent to its
   unicast connectivity, the VRF of that MVPN, as referred to by this
   document, means the VRF that is distinct from the VRF of that VPN
   used for unicast routing. On a given PE such a VRF may have its own
   import and export Route Targets, different from the ones used by the
   VRF used for unicast routing. These Route Targets are used to control
   distribution of auto-discovery routes. In addition the export Route
   Targets of the VRF are added to the Route Targets used for unicast
   routing when originating (unicast) VPN-IP routes. The import Route
   Targets associated with a given VRF are used to determine which of
   the received (unicast) VPN-IP routes should be accepted into the VRF.

   If an MVPN site is single-homed to a PE, then on this PE the VRF



Raggarwa                                                       [Page 27]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


   associated with the site SHOULD use the same RD as the one used by
   the VRF used for unicast routing of that VPN. If an MVPN site is
   multi-homed to several PEs, then to support non-congruent unicast and
   multicast connectivity on each of these PEs the VRF of the MVPN MUST
   use its own distinct RD (although on a given PE the RD used by the
   VRF of the MVPN SHOULD be the same as the one used by the VRF used
   for unicast routing of that VPN).

   Another non-congruency case is when all the the CE-PE routing for a
   given MVPN uses BGP with Multiprotocol Extensions [RFC4760] with SAFI
   2 "Network Layer Reachability Information used for multicast
   forwarding" [IANA-SAFI] (and either IPv4 or IPv6 AFI). To handle this
   case the routes that a PE receives from a CE over such SAFI are
   placed in the VRF used by MVPN. Such routes are exchanged among PEs
   using the same AFI as the one used for CE-PE routing information
   exchange (either IPv4 or IPv6 AFI), and SAFI set to "Multicast for
   BGP/MPLS IP Virtual Private Networks (VPNs)" [IANA-SAFI].

   The NLRI carried by these routes is defined as follows:

         +---------------------------+
         |   Length (1 octet)        |
         +---------------------------+
         |   Prefix (variable)       |
         +---------------------------+

      The use and the meaning of these fields are as follows:

         a) Length:

            The Length field indicates the length in bits of the address
            prefix plus the label(s).

         b) Prefix:

      The Prefix field contains a Route Distinguisher as defined
      in [RFC 4364] prepended to an IPv4 or IPv6 address prefix,
      followed by enough trailing bits to make the end of the
      field fall on an octet boundary. Note that the value of
      trailing bits is irrelevant.


   These routes MUST carry the VRF Route Import Extended Community and
   Source AS Extended Community. The detailed procedures for selecting
   forwarder PE in the presence of such routes are outside the scope of
   this document.  However, this document requires these procedures to
   preserve the constrains imposed by the single forwarder PE selection
   procedures, as specified in Section "Duplicate Packet Detection and



Raggarwa                                                       [Page 28]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


   Single Forwarder PE" of [MVPN].


10. VPN C-Multicast Routing Information Exchange among PEs

   VPN C-Multicast Routing Information is exchanged among PEs by using
   C-multicast routes that are carried using MCAST-VPN NLRI. These
   routes are originated and propagated as follows.


10.1. Originating C-multicast routes by a PE

   Part of the procedures for constructing MCAST-VPN NLRI depend on the
   multicast routing protocol between CE and PE (C-multicast protocol).


10.1.1. Originating routes with PIM as the C-Multicast protocol

   The following specifies construction of MCAST-VPN NLRI of C-multicast
   routes for the case where the C-multicast protocol is PIM. These C-
   multicast routes are originated as a result of updates in <C-S, C-G>,
   or <C-*, C-G> state learnt by a PE via the C-multicast protocol.


10.1.1.1. Originating Source Tree Join C-multicast route

   Whenever a PE creates a new <C-S,C-G> state in one of its MVPN-TIBs,
   if C-S is reachable through some other PE the local PE originates a
   C-multicast route of a type Source Tree Join. The Multicast Source
   field in the MCAST-VPN NLRI of the route is set to C-S, the Multicast
   Group field is set of C-G.

   The semantics of the route is that the PE has one or more receivers
   for <C-S, C-G> in the sites connected to the PE (the route has the
   <C-S, C-G> Join semantics).

   Whenever a PE deletes a previously created <C-S, C-G> state that had
   resulted in originating a C-multicast route, the PE withdraws the
   route (the withdrawn route has the <C-S, C-G> Prune semantics).  The
   MCAST-VPN NLRI of the withdrawn route is carried in the
   MP_UNREACH_NLRI attribute.


10.1.1.2. Originating Shared Tree Join C-multicast route

   Whenever a PE creates a new <C-*, C-G> state in one of its MVPN-TIBs,
   if the C-RP for C-G is reachable through some other PE the local PE
   originates a C-multicast route of a type Shared Tree Join. The



Raggarwa                                                       [Page 29]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


   Multicast Source field in the MCAST-VPN NLRI of the route is set to
   the C-RP address. The Multicast Group field in the MCAST-VPN NLRI is
   set to the C-G address.

   The semantics of the route is that the PE has one or more receivers
   for <C-*, C-G> in the sites connected to the PE (the route has the
   <C-*, C-G> Join semantics).

   Whenever a PE deletes a previously created <C-*, C-G> state that had
   resulted in originating a C-multicast route, the PE withdraws the
   route (the withdrawn route has the <C-*, C-G> Prune semantics).  The
   MCAST-VPN NLRI of the withdrawn route is carried in the
   MP_UNREACH_NLRI attribute.



10.1.2. Originating routes with mLDP as the C-Multicast protocol

   The following specifies construction of MCAST-VPN NLRI of C-multicast
   routes for the case where the C-multicast protocol is mLDP [mLDP].

   Whenever a PE receives from one of its CEs a P2MP Label Map <X, Y, L>
   over interface I, where X is the Root Node Address, Y is the Opaque
   Value, and L is an MPLS label, the PE checks whether it already has
   state for <X, Y> in the VRF associated with the CE. If yes, then all
   the PE needs to do in this case is to update its forwarding state by
   adding <I, L> to the forwarding state associated with <X, Y>.

   If the PE does not have state for <X, Y> in the VRF associated with
   the CE, then the PE constructs a Source Tree Join C-multicast route
   whose MCAST-VPN NLRI contains X as the Multicast Source field, and Y
   as the Multicast Group field.

   Whenever a PE deletes a previously created <X, Y> state that had
   resulted in originating a C-multicast route, the PE withdraws the C-
   multicast route. The MCAST-VPN NLRI of the withdrawn route is carried
   in the MP_UNREACH_NLRI attribute.


10.1.3. Constructing the rest of the C-multicast route

   The rest of the C-multicast route is constructed as follows (the same
   procedures apply to both PIM and mLDP as the C-Multicast protocol).

   The (local) PE uses its VRF to find (a) the autonomous system number
   of the (remote) PE that originates the (unicast) route to the address
   carried in the Multicast Source field of MCAST-VPN NLRI, and (b) the
   import Route Target Extended Community associated with the VRF on the



Raggarwa                                                       [Page 30]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


   remote PE which was used to originate the route (the value of this
   import Route Target is the value of the VRF Route Import Extended
   Community carried in the unicast VPN-IP routing advertisements by the
   remote PE). The Source AS field in the C-multicast route is set to
   the found autonomous system. The Route Target Extended Community of
   the C-multicast route is set to the found Route Target (the Route
   Target constructed from the VRF Route Import).

   If there is more than one (remote) PE that originates the (unicast)
   route to the address carried in the Multicast Source field of the
   MCAST-VPN NLRI, then the procedures for selecting an upstream PE to
   reach that address are as specified in [MVPN].

   If the local and the remote PEs are in the same AS, then the RD of
   the advertised MCAST-VPN NLRI is set to the RD of the VPN-IP route
   that contains the address carried in the Multicast Source field.  The
   C-multicast route is then advertised into IBGP.

   If the local and the remote PEs are in different ASes, then the local
   PE finds in its VRF an inter-AS auto-discovery route whose Source AS
   field carries the autonomous system number of the remote PE that
   originates the (unicast) route to the address carried in the
   Multicast Source field. The RD of the found inter-AS auto-discovery
   route is used as the RD of the advertised C-multicast route. The
   local PE constructs an IP-based Route Target community by placing the
   next hop of the found inter-AS auto-discovery route in the Global
   Administrator field of this community, with the Local Administrator
   field of this community set to 0, and adds this community to the
   Extended Communities attribute of the C-multicast route.

   Inter-AS auto-discovery routes are not used to support non-segmented
   inter-AS tunnels. To support non-segmented inter-AS tunnels, if the
   local and the remote PEs are in different ASes, the local system
   finds in its VRF an intra-AS I-PMSI auto-discovery route whose
   Originating Router's IP Address field has the same value as the one
   carried in the VRF Route Import of the (unicast) route to the address
   carried in the Multicast Source field. The RD of the found intra-AS
   auto-discovery route is used as the RD of the advertised C-multicast
   route.  The Source AS field in the C-multicast route is set to value
   of the Originating Router's IP Address field of the found intra-AS
   auto-discovery route.

   The Next Hop field of the MP_REACH_NLRI attribute is set to a
   routable IP address of the local PE.

   If the next hop of the found inter-AS auto-discovery route is an EBGP
   neighbor of the local PE, then the PE advertises the C-multicast
   route to that neighbor. If the next hop of the found inter-AS auto-



Raggarwa                                                       [Page 31]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


   discovery route is within the same AS as the local PE, then the PE
   advertises the C-multicast route into IBGP.


10.1.4. Unicast Route Changes

   Whenever unicast route used for determining PE connected to C-S/C-RP
   changes, the local PE updates and re-originates the previously
   originated C-multicast routes, as appropriate.


10.2. Propagating C-multicast routes by an ASBR

   When an ASBR receives a BGP Update message that carries a C-multicast
   route, if at least one of the Route Targets of the route matches one
   of the import Route Targets configured on the ASBR, the ASBR finds an
   inter-AS auto-discovery route whose RD and Source AS matches the RD
   and Source AS carried in the C-multicast route. If no matching route
   is found, the ASBR discards the received C-multicast route.
   Otherwise (if a matching route is found) the ASBR proceeds as
   follows.

   To support non-segmented inter-AS tunnels, instead of matching the RD
   and Source AS carried in the C-multicast route against the RD and
   Source AS of an inter-AS auto-discovery route, the ASBR should match
   it against the RD and the Originating Router's IP Addr of the (non-
   segmented) inter-AS auto-discovery routes.

   The ASBR first checks if it already has one or more C-multicast
   routes that have the same MCAST-VPN NLRI as the newly received route.
   If such route(s) already exists, the ASBR keeps the newly received
   route, but SHALL not re-advertise the newly received route.
   Otherwise, the ASBR re-advertises the route, as described further
   down.

   When an ASBR receives a BGP Update message that carries a withdraw of
   a previously advertised C-multicast route, the ASBR first checks if
   it already has at least one other C-multicast route that has the same
   MCAST-VPN NLRI. If such a route already exists, the ASBR processes
   the withdrawn route, but SHALL not re-advertise the withdrawn route.
   Otherwise, the ASBR re-advertise the withdraw of a previously
   advertised C-multicast route, as described below.

   If the next hop for the found inter-AS auto-discovery route is an
   EBGP neighbor of the ASBR, then the ASBR re-advertises the C-
   multicast route to that neighbor. If the next hop for the found
   inter-AS auto-discovery route is an IBGP neighbor of the ASBR, the
   ASBR re-advertises the C-multicast route into IBGP. If it is the ASBR



Raggarwa                                                       [Page 32]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


   that originated the found inter-AS auto-discovery route in the first
   place, then the ASBR just re-advertises the C-multicast route into
   IBGP.

   If the ASBR is the ASBR that originated the found inter-AS auto-
   discovery route, then before re-advertising the C-multicast route
   into IBGP the ASBR removes from the route the Route Target that
   matches one of the import Route Targets configured on the ASBR.

   If the ASBR is not the ASBR that originating the found inter-AS auto-
   discovery route, then before re-advertising the C-multicast route,
   the ASBR modifies the Extended Communities attribute of the C-
   multicast route as follows. If the Route Target of the route that
   matches one of the import Route Targets configured on the ASBR is an
   IP-based Route Target with the Global Administrator field set to the
   IP address of ASBR, then the ASBR replaces this Route Target with a
   newly constructed IP-based Route Target that has the Global
   Administrator field set to the Next Hop of the found inter-AS auto-
   discovery route, and Local Administrator field of this community set
   to 0. The rest of the Extended Communities attribute of the route
   SHOULD be passed unmodified.

   The Next Hop field of the MP_REACH_NLRI attribute SHOULD be set to an
   IP address of the ASBR.


10.3. Receiving C-multicast routes by a PE

   When a PE receives a C-multicast route the PE checks if any of the
   Route Target communities carried in the Extended Communities
   attribute of the route match any of the import Route Target
   communities associated with the VRFs maintained by the PE. If no
   match is found the PE SHOULD discard the route. Otherwise, (if a
   match is found), the PE checks if the address carried in the
   Multicast Source field of the C-multicast route matches one of the
   (unicast) VPN-IP routes advertised by PE from the VRF. If no match is
   found the PE SHOULD discard the route. Otherwise, (if a match is
   found), the PE proceeds as follows, depending on the multicast
   routing protocol between CE and PE (C-multicast protocol).


10.3.1. Receiving routes with PIM as the C-Multicast protocol

   The following described procedures when PIM is used as the multicast
   routing protocol between CE and PE (C-multicast protocol).






Raggarwa                                                       [Page 33]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


10.3.1.1. Receiving Source Tree Join C-multicast route

   If the received route has the route type set to Source Tree Join,
   then the PE creates a new <C-S, C-G> state in its MVPN-TIB from the
   Multicast Source and Multicast Group fields in the MCAST-VPN NLRI of
   the route, if such a state does not already exist. If there is no S-
   PMSI for <C-S, C-G> then the PE adds an I-PMSI to the outgoing
   interface list of the state if it is not already there. If there is
   an S-PMSI for <C-S, C-G> then the PE add S-PMSI to the outgoing
   interface list of the state if it is not already there.


10.3.1.2. Receiving Shared Tree Join C-multicast route

   If the received route has the route type set to Shared Tree Join,
   then the PE creates a new <C-*, C-G> state in its MVPN-TIB with the
   RP address for that state taken from the Multicast Source, and C-G
   for that state taken from the Multicast Group fields of the MCAST-VPN
   NLRI of the route, if such a state does not already exist. The PE
   adds I-PMSI to the outgoing interface list of the state if it is not
   already there.


10.3.2. Receiving routes with mLDP as the C-Multicast protocol

   The following described procedures when mLDP is used as the multicast
   routing protocol between CE and PE (C-multicast protocol).

   When mLDP is used as a C-multicast protocol, the only valid type of a
   C-multicast route that a PE could receive is a Source Tree Join C-
   multicast route.

   When the PE receives a Source Tree Join C-multicast route, the PE
   applies, in the scope of this VRF, the P2MP LDP procedures for a
   transit node using the value carried in the Multicast Source field of
   the route as the C-Root Node Identifier, and the value carried in the
   Multicast Group of the route as the C-Generic LSP Identifier Value.

   If there is no S-PMSI for <C-Root Node Identifier, C-Generic LSP
   Identifier Value> then the PE creates and advertises an S-PMSI as
   described in Section "Switching to S-PMSI" using C-Root Node
   Identifier as the value for the Multicast Source field of the S-PMSI
   auto-discovery route and C-Generic LSP Identifier Value as the value
   for the Multicast Group field of the route.

   To improve scalability when mLDP is used as the C-Multicast protocol
   for a given MVPN, within each AS that has sites of that MVPN
   connected to the PEs of that AS, all the S-PMSIs of that MVPN MAY be



Raggarwa                                                       [Page 34]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


   aggregated into a single P-Multicast tree (by using upstream assigned
   labels).


10.4. C-multicast routes aggregation

   Note that C-multicast routes are "de facto" aggregated by BGP. This
   is because the MCAST-VPN NLRIs advertised by multiple PEs, for a C-
   multicast route for a particular C-S and C-G (or a particular C-* and
   C-G) of a given MVPN are identical.

   Hence a BGP Route Reflector or ASBR that receives multiple such
   routes with the same NLRI will re-advertise only one of these routes
   to other BGP speakers.

   This implies that C-multicast routes for a given (S,G) of a given
   MVPN originated by PEs that are clients of a given Route Reflector
   are aggregated by the Route Reflector. For instance, if multiple PEs
   that are clients of a Route Reflector, have receivers for a specific
   SSM channel of a MVPN, they will all advertise an identical NLRI for
   the "Source Tree Join" C-multicast route. However only one C-
   multicast route will be advertised by the Route Reflector for this
   specific SSM channel of that MVPN, to other PEs and Route Reflectors
   that are clients of the Route Reflector.

   This also implies that an ASBR aggregates all the received C-
   multicast routes for a given (S,G) (or a given (*,G)) of a given MVPN
   into a single C-multicast route.

   To further reduce the routing churn due to C-multicast routes changes
   a Route Reflector that re-advertises a C-multicast route SHOULD set
   the Next Hop field of the MP_REACH_NLRI attribute of the route to an
   IP address of the Route Reflector. Likewise, an ASBR that re-
   advertises a C-multicast route SHOULD set the Next Hop field of the
   MP_REACH_NLRI attribute of the route to an IP address of the ASBR.

   Further a BGP receiver, that receives multiple such routes with the
   same NLRI for the same C-multicast route, will potentially create
   forwarding state based on a single C-multicast route. As per the
   procedures described in Section "Receiving C-Multicast Routes by a
   PE", this forwarding state will be the same as the state that would
   have been created based an other route with same NLRI.









Raggarwa                                                       [Page 35]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


11. Switching to S-PMSI

   [MVPN] describes a BGP based procedures for switching to S-PMSI.  S-
   PMSI auto-discovery routes are used for this purpose.


11.1. Originating S-PMSI auto-discovery routes

   The following describes procedures for originating S-PMSI auto-
   discovery routes by a PE.

   An S-PMSI auto-discovery route instantiated for a given <C-S, C-G>
   multicast stream is constructed as follows.

   The MCAST-VPN NLRI of the route is constructed as follows.

     + The RD in this NLRI is set to the RD of the VRF associated with
       <C-S, C-G>.

     + The Multicast Source field MUST contain the source address
       associated with the C-multicast stream, and the Multicast Source
       Length field is set appropriately to reflect this.

     + The Multicast Group field MUST contain the group address
       associated with the C-multicast stream, and the Multicast Group
       Length field is set appropriately to reflect this.

     + The Originating Router's IP Address field MUST be set to the IP
       address that the PE places in the Global Administrator field of
       the VRF Route Import extended community of the VPN-IP routes
       advertised by the PE. Note that the <RD, Originating Router's IP
       address> tuple uniquely identifies a given multicast VRF.


   Depending on the type of a P-Multicast tree used to instantiate the
   S-PMSI, the PMSI tunnel attribute of the S-PMSI auto-discovery route
   is constructed as follows:

     + The PMSI tunnel attribute MUST contain the identity of the P-
       Multicast tree that is used to instantiate the tunnel (note that
       the PE could create the identity of the tree prior to the actual
       instantiation of the tunnel). If in order to instantiate the
       tunnel the PE needs to know the leaves of the tree within its own
       AS, then the PE obtains this information from the leaf auto-
       discovery routes received from other PEs/ASBRs within its own AS
       (as other PEs/ASBRs originate leaf auto-discovery routes in
       response to receiving the S-PMSI auto-discovery route) by setting
       the Leaf Information Required flag in the PMSI Tunnel attribute



Raggarwa                                                       [Page 36]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


       to 1.

     + A PE MAY aggregate two or more S-PMSIs originated by the PE onto
       the same P-Multicast tree. If the PE already advertises S-PMSI
       auto-discovery routes for these S-PMSIs, then aggregation
       requires the PE to re-advertise these routes. The re-advertised
       routes MUST be the same as the original ones, except for the PMSI
       tunnel attribute. If the PE has not previously advertised S-PMSI
       auto-discovery routes for these S-PMSIs, then the aggregation
       requires the PE to advertise (new) S-PMSI auto-discovery routes
       for these S-PMSIs.  The PMSI Tunnel attribute in the newly
       advertised/re-advertised routes MUST carry the identity of the P-
       Multicast tree that aggregates the S-PMSIs. If at least some of
       the S-PMSIs aggregated onto the same P-Multicast tree belong to
       different MVPNs, then all these routes MUST carry an MPLS
       upstream assigned label [MPLS-UPSTREAM].  If all these aggregated
       S-PMSIs belong to the same MVPN, then the routes MAY carry an
       MPLS upstream assigned label [MPLS-UPSTREAM].  The labels MUST be
       distinct on a per MVPN basis, and MAY be distinct on a per route
       basis.

   The Next Hop field of the MP_REACH_NLRI attribute of the route SHOULD
   be set to the same IP address as the one carried in the Originating
   Router's IP Address field.

   The route SHOULD carry the same set of Route Targets as the intra-AS
   auto-discovery route of the MVPN originated by the PE.


11.2. Handling S-PMSI auto-discovery routes by ASBRs

   Procedures for handling an S-PMSI auto-discovery route by ASBRs (both
   within and outside of the AS of the PE that originates the route) are
   the same as specified in Section "Propagating Inter-AS Auto-Discovery
   Information", except that instead of inter-AS auto-discovery routes
   the procedures apply to S-PMSI auto-discovery routes.


11.3. Receiving S-PMSI auto-discovery routes by PEs

   Procedures for receiving an S-PMSI auto-discovery route by a PE (both
   within and outside of the AS of the PE that originates the route) are
   the same as specified in Section "Inter-AS auto-discovery route
   received via IBGP" except that (a) instead of inter-AS auto-discovery
   routes the procedures apply to S-PMSI auto-discovery routes, and (b)
   a PE performs procedures specified in that section only if in
   addition to the criteria specified in that section the PE has in its
   MVPN-TIB the state for (C-S, C-G), where C-S is the Multicast Source



Raggarwa                                                       [Page 37]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


   and C-G is the Multicast Group carried in the S-PMSI auto-discovery
   route, and the oif (outgoing interfaces) for this state contains one
   or more interfaces to the locally attached CEs.


12. Carrier's Carrier

   A way to support the Carrier's Carrier model is provided by using
   mLDP as the CE-PE multicast routing and label distribution protocol.
   Use of RSVP-TE and/or BGP as the CE-PE multicast routing and label
   distribution protocol is for further study.

   To improve scalability it is RECOMMENDED that for the Carrier's
   Carrier scenario within an AS all the S-PMSIs of a given MVPN be
   aggregated into a single P-Multicast tree (by using upstream assigned
   labels).


13. Choosing a single forwarder PE when switching from RPT to SPT

   The procedures defined in this section only apply when the C-
   multicast routing protocol is PIM [RFC4601], moreover only apply for
   the multicast ASM mode, and MUST NOT be applied to Multicast Group
   addresses belonging to the SSM range.

   In the scenario where an MVPN customer switches from an C-RP based
   tree (RPT) to the shortest path tree (SPT), in order to avoid packet
   duplication choosing of a single consistent upstream PE, as described
   in [MVPN], may not suffice. To illustrate this consider a set of PEs
   {PE2, PE4, PE6} that are on the C-RP tree for <C-*, C-G> and have
   chosen a consistent upstream PE, as described in [MVPN], for <C-*, C-
   G> state. Further this upstream PE, say PE1, is using an MI-PMSI for
   <C-*, C-G>. If a site attached to one of these PEs, say PE2, switches
   to the C-S tree for <C-S, C-G>, PE2 generates a Source Tree Join C-
   multicast route towards the upstream PE that is on the path to C-S,
   say PE3. PE3 also uses the MI-PMSI for <C-S, C-G>, as PE1 uses for
   <C-*, C-G>. This results in {PE2, PE4, PE6} receiving duplicate
   traffic for <C-S, C-G> - both on the C-RP tree (from PE1) and C-S
   tree (from PE3). If it is desirable to suppress receiving duplicate
   traffic then it is necessary to choose a single forwarder PE for <C-
   S, C-G>. The following describes how this is achieved.










Raggarwa                                                       [Page 38]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


13.1. Source Within a Site - Source Active Advertisement

   Whenever a PE creates an <C-S,C-G> state as a result of receiving a
   Source Tree Join C-multicast route for <C-S, C-G> from some other PE,
   the PE that creates the state MUST originate a Source Active auto-
   discovery route. The route carries a single MCAST-VPN NLRI
   constructed as follows:

     + The RD in this NLRI is set to the RD of the VRF of the MVPN on
       the PE.

     + The Multicast Source field MUST be set to C-S. The Multicast
       Source Length field is set appropriately to reflect this.

     + The Multicast Group field MUST be set to C-G. The Multicast Group
       Length field is set appropriately to reflect this.

   The route SHOULD carry the same set of Route Targets as the intra-AS
   auto-discovery route of the MVPN originated by the PE.

   Using the normal BGP procedures the Source Active auto-discovery
   route is propagated to all the PEs of the MVPN.

   Whenever the PE deletes the <C-S, C-G> state that was previously
   created as a result of receiving a Source Tree Join C-multicast route
   for <C-S, C-G> from some other PE, the PE that deletes the state MUST
   also withdraw the Source Active auto-discovery route, if such a route
   was advertised when the state was created.


13.2. Receiving Source Active auto-discovery route

   When a PE receives a new Source Active auto-discovery route, the PE
   finds a VRF whose import Route Targets match one or more of the Route
   Targets carried by the route. If the match is found, then the PE
   updates the VRF with the received route.

   We say that a given (C-S, C-G) Source Active auto-discovery route
   stored in a given VRF matches a given <C-*, C-G> entry present in the
   MVPN-TIB associated with the VRF if C-G carried by the route is the
   same as C-G of the entry.

   When (as a result of receiving PIM messages from one of its CEs) a PE
   creates in one of its MVPN-TIBs a (new) <C-*, C-G> entry with a non-
   empty outgoing interface list that contains one or more PE-CE
   interfaces, the PE MUST check if it has any matching Source Active
   auto-discovery routes. If there is one or more such matching routes,
   and the best path to C-S carried in the matching route(s) is



Raggarwa                                                       [Page 39]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


   reachable through some other PE, then for each such route the PE MUST
   originate a Source Tree Join C-multicast route.

   When as a result of receiving a new Source Active auto-discovery
   route a PE updates its VRF with the route, the PE MUST check if the
   newly received route matches any <C-*, C-G> entries. If there is a
   matching entry, and the best path to C-S carried in the (auto-
   discovery) route is reachable through some other PE, the PE MUST
   originate a Source Tree Join C-multicast route for the (C-S, C-G)
   carried by the route.

   Construction and distribution of the Source Tree Join C-multicast
   route follows the procedures specified in Section "Originating Source
   Tree Join C-multicast route", except that the Multicast Source
   Length, Multicast Source, Multicast Group Length, and Multicast Group
   fields in the MCAST-VPN NLRI of the Source Tree Join C-multicast
   route are copied from the corresponding field in the Source Active
   auto-discovery route.

   A PE MUST withdraw a Source Tree Join C-multicast route for (C-S, C-
   G) if, as a result of having received PIM messages from one of its
   CEs, the PE creates a Prune <C-S, C-G, RPT-bit> upstream state in one
   of its MVPN-TIBs, but has no <C-S, C-G> Joined state in that MVPN-
   TIB, and had previously advertised the said route.  (This is even if
   the VRF associated with the MVPN-TIB still has a (C-S, C-G) Source
   Active auto-discovery route).

   A PE MUST withdraw a Source Tree Join C-multicast route for (C-S, C-
   G) if the Source Active auto-discovery route that triggered the
   advertisement of the C-multicast route is withdrawn.


13.2.1. Pruning Sources off the Shared Tree

   If the incoming interface list (iif) for the found <C-*, C-G> entry
   in the MVPN-TIB on the PE contains one of the PE-CE interfaces
   (interfaces from the PE to its directly connected CEs), then the PE
   MUST create in the MVPN-TIB a <C-S, C-G, RPT-bit> entry, if it does
   not already exist. C-S of this entry is set to the address carried in
   the Multicast Source field of the received Source Active auto-
   discovery route, and C-G of this entry is set to the address carried
   in the Multicast Group field of the route. Creating this entry
   results in pruning <C-S, C-G> traffic off the shared (RPT) tree.

   The PE maintains the <C-S, C-G, RPT-bit> entry for as long as it has
   at least one Source Active auto-discovery route for <C-S, C-G>.





Raggarwa                                                       [Page 40]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


14. Supporting PIM-SM without inter-site Shared Trees

   The procedures defined in this section only apply when the C-
   multicast routing protocol is PIM [RFC4601], moreover only apply for
   the multicast ASM mode, and MUST NOT be applied to Multicast Group
   addresses belonging to the SSM range.


14.1. Multicast Source Within a Site - Source Active Advertisement

   A PE can obtain information about active multicast sources within a
   given MVPN in a variety of ways. One way is for the PE to act as a
   fully functional customer RP (C-RP) for that MVPN. Another way is to
   use PIM Anycast RP procedures [PIM-ANYCAST-RP] to convey information
   about active multicast sources from one or more of the MVPN C-RPs to
   the PE. Yet another way is to use MSDP [MSDP] to convey information
   about active multicast sources from the MVPN C-RPs to the PE.

   When a PE using any of the above methods first learns of a new
   (multicast) source within that MVPN, the PE constructs a Source
   Active auto-discovery route, and sends this route to all other PEs
   that have one or more sites of that MVPN connected to them. The route
   carries a single MCAST-VPN NLRI constructed as follows:

     + The RD in this NLRI is set to the RD of the VRF of the MVPN on
       the PE.

     + The Multicast Source field MUST be set to the source IP address
       of the multicast data packet carried in the PIM-Register message.
       The Multicast Source Length field is set appropriately to reflect
       this.

     + The Multicast Group field MUST be set to the group address of the
       multicast data packet carried in the PIM-Register message. The
       Multicast Group Length field is set appropriately to reflect
       this.

   The route SHOULD carry the same set of Route Targets as the intra-AS
   auto-discovery route of the MVPN originated by the PE.

   Using the normal BGP procedures the Source Active auto-discovery
   route is propagated to all the PEs of the MVPN.

   When a PE that previously advertised a Source Active auto-discovery
   route for a given (multicast) source learns that the source is no
   longer active (the PE learns this by using the same mechanism by
   which the PE learned that the source was active), the PE SHOULD
   withdraw the previously advertised Source Active route.



Raggarwa                                                       [Page 41]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


14.2. Receiver(s) Within a Site

   A PE follows the procedures specified in Section "Originating C-
   multicast routes by a PE", except that the procedures specified in
   Section "Originating Shared Tree Join C-multicast route" are replaced
   with the procedures specified in this Section below.

   When a PE receives a new Source Active auto-discovery route, the PE
   finds a VRF whose import Route Targets match one or more of the Route
   Targets carried by the route. If the match is found, then the PE
   updates the VRF with the received route.

   We say that a given (C-S, C-G) Source Active auto-discovery route
   stored in a given VRF matches a given <C-*, C-G> entry present in the
   MVPN-TIB associated with the VRF if C-G carried by the route is the
   same as C-G of the entry.

   When (as a result of receiving PIM messages from one of its CEs) a PE
   creates in one of its MVPN-TIBs a (new) <C-*, C-G> entry with a non-
   empty outgoing interface list that contains one or more PE-CE
   interfaces, the PE MUST check if it has any matching Source Active
   auto-discovery routes. If there is one or more such matching routes,
   and the best path to C-S carried in the matching route(s) is
   reachable through some other PE, then for each such route the PE MUST
   originate a Source Tree Join C-multicast route. If there is one or
   more such matching routes, and the best path to C-S carried in the
   matching route(s) is reachable through a CE connected to the PE, then
   for each such route the PE MUST originate a PIM Join (C-S, C-G)
   towards the CE.

   When as a result of receiving a new Source Active auto-discovery
   route a PE updates its VRF with the route, the PE MUST check if the
   newly received route matches any <C-*, C-G> entries. If there is a
   matching entry, and the best path to C-S carried in the (auto-
   discovery) route is reachable through some other PE, the PE MUST
   originate a Source Tree Join C-multicast route for the (C-S, C-G)
   carried by the route. If there is a matching entry, and the best path
   to C-S carried in the (auto-discovery) route is reachable through a
   CE connected to the PE, the PE MUST originate a PIM Join (C-S, C-G)
   towards the CE.

   Construction and distribution of the Source Tree Join C-multicast
   route follows the procedures specified in Section "Originating Source
   Tree Join C-multicast route", except that the Multicast Source
   Length, Multicast Source, Multicast Group Length, and Multicast Group
   fields in the MCAST-VPN NLRI of the Source Tree Join C-multicast
   route are copied from the corresponding field in the Source Active
   auto-discovery route.



Raggarwa                                                       [Page 42]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


   A PE MUST withdraw a Source Tree Join C-multicast route for (C-S, C-
   G) if, as a result of having received PIM messages from one of its
   CEs, the PE creates a Prune <C-S, C-G, RPT-bit> upstream state in one
   of its MVPN-TIBs, but has no <C-S, C-G> Joined state in that MVPN-
   TIB, and had previously advertised the said route.  (This is even if
   the VRF associated with the MVPN-TIB still has a (C-S, C-G) Source
   Active auto-discovery route).

   A PE MUST withdraw a Source Tree Join C-multicast route for (C-S, C-
   G) if the Source Active auto-discovery route that triggered the
   advertisement of the C-multicast route is withdrawn.

   Even though PIM is used as a C-multicast protocol, procedures
   described in Section "Originating Shared Tree Join C-multicast route"
   do not apply here, as only the Source Tree Join C-multicast routes
   are exchanged among PEs.


14.3. Receiving C-multicast routes by a PE

   In this model the only valid type of a C-multicast route that a PE
   could receive is a Source Tree Join C-multicast route. Processing of
   such a route follows the procedures specified in Section "Receiving
   Source Tree Join C-multicast route".


15. Scalability Considerations

   A PE should use Route Target Constrain [RT-CONSTRAIN] to advertise
   the Route Targets that the PE uses for the VRF Route Imports extended
   community (note that doing this requires just a single Route Target
   Constraint advertisement by the PE). This allows each C-multicast
   route to reach only the relevant PE, rather than all the PEs
   participating the an MVPN.

   To keep the intra-AS membership/binding information within the AS of
   the advertising router the BGP Update message originated by the
   advertising router SHOULD carry the NO_EXPORT Community ([RFC1997]).

   An inter-AS auto-discovery route originated by an ASBR aggregates
   auto-discovery routes originated within the ASBR's own AS. Thus while
   the auto-discovery routes originated within an AS are at the
   granularity of <PE, MVPN> within that AS, outside of that AS the
   (aggregated) inter-AS auto-discovery routes are at the granularity of
   <AS, MVPN>. An inter-AS auto-discovery route for a given <AS, MVPN>
   indicates the presence of or or more sites of the MVPN connected to
   the PEs of the AS.




Raggarwa                                                       [Page 43]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


   For a given inter-AS tunnel each of its intra-AS segments could be
   constructed by its own mechanism. Moreover, by using upstream
   assigned labels within a given AS multiple intra-AS segments of
   different inter-AS tunnels of either the same or different MVPNs may
   share the same P-Multicast tree.

   Since (aggregated) inter-AS auto-discovery routes have granularity of
   <AS, MVPN>, an MVPN that is present in N ASes would have total of N
   inter-AS tunnels. Thus for a given MVPN the number of inter-AS
   tunnels is independent of the number of PEs that have this MVPN.

   Within each Autonomous System BGP Route reflectors can be partitioned
   among MVPNs present in that Autonomous System so that each partition
   carries routes for only a subset of the MVPNs supported by the
   Service Provider. Thus no single Route Reflector is required to
   maintain routes for all MVPNs. Moreover, Route Reflectors used for
   MVPN do not have to be used for VPN-IP routes (although they may be
   used for VPN-IP routes as well).

   As described in Section "C-multicast routes aggregation", C-multicast
   routes for a given (S,G) of a given MVPN originated by PEs that are
   clients of a given Route Reflector are aggregated by the Route
   Reflector. Therefore, even if within a Route Reflector cluster there
   are multiple C-multicast routes for a given (S,G) of a given MVPN,
   outside of the cluster all these routes are aggregated into a single
   C-multicast route. Additional aggregation of C-multicast routes
   occurs at ASBRs, where an ASBR aggregates all the received C-
   multicast routes for a given (S,G) of a given MVPN into a single C-
   multicast route. Moreover, both Route Reflectors and ASBRs maintain
   C-multicast routes only in the control plane, but not in the data
   plane.


16. Dampening C-multicast routes

   The rate of C-multicast routing changes advertised by a PE is not
   directly proportional to the rate of multicast routing changes within
   the MVPN sites connected to the PE, as after the first <C-S,C-G> Join
   originated within a site, all the subsequent Joins for same <C-S,C-G>
   originated within the sites of the same MVPN connected to the PE do
   not cause origination of new C-multicast routes by the PE.

   Depending on how multicast VPN is engineered, dynamic addition and
   removal of P2MP RSVP-TE leaves through advertisement/withdrawal of
   leaf auto-discovery routes, will happen. Dampening techniques can be
   used to limit corresponding processing.

   To lessen the control plane overhead associated with processing of C-



Raggarwa                                                       [Page 44]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


   multicast routes, this document proposes OPTIONAL route dampening
   procedures similar to what is described in RFC2439. The following
   OPTIONAL procedures can be enabled on a PE, ASBR, or BGP Route
   Reflector advertising or receiving C-multicast routes.


16.1. Dampening withdrawals of C-multicast routes

   A PE/ASBR/Route Reflector can OPTIONALLY delay the advertisement of
   withdrawals of C-multicast routes.  An implementation SHOULD provide
   the ability to control the delay via a configurable timer, possibly
   with some backoff algorithm to adapt the delay to multicast routing
   activity.

   Dampening of withdrawals of C-multicast routes does not impede the
   multicast join latency observed by MVPN customers, and also does not
   impede the multicast leave latency observed by a CE, as multicast
   forwarding from the VRF will stop as soon as C-multicast state is
   removed in the VRF.

   The only potential drawback of dampening of withdrawals of C-
   multicast routes is that the PE that performs the dampening may
   receive useless (multicast) traffic for some period of time. Note
   that the PE may receive useless (multicast) traffic anyway,
   irrespective of dampening of withdrawals of C-multicast routes due to
   the use of I-PMSIs.


16.2. Dampening Source/Shared Tree Join C-multicast routes

   A PE/ASBR/Route Reflector can OPTIONALLY delay the advertisement of
   Source/Shared Tree Join C-multicast routes.  An implementation SHOULD
   provide the ability to control the delay via a configurable timer,
   possibly with some backoff algorithm to adapt the delay to multicast
   routing activity.

   Dampening Source/Shared Tree Join C-multicast routes will not impede
   multicast join latency observed by a given MVPN, except if the PE
   advertising the Source/Shared Tree Join C-multicast route is the
   first for all the sites of the MVPN to do so.











Raggarwa                                                       [Page 45]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


17. Dampening withdrawals of leaf auto-discovery routes

   Similarly to the procedures proposed above for withdrawal of C-
   multicast routes, dampening can be applied aggressively to the
   withdrawal of leaf auto-discovery routes.


18. IANA Consideration

   This document defines a new BGP Extended Community called Source AS.
   This community is 2-octet AS specific, of an extended type, and is
   transitive.

   This document defines a new BGP Extended Community called VRF Route
   Import. This community is IP address specific, of an extended type,
   and is transitive.

   This document defines a new NLRI, called MCAST-VPN, to be carried in
   BGP using multiprotocol extensions. It requires assignment of a new
   SAFI.

   This document defines a new BGP optional transitive attribute, called
   PMSI Tunnel.


19. Security Considerations

   The mechanisms described in this document could re-use the existing
   BGP security mechanisms.


20. Acknowledgement

   Some of the text in Section "Supporting PIM-SM without inter-site
   Shared Trees" has been taken almost verbatim from RFC3618.


21. References

21.1. Normative References

   [IANA-SAFI] http://www.iana.org/assignments/safi-namespace

   [MVPN] E. Rosen, R. Aggarwal [Editors], "Multicast in MPLS/BGP IP
   VPNs", draft-ietf-l3vpn-2547bis-mcast

   [RFC1997] R. Chandra, P. Traina, T. Li, "BGP Communities Attribute",
   RFC1997, August 1996.



Raggarwa                                                       [Page 46]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


   [RFC2119] "Key words for use in RFCs to Indicate Requirement
   Levels.", Bradner, RFC2119, March 1997.

   [RFC4271] Rekhter, Y., Li, T., Hares, S., "A Border Gateway Protocol
   4 (BGP-4)", RFC 4271, January 2006

   [RFC4760] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
   "Multiprotocol Extensions for BGP-4", RFC 2858, January 2007.

   [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
   Communities Attribute", RFC 4360, February 2006.

   [RFC4364] E. Rosen, Y. Rekhter, "BGP/MPLS IP Virtual Private Networks
   (VPNs)", RFC4364, February 2006

   [RFC4601] B. Fenner et. al., "Protocol Independent Multicast - Sparse
   Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August
   2006


21.2. Informative References

   [MPLS-UPSTREAM] R. Aggrwal, Y. Rekhter, E. Rosen, " MPLS Upstream
   Label Assignment and Context Specific Label Space", draft-ietf-mpls-
   upstream-label

   [RT-CONSTRAIN] P. Marques et. al., "Constrained Route Distribution
   for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS)
   Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684,
   November 2006

   [mLDP] I. Minei et. al., "Label Distribution Protocol Extensions for
   Point-to-Multipoint and Multipoint-to-Multipoint Label Switched
   Paths", draft-ietf-mpls-ldp-p2mp

   [RFC4607] H. Holbrook, B. Cain "Source-Specific Multicast for IP",
   RFC 4607, August 2006

   [RSVP-TE-P2MP] R. Aggarwal et. al., "Extensions to RSVP-TE for Point-
   to-Multipoint TE LSPs", draft-ietf-mpls-rsvp-te-p2mp

   [PIM-ANYCAST-RP] D. Farinacci, Y. Cai, "Anycast-RP using PIM" RFC
   4610, August 2006

   [MSDP] B. Fenner, D. Meyer, "Multicast Source Discovery Protocol
   (MSDP)", RFC3618, October 2003





Raggarwa                                                       [Page 47]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


22. Author Information

   Rahul Aggarwal
   Juniper Networks
   1194 North Mathilda Ave.
   Sunnyvale, CA 94089
   Email: rahul@juniper.net

   Eric C. Rosen
   Cisco Systems, Inc.
   1414 Massachusetts Avenue
   Boxborough, MA, 01719
   E-mail: erosen@cisco.com

   Thomas Morin
   France Telecom R & D
   2, avenue Pierre-Marzin
   22307 Lannion Cedex
   France
   Email: thomas.morin@francetelecom.com

   Yakov Rekhter
   Juniper Networks
   1194 North Mathilda Ave.
   Sunnyvale, CA 94089
   Email: yakov@juniper.net

   Chaitanya Kodeboniya



23. Intellectual Property Statement

   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.



Raggarwa                                                       [Page 48]

Internet Draft  draft-ietf-l3vpn-2547bis-mcast-bgp-03.txt      July 2007


   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.


24. Copyright Notice

   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.





























Raggarwa                                                       [Page 49]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/