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 <P-
Root Node Address, Variable length opaque identifier>.
When the type is set to PIM-SM Tree, the tunnel identifier is <P-RP
Node Address, P-Multicast Group>.
When the type is set to PIM-SSM Tree, the tunnel identifier is <P-
Root Node Address, P-Multicast Group>.
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 <RD, Originating Router's IP address>
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 <C-S, C-G> 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<C-S, C-G> towards the source is carried in the
MP_REACH_NLRI attribute, and for Prune<C-S, C-G> towards the source
in the MP_UNREACH_NLRI attribute.
When a PE generates a <C-S, C-G> 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<C-S, C-G> towards the C-RP is carried in the
MP_UNREACH_NLRI attribute, and for Prune<C-S, C-G> 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 <C-*, C-G> 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<C-*, C-G> is carried in
the MP_REACH_NLRI attribute, and for Prune<C-*, C-G> in the
MP_UNREACH_NLRI attribute.
When a PE generates a <C-*, C-*> 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<C-*,
C-*> is carried in the MP_REACH_NLRI attribute, and for Prune<C-*,
C-*> 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 <RD, Originat-
ing Router's IP address> 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]