Network Working Group R. Aggarwal Internet Draft Juniper Networks Expiration Date: March 2006 C. Kodeboniya Juniper Networks Y. Rekhter Juniper Networks E. Rosen Cisco Systems, Inc. T. Morin France Telecom September 2005 BGP Encodings for Multicast in MPLS/BGP IP VPNs draft-raggarwa-l3vpn-2547bis-mcast-bgp-00.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, et al. [Page 1] Internet Draftdraft-raggarwa-l3vpn-2547bis-mcast-bgp-00.txteptember 2005 Abstract This document describes the BGP encodings for signaling the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in [MVPN]. Table of Contents 1 Specification of requirements ......................... 3 2 Terminology ........................................... 3 3 Introduction .......................................... 3 4 MCAST-VPN NLRI ........................................ 3 5 Tunnel Type Identifiers ............................... 5 6 Source AS Extended Community .......................... 6 7 Route Import Extended Community ....................... 6 8 MVPN Auto-Discovery/Binding ........................... 7 8.1 MVPN Auto-Discovery/Binding - Intra AS Operations ..... 7 8.2 MVPN Auto-Discovery/Binding - Inter AS Operations ..... 8 8.2.1 Originating Inter AS MVPN Auto-Discovery Information .. 8 8.2.2 Propagating Inter AS MVPN Auto-Discovery Information .. 9 8.2.2.1 Auto-Discovery Route received via EBGP ................ 9 8.2.2.2 Auto-Discovery Route received via IBGP ................ 10 9 VPN C-Multicast Routing Information Exchange among PEs ....10 9.1 Originating C-Multicast Routes by a PE ................ 10 9.2 Propagating C-Multicast routes by an ASBR ............. 12 10 Switching to S-PMSI ................................... 13 11 Electing a single forwarder PE ........................ 13 12 Co-locating C-RPs on a PE ............................. 14 13 IANA Consideration .................................... 14 14 References ............................................ 14 14.1 Normative References .................................. 14 14.2 Informative References ................................ 15 15 Author Information .................................... 15 16 Intellectual Property Statement ....................... 16 17 Full Copyright Statement .............................. 16 Raggarwa, et al. [Page 2] Internet Draftdraft-raggarwa-l3vpn-2547bis-mcast-bgp-00.txteptember 2005 1. Specification of requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Terminology In the context of this document we will refer to the MVPN auto-dis- covery/binding information carried in BGP as "auto-discovery routes". In the context of this document we will refer to the MVPN customers multicast routing information carried in BGP as "C-multicast routes". 3. Introduction This document describes the BGP encodings for signaling the informa- tion elements required by Multicast in MPLS/BGP IP VPNs, as specified in [MVPN]. This document assumes a thorough familiarity with [MVPN]. This document specifies a new NLRI, MCAST-VPN NLRI. The MCAST-VPN NLRI is used for MVPN auto-discovery, advertising MVPN - Inclusive tunnel binding, VPN customer multicast routing information exchange among PEs, S-PMSI signaling, electing a single forwarder PE and for anycast RP procedures required to home a C-RP on a PE. This document also specifies new Tunnel Identifier types to be car- ried in the Tunnel attribute [TUNNEL-ENCAP]. 4. MCAST-VPN NLRI A new BGP NLRI, called the MCAST-VPN NLRI, is proposed. This NLRI is carried in BGP using BGP Multiprotocol Extensions [RFC2858bis]. Fol- lowing is the format of the MCAST-VPN NLRI: +---------------------------------+ | Length (1 octet) | +---------------------------------+ | RD (8 octets) | +---------------------------------+ | Originating Router's IP Addr | +---------------------------------+ |Multicast Source Length (1 octet)| +---------------------------------+ | Multicast Source (Variable) | Raggarwa, et al. [Page 3] Internet Draftdraft-raggarwa-l3vpn-2547bis-mcast-bgp-00.txteptember 2005 +---------------------------------+ |Multicast Group Length (1 octet) | +---------------------------------+ |Multicast Group (Variable) | +---------------------------------+ | MPLS Labels (variable) | |---------------------------------+ The Length field indicates the length in bytes of the RD, Originating Router's IP Address, Multicast Source Length, Multicast Source, Mul- ticast Group Length, Multicast Group, and MPLS Label fields. The RD is encoded as described in [BGP-VPN]. The value of the Multicast Source Length field is the length in bits of the Multicast Source Address field minus 2. Following is the encoding of the Multicast Source field: +---------------------------------+ |W|R| Source Address (variable) | +---------------------------------+ W The WC (or WildCard) bit is a 1 bit value for use with C-MVPN routing updates (see section 8) [PIM-SM] R The RPT (or Rendezvous Point Tree) bit is a 1 bit value for use with C-MVPN routing updates (see Section 8) [PIM-SM] Since the same MCAST-VPN NLRI is used to carry both auto-discovery routes and C-multicast routes, the WC and RPT bits are also used to distinguish between these two types of routes. Specifically, all the auto-discovery routes MUST have the WC bit set to 1, and the RPT bit set to 0. The Source Address field encodes the C-S address as an IP prefix, followed by enough trailing bits to make the end of the field fall on an octet boundary. The value of the Multicast Group Length field is the length in bits of the Multicast Group field. The Multicast Group field encodes the C-G address as an IP prefix, followed by enough trailing bits to make the end of the trail fall on Raggarwa, et al. [Page 4] Internet Draftdraft-raggarwa-l3vpn-2547bis-mcast-bgp-00.txteptember 2005 an octet boundary. The Label field, if present, carries one or more labels (that corre- sponds to the stack of labels [MPLS-ENCAPS]). Each label is encoded as 3 octets, where the high-order 20 bits contain the label value, and the low order bit contains "Bottom of Stack" (as defined in [MPLS-ENCAPS]). The Next Hop field of the MP_REACH_NLRI attribute is set to a routable IP address of the originator of the BGP Update message that carries this MP_REACH_NLRI. 5. Tunnel Type Identifiers As specified in [TUNNEL-ENCAP], the Tunnel Type Identifier carried in the Tunnel attribute has the following format: +---------------------------------+ | Tunnel Type (2 octets) | +---------------------------------+ | Tunnel Identifier (variable) | +---------------------------------+ The Tunnel Type identifies the type of the tunneling technology used to establish the tunnel. The type determines the syntax and semantics of the tunnel identifier fiels. This document defines the following Tunnel Types: 1. RSVP-TE P2MP LSP 2. LDP P2MP LSP 3. PIM-SSM Tree 4. PIM-SM Tree 5. Ingress Replication When the type is set to RSVP-TE P2MP LSP, the tunnel identifier con- tains the RSVP-TE P2MP LSP's SESSION Object and optionally the RSVP- TE P2MP LSP's SENDER_TEMPLATE Object. When the type is set to LDP P2MP LSP, the tunnel identifier is . When the type is set to PIM-SM Tree, the tunnel identifier is . When the type is set to PIM-SSM Tree, the tunnel identifier is . Raggarwa, et al. [Page 5] Internet Draftdraft-raggarwa-l3vpn-2547bis-mcast-bgp-00.txteptember 2005 When the type is set to Ingress Replication the tunnel identifier carries the unicast tunnel endpoint. 6. Source AS Extended Community This document defines a new extended community called Source AS. The Source AS is an AS specific extended community. The Source AS extended community is of an extended type, and is tran- sitive across AS boundaries. To support MVPN a PE that originates a (unicast) route to VPN-IPv4 addresses MUST include in the BGP Update message that carries this route 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 SHOULD be set to 0. 7. Route Import Extended Community This document defines a new extended community called Route Import. The Route Import is an IPv4 address specific extended community. The Route Import is of an extended type, and is transitive across AS boundaries. To support MVPN in addition to the import/export Route Target(s) used by the unicast routing, each VRF MUST have an import Route Target that is unique to this VRF. This Route Target MUST be IP address spe- cific. The Global Administrator field of this Route Target MUST be set to the IP address used for the Next Hop in (unicast) VPN-IPv4 address advertisements for that VRF. A PE that originates a route to VPN-IPv4 addresses MUST include in the BGP Updates message that car- ries this route the Route Import extended community that has the value of this Route Target. If a PE uses Route Target Constrain [RT-CONSTRAIN], the PE SHOULD advertise all such import Route Targes using Route Target Constrains (note that doing this requires just a single Route Target Constraint advertisement by the PE). Raggarwa, et al. [Page 6] Internet Draftdraft-raggarwa-l3vpn-2547bis-mcast-bgp-00.txteptember 2005 8. MVPN Auto-Discovery/Binding 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 ASs. 8.1. MVPN Auto-Discovery/Binding - Intra AS Operations To participate in the MVPN auto-discovery/binding a PE router that has a given VRF of a given MVPN originates an auto-discovery route and advertises this route in IBGP. The BGP Update message that car- ries this route is constructed as follows. The message carries a sin- gle MCAST-VPN NLRI (the format of this NLRI is described in section 3). The RD in this NLRI is set to the RD of the VRF. The Multicast Source Length field and the Multicast Group Length field MUST both be set to 0. The Originating Router's IP Address is set to the IP address of the router that generates the advertisement. This address doesn't have to be a routable IP address. The tuple results in an address that uniquely identifies a given multi- cast VRF. If the advertising router uses ingress replication to instantiate the provider tunnel for the MVPN, the NLRI MUST carry a downstream assigned MPLS label that is used to demultiplex the MVPN traffic received over a unicast tunnel, by the advertising router. Further the BGP Update message MUST carry a Tunnel Identifier in the Tunnel attribute with type set to Ingress Replication. This identifier MUST carry a routable address of the advertising router. If a P-Multicast Tree is used to instantiate the provider tunnel for the MVPN, and either (a) this tree exists at the time of discovery, or (b) the PE doesn't need to know the leaves of the tree beforehand in order to advertise the P-Multicast tree identifier, then the advertising PE SHOULD advertise the P-Multicast tree identifier in the Tunnel Identifier of the Tunnel attribute. If a P-Multicast Tree is used to instantiate the provider tunnel for the MVPN, and the advertising PE needs to know the leaves of the tree beforehand in order to advertise the P-Multicast tree identifier, the PE first discovers the leaves using the Auto-Discovery procedures. It then advertises the binding of the tree to the MVPN using the same message as the one used for the auto-discovery with the addition of carrying in the message the Tunnel attribute that contains the type and the identity of the tree (encoded in the Tunnel Identifier of the Raggarwa, et al. [Page 7] Internet Draftdraft-raggarwa-l3vpn-2547bis-mcast-bgp-00.txteptember 2005 attribute). If at some later point a new PE advertises participation in the same MVPN, the initial binding SHOULD NOT change. When multiple MVPNs are aggregated onto the same P-multicast tree advertised in the Tunnel attribute, the NLRI MUST carry a MPLS upstream assigned label [MPLS-UPSTREAM] that is associated with the MVPN. The BGP Update message MUST carry the export Route Target used by the unicast routing. If any other PE has one of these Route Targets con- figured for a VRF, it treats the advertising PE as a member in the MVPN to which the VRF belongs. 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]). 8.2. MVPN Auto-Discovery/Binding - Inter AS Operations An Autonomous System Border Router (ASBR) may be configured to sup- port a particular MVPN. 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 AS that the ASBR belongs to, as defined in this document. Moreover, in addition to the above the ASBR performs the following procedures. 8.2.1. Originating Inter AS MVPN Auto-Discovery Information For a given MVPN and a given AS all the ASBRs within that AS that are configured to support the MVPN MUST be configured with the same RD. This RD MUST be of Type 0, MUST embed the autonomous system number of the AS, and MUST be unique to that MVPN. When an ASBR determines (using the intra AS auto-discovery proce- dures) that at least one of the PEs of its own AS has members of an MVPN configured on the ASBR, the ASBR originates an auto-discovery route and advertises it in EBGP. The BGP Update message that carries this route is constructed as follows. The message carries a single MCAST-VPN NLRI (the format of this NLRI is described in section 3) constructed as follows. The RD MUST be set to the RD configured for that MVPN on the ASBR. The Originating Raggarwa, et al. [Page 8] Internet Draftdraft-raggarwa-l3vpn-2547bis-mcast-bgp-00.txteptember 2005 Router's IP Address field MUST be set to 0. The Multicast Source Length field and the Multicast Group Length field MUST both be set to 0. The MCAST-VPN NLRI carries no MPLS Labels. The BGP Update message MUST carry the export Route Target used by the unicast routing of that VPN. 8.2.2. Propagating Inter AS MVPN Auto-Discovery Information 8.2.2.1. Auto-Discovery Route received via EBGP When an ASBR receives from one of its EBGP neighbors a BGP Update message that carries an 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 propagates this auto-discovery route within its own AS using the intra-AS MVPN auto-discovery/bind- ing procedures with the following modifications: 1. The the MCAST-VPN NLRI of the advertised route is set to the MCAST-VPN NLRI carried in the received route; 2. The Extended Community attribute of the advertised route is set to the Extended Community attribute of the received route; 3. Even if the ASBR supports ingress replication, the BGP Update message that the ASBR originates for the distribution within its own AS MUST NOT carry a Tunnel Identifier in the Tunnel attribute with type set to Ingress Replication. In addition the ASBR MUST sent to the neighbor a BGP Update message constructed as follows. The message carries a single MCAST-VPN NLRI (the format of this NLRI is described in section 3). The RD in this NLRI is set to the RD car- ried in the route received from that neighbor. The Multicast Source Length field and the Multicast Group Length field MUST both be set to 0. The BGP Update MUST carry the same set of Route Targe communities as was carried by the route. The NLRI MUST carry a downstream assigned MPLS label that is used to demultiplex the MVPN traffic received over a unicast tunnel by the advertising router. Further the BGP Update MUST carry a Tunnel Identifier in the Tunnel attribute with type set to Ingress Replication. This identifier MUST carry a routable address of the advertising router. The message SHOULD carry Raggarwa, et al. [Page 9] Internet Draftdraft-raggarwa-l3vpn-2547bis-mcast-bgp-00.txteptember 2005 the NO_ADVERTISE BGP community ([RFC1997]). 8.2.2.2. Auto-Discovery Route received via IBGP When an ASBR receives from one of its IBGP neighbors a BGP Update message that carries an auto-discovery route, if (a) the route was originated outside of the ASBR's own AS, (b) at least one of the Route Targets carried in the message matches one of the import Route Targets configured on the ASBR, and (c) the ASBR determines that the received route is the best route to the destination carried in the NLRI of the route, then the ASBR propagates the route to its EBGP neighbors. 9. VPN C-Multicast Routing Information Exchange among PEs In order to support exchange of C-multicast routes across ASs, each ASBR within these ASs MUST be configured with an import RT that is IP address specific. The Global Administrator field of this community MUST be set to the IP address carried in the Next Hop of the 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 community MUST be set to 0. If the ASBR uses Route Target Constrain [RT-CONSTRAIN], the ASBR SHOULD advertise this import Route Target using Route Target Constrains. VPN C-Multicast Routing Information is exchanged among PEs by using C-multicast routes that carry MCAST-VPN NLRI. These routes are origi- nated and propagated as follows. 9.1. Originating C-Multicast Routes by a PE When a PE generates a update towards the source, the source address in the MCAST-VPN NLRI is set to C-S and the group address is set to C-G. The WC and RPT bits MUST be clear. The MCAST- VPN NLRI for Join towards the source is carried in the MP_REACH_NLRI attribute, and for Prune towards the source in the MP_UNREACH_NLRI attribute. When a PE generates a update towards the C-RP, the source address in the MCAST-VPN NLRI is set to C-S and the group address is set to C-G. The WC bit MUST be clear and the RPT bit MUST be set. The MCAST-VPN NLRI for Join towards the C-RP is carried in the MP_UNREACH_NLRI attribute, and for Prune towards the C-RP Raggarwa, et al. [Page 10] Internet Draftdraft-raggarwa-l3vpn-2547bis-mcast-bgp-00.txteptember 2005 in the MP_REACH_NLRI attribute. When a PE generates a update towards the C-RP, the source address in the MCAST-VPN NLRI MUST be set to the C-RP address. The group address in the NLRI MUST be set to C-G. Both the WC and RPT bits MUST be set. The MCAST-VPN NLRI for Join is carried in the MP_REACH_NLRI attribute, and for Prune in the MP_UNREACH_NLRI attribute. When a PE generates a update towards the C-RP, the source address in the MCAST-ROUTING NLRI MUST be set to the C-RP address. The group address in the NLRI MUST be set to a wildcard i.e. 0. Both the WC and RPT bits MUST be set. The MCAST-VPN NLRI for Join is carried in the MP_REACH_NLRI attribute, and for Prune in the MP_UNREACH_NLRI attribute. The rest of the C-multicast route and the BGP Update that carries the route is constructed as follows. The (local) PE uses its VRF to determine (a) the autonomous system number of the (remote) PE that originates the (unicast) route to C- S/C-RP, and (b) the import Route Target community associated with the VRF on the remote PE which was used to originate the route (this information is available from the Route Import extended community carried in the unicast VPN-IPv4 routing advertisements by the remote PE). Irrespective of whether the local and the remote PE are in the same or different ASs, the Extended Community attribute of the route MUST include the import Route Target community associated with the VRF on the remote PE. Irrespective of whether the local and the remote PE are in the same or different ASs, the Originating Router's IP Address is set to the IP address of the router that generates the advertisement. This address doesn't have to be a routable IP address. The tuple results in an address that uniquely identifies a given multicast VRF. Irrespective of whether the local and the remote PE are in the same or different ASs, the MCAST-VPN NLRI carries no MPLS Labels. 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-IPv4 route that contains C-S/C-RP. The route is then advertised into IBGP. If the local and the remote PEs are in different ASs, then the local PE finds in its VRF an auto-discovery route whose RD embeds the Raggarwa, et al. [Page 11] Internet Draftdraft-raggarwa-l3vpn-2547bis-mcast-bgp-00.txteptember 2005 autonomous system number of the remote PE. The RD of this route is used as the RD of the advertised MCAST-VPN NLRI. The local PE con- structs an IP-based Route Target community by placing the next hop of this route in the Global Administrator field of an community, with the Local Administrator field of this community set to 0, and adds this community to the Extended Community attribute of the route. If the next hop of the auto-discovery route is an EBGP neighbor of the local PE, then the PE advertises this route to that neighbor. If the next hop of the route is within the same AS as the local PE, then the PE advertises the route into IBGP. 9.2. Propagating C-Multicast routes by an ASBR When an ASBR receives a BGP Update message that carries a C-Multicast route 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, except for the value of the Originating Router's IP Address field. If such route(s) already exists, the ASBR keeps the newly received route, but SHALL not re-advertise the newly received route. Other- wise, 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 C-multicast route that has the same MCAST-VPN NLRI, except for the value of the Originating Router's IP Address field. If such a route already exists, the ASBR processes the withdrawn route, but SHALL not re-advertise the withdrawn route. Oth- erwise, the ASBR re-advertise the withdraw of a previously advertised C-multicast route, as described below. When an ASBR receives a BGP Update message that carries a C-Multicast route, if the at least one of the Route Targets carried in the mes- sage matches one of the import Route Targets configured on the ASBR, the ASBR finds an auto-discovery route whose RD matches the RD car- ried in the C-Multicast route. Before re-advertising this route, the ASBR modifies the Extended Com- munity attribute of the route as follows. If the matching Route Tar- get is an IP-based Route Target with the Global Administrator field set to the IP address of ASBR, then the ASBR remotes this Route Tar- get from the Extended Community attribute. In addition, the ASBR con- structs a new IP-based Route Target with the Global Administrator field set to the Next Hop of the matching auto-discovery route, Local Administrator field of this community set to 0, and add this Route Target to the Extended Community attribute of the route. The rest of the Extended Community attribute of the route is passed unmodified. Raggarwa, et al. [Page 12] Internet Draftdraft-raggarwa-l3vpn-2547bis-mcast-bgp-00.txteptember 2005 The Originating Router's IP Address is set to the IP address of the ASBR. If the next hop for the auto-discovery route is an EBGP neighbor of the ASBR, then the ASBR advertises the C-multicast route to that neighbor. If the next hop for the auto-discovery route is an IBGP neighbor of the ASBR, the ASBR advertises the route into IBGP. If it is the ASBR that originated the auto-discovery route in the first place, then the ASBR just advertises this route into IBGP. 10. Switching to S-PMSI Section 7.3.2 if [MVPN] describes a BGP based protocol for switching to S-PMSI. Auto-discovery routes are used for this purpose. The pro- cedures are described in section 7.3.2 of [MVPN]. The C-multicast streams for which the S-PMSI is being instantiated are advertised using the same procedures as the MVPN auto-discovery/binding proce- dures specified in this document with the following modifications: 1. The Multicast Source field MUST contain the source address associcated with the C-multicast stream, and the Multicast Source Length field is set appropriately to reflect this; 2. 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. 11. Electing a single forwarder PE In certain cases it may be necessary to elect a single forwarder PE to avoid packet duplication. Election of a single consistant upstream PE as described in [MVPN] may not suffice. An example is a (*, C-G) to (C-S, C-G) switch when a provider multicast tunnel is setup by a shared root and the PEs tunnel the traffic to the shared root using unicast tunnels. These election procedures utilize the MCAST-VPN NLRI and will be described in detail in the next revision. Raggarwa, et al. [Page 13] Internet Draftdraft-raggarwa-l3vpn-2547bis-mcast-bgp-00.txteptember 2005 12. Co-locating C-RPs on a PE Section 9 of [MVPN] describes two models for co-locating C-RPs on a PE. When the first model of anycast RP based on (*, C-G) advertisements is used, (C-*, C-G) information is advertised using MCAST-VPN SAFI as per the procedures of section 9.1.2 in [MVPN]. This information is sent to all PEs in the MVPN. When the second model of anycast RP based on advertising active sources is used, the active source information is advertised using MCAST-VPN NLRI as per the procedures of section 9.1.3 of [MVPN]. It MAY contain a Tunnel attribute if a S-PMSI is being signaled along with the active source. 13. 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 Route Import. This community is IPv4 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 is assigned its own SAFI. 14. References 14.1. Normative References [MVPN] E. Rosen, R. Aggarwal [Editors], "Multicast in MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-00.txt, [TUNNEL-ENCAP] "Signaling Tunnel Encapsulation/Deencapsulation Capa- bilities", work in progress. [RFC2119] "Key words for use in RFCs to Indicate Requirement Lev- els.", Bradner, March 1997 Raggarwa, et al. [Page 14] Internet Draftdraft-raggarwa-l3vpn-2547bis-mcast-bgp-00.txteptember 2005 14.2. Informative References [BGP-VPN] E. Rosen, Y. Rekhter, "BGP/MPLS VPNs", September 2003, draft-ietf-l3vpn-rfc2547bis-01.txt [MPLS-UPSTREAM] R. Aggrwal, Y. Rekhter, E. Rosen, " MPLS Upstream Label Assignment and Context Specific Label Space", draft-raggarwa- mpls-upstream-label-00.txt [PIM-SM] B. Fenner et. al., "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", draft-ietf-pim-sm- v2-new-11.txt [RT-CONSTRAIN] P. Marques et. al., ",Constrained VPN Route Distribu- tion" draft-ietf-l3vpn-rt-constrain-02 15. Author Information Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Email: rahul@juniper.net Chaitanya Kodeboniya Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Email: ck@juniper.net Yakov Rekhter Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Email: yakov@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 Raggarwa, et al. [Page 15] Internet Draftdraft-raggarwa-l3vpn-2547bis-mcast-bgp-00.txteptember 2005 Email: thomas.morin@francetelecom.com 16. 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 assur- ances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. 17. Full Copyright Statement Copyright (C) The Internet Society (2005). 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 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Raggarwa, et al. [Page 16] Internet Draftdraft-raggarwa-l3vpn-2547bis-mcast-bgp-00.txteptember 2005 Raggarwa, et al. [Page 17]