One document matched: draft-raggarwa-l3vpn-2547bis-mcast-bgp-01.txt
Differences from draft-raggarwa-l3vpn-2547bis-mcast-bgp-00.txt
Network Working Group R. Aggarwal
Internet Draft Juniper Networks
Expiration Date: September 2006
C. Kodeboniya
Juniper Networks
Y. Rekhter
Juniper Networks
E. Rosen
Cisco Systems, Inc.
T. Morin
France Telecom
March 2006
BGP Encodings for Multicast in MPLS/BGP IP VPNs
draft-raggarwa-l3vpn-2547bis-mcast-bgp-01.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.
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
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-
discovery/binding information carried in BGP as "auto-discovery
routes". For a given MVPN there are three types of auto-discovery
routes:
+ intra-AS auto-discovery route (auto-discovery route);
+ inter-AS auto-discovery route;
+ intra-AS segment leaf auto-discovery route (leaf 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 three types of C-Multicast routes:
+ shared tree join route;
+ source tree join route;
+ prune source from shared tree 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 [PIM-SM], except
that instead of a single TIB a PE maintains multiple MVPN-TIBs, one
per each MVPN.
3. Introduction
This document describes the BGP encodings 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 - Inclusive tunnel
binding, VPN customer multicast routing information exchange among
PEs, S-PMSI signaling, choosing a single forwarder PE, and for
anycast RP procedures required to home a C-RP on a PE.
This document also specifies new BGP attribute, P-Multicast Service
Interface Tunnel (PMSI Tunnel) attribute.
4. MCAST-VPN NLRI
This document defines a new BGP NLRI, called the MCAST-VPN NLRI.
This NLRI is carried in BGP using BGP Multiprotocol Extensions
[RFC2858bis]. Following is the format of the MCAST-VPN NLRI:
+-----------------------------------+
| Length (1 octet) |
+-----------------------------------+
| Route Type (1 octet) |
+-----------------------------------+
| Route Type specific (variable) |
+-----------------------------------+
The Length field indicates the length in octets of MCAST-VPN NLRI,
excluding the Length field itself.
The Route Type field defines encoding of the rest of MCAST-VPN NLRI
(Route Type specific MCAST-VPN NLRI).
This document defines the following Route Types for auto-discovery
routes:
+ 1 - Intra-AS auto-discovery route (or just auto-discovery route);
+ 2 - Inter-AS auto-discovery route;
+ 3 - Intra-AS segment leaf auto-discovery route (or just leaf
auto-discovery route).
This document defines the following Route Types for C-multicast
routes:
+ 4 - Shared Tree Join route;
+ 5 - Source Tree Join route;
+ 6 - Prune Source from Shared Tree route.
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 auto-discovery route
An intra-AS auto-discovery route type specific MCAST-VPN NLRI
consists of the following:
+-----------------------------------+
| RD (8 octets) |
+-----------------------------------+
| Originating Router's IP Addr |
+-----------------------------------+
| Multicast Source Length (1 octet) |
+-----------------------------------+
| Multicast Source (Variable) |
+-----------------------------------+
| Multicast Group Length (1 octet) |
+-----------------------------------+
| Multicast Group (Variable) |
+-----------------------------------+
The RD is encoded as described in [RFC4364].
If the Multicast Source field is empty (not present), then the value
of the Multicast Source Length field is 0. 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.
The Source Address field, if present, contains the C-S address.
If the Multicast Group field is empty (not present), then the value
of the Multicast Group Length field is 0. 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.
The Group Address field, if present, contains the C-G address.
4.2. Inter-AS auto-discovery route
An inter-AS 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].
An inter-AS auto-discovery route contains the autonomous system
number (AS number) of the ASBR that originates the route. This AS
number is encoded in the RD field of the MCAST-VPN NLRI of the route.
If the Multicast Source field is empty (not present), then the value
of the Multicast Source Length field is 0. 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.
The Source Address field, if present, contains the C-S address.
If the Multicast Group field is empty (not present), then the value
of the Multicast Group Length field is 0. 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.
The Group Address field, if present, contains the C-G address.
4.3. Leaf auto-discovery route
A leaf auto-discovery route type specific MCAST-VPN NLRI has the same
format as an intra-AS auto-discovery route type specific MCAST-VPN
NLRI.
4.4. C-Multicast Route
A shared tree join route, a source tree join route, and a prune
source from shared tree route have the following encoding:
+-----------------------------------+
| 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].
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.
The Source Address field contains the C-S 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.
The Group Address field contains the C-G address.
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:
+---------------------------------+
| Tunnel Type (2 octets) |
+---------------------------------+
| MPLS Label (3 octets) |
+---------------------------------+
| Tunnel Identifier (variable) |
+---------------------------------+
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:
+ 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
contains 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 MUST
include P-Multicast Group address, and MAY include P-RP Node Address.
When the type is set to PIM-SSM Tree, the Tunnel Identifier is <P-
Root Node Address, P-Multicast Group>.
When the type is set to PIM-Bidir Tree, the Tunnel Identifier MUST
include P-Multicast Group address, and MAY include P-RP Node Address.
When the type is set to Ingress Replication the Tunnel Identifier
carries the unicast tunnel endpoint.
When the type is set to LDP MP2MP LSP, the Tunnel Identifier is <P-
Root Node Address, Variable length opaque identifier>.
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")
mandatory.
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
transitive 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
specific. 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. The Local Administrator field of
this Route Target should contain a 2 octets long number that uniquely
identifies that VRF within the PE that contains the VRF (procedures
for assigning such number are purely local to the PE, and outside the
scope of this document). A PE that originates a route to VPN-IPv4
addresses MUST include in the BGP Updates message that carries 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 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, rather than all the PEs participating the an
MVPN.
8. MVPN Auto-Discovery/Binding
This section specifies procedures for the autodiscovery 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 [BGP-VPN]. 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 auto-discovery/binding
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 route is constructed as
follows.
The route carries a single MCAST-VPN NLRI constructed as follows:
+ The RD in this NLRI is set to the RD of the VRF.
+ The Originating Router's IP Address is set to the IP address of
the PE that generates the advertisement. This address doesn't
have to be a routable IP address. Note that the <RD, Originating
Router's IP address> tuple results in an address that uniquely
identifies a given multicast VRF.
+ The Multicast Source Length field and the Multicast Group Length
field MUST both be set to 0.
If a P-Multicast Tree is used to instantiate the provider tunnel for
the MVPN on the PE, 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 type and the identity of
the P-Multicast tree in the PMSI Tunnel attribute of the route.
If a P-Multicast Tree is used to instantiate the provider tunnel for
the MVPN on the PE, and in order to advertise the P-Multicast tree
identifier the advertising PE needs to know the leaves of the tree
beforehand, the PE first discovers the leaves using the Auto-
Discovery procedures, as described above. It then advertises the
binding of the tree to the MVPN using the same route as the one used
for the auto-discovery, with the addition of carrying in the route
the PMSI Tunnel attribute that contains the type and the identity of
the P-Multicast tree. In other words, in the first phase the PE
advertises an auto-discovery route, but with no binding, and receives
auto-discovery routes from other PEs. Once this is done, in the
second phase the PE advertises binding based on the information
acquired in the first phase. If at some later point a new PE
advertises participation in the same MVPN, the initial binding PMSI
Tunnel binding information SHOULD NOT change (though the leaves of
the corresponding P-multicast tree may change).
When multiple MVPNs are aggregated onto the same P-multicast tree,
advertised in the PMSI Tunnel attribute, the PMSI Tunnel attribute
MUST carry a MPLS upstream assigned label [MPLS-UPSTREAM] that is
associated with the MVPN.
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.
The Next Hop field of the MP_REACH_NLRI attribute is set to a
routable IP address of 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.
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-IPv4 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 for a VRF, 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 set of Route Targets used for the auto-
discovery routes being distinct from the ones used for the VPN-IPv4
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. Receiving auto-discovery/binding
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) one of the Route Targets
of the route matches one of the import Route Targets configured for a
particular VRF on the local PE, (c) the BGP route selection
determines that this is the best route with respect to the NLRI
carried by the route, and (d) the route carries the PMSI Tunnel
attribute, the PE performs the following.
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.
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 the import
Route Target 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 label, and all packets that are
received on this tree with that upstream label are forwarded using
the matching VRF.
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) RTs that
would specify the set of MVPNs supported by the ASBR. These RTs
would 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 RTs as the ones used
for supporting unicast.
+ The ASBR 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.
Note, that this RT is used by both the auto-discovery routes and
C-multicast routes (see Section "VPN C-Multicast Routing
Information Exchange among PEs").
+ The ASBR MUST be configured with the tunnel type 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.
+ If the ASBR originates an inter-AS auto-discovery route for a
particular MVPN within its own AS, the ASBR MUST be configured
with the AS-specific RD for that MVPN. This RD MUST be of Type 0,
and MUST embed the autonomous system number of the AS. The
Assigned Number field of the RD contains a number that MUST
uniquely identify that MVPN within that AS (however, for a given
MVPN each AS may assign this number on its own, without
coordination with other ASes). As a result, for a given MVPN and
a given AS all the ASBRs within that AS that originate the inter-
AS auto-discovery route for that MVPN would be configured with
the same RD for that MVPN. Note also that ASBRs in a pure transit
AS need not originate any inter-AS auto-discovery route.
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 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 constructed as follows:
+ The RD MUST be set to the RD configured for that MVPN on the
ASBR.
+ The Multicast Source Length field and the Multicast Group Length
field MUST both be set to 0.
The Next Hop field of the MP_REACH_NLRI attribute is set to a
routable IP address of the ASBR.
By default the BGP Update message 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
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>.
8.2.2. Propagating Inter-AS MVPN Auto-Discovery Information
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. The
precise rules for distributing and processing the inter-AS auto-
discovery routes are given in subsequent sections.
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 neighbor" 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 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 originates 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
constructed by its own independent mechanism. Moreover, by using
upstream 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 multicast tunnel 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), then all the
information needed to create that segment will be present in the
inter-AS auto-discovery routes. But if the multicast tunnel
instantiating the segment is created by a protocol that does not use
receiver-initiated joins (e.g., RSVP-TE, ingress unicast
replication), 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 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.
The following sections specify procedures for propagation of
(aggregated) inter-AS auto-discovery routes across ASes.
8.2.2.1. 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.
When re-advertising an inter-AS auto-discovery route the ASBR MUST
NOT modify the NLRI of the route.
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 ASBR uses ingress replication to instantiate the intra-AS
segment of the inter-AS tunnel, the re-advertised route SHOULD carry
the PMSI Tunnel attribute with the Tunnel Type set to Ingress
Replication, but no MPLS labels.
If a P-Multicast Tree is used to instantiate the intra-AS segment of
the inter-AS tunnel, and in order to advertise the P-Multicast tree
identifier the ASBR does not need to know the leaves of the tree
beforehand, then the advertising ASBR SHOULD advertise the type and
the identity of the P-Multicast tree in the PMSI Tunnel attribute of
the route. This, in effect, creates a binding between the inter-AS
auto-discovery route and the P-Multicast Tree.
If a P-Multicast Tree is used to instantiate the intra-AS segment of
the inter-AS tunnel, and in order to advertise the P-Multicast tree
identifier the advertising ASBR needs to know the leaves of the tree
beforehand, the ASBR first discovers the leaves using the Auto-
Discovery procedures, as specified further down. It then advertises
the binding of the tree to the inter-AS auto-discovery route using
the original inter-AS auto-discovery route with the addition of
carrying in the route the PMSI Tunnel attribute that contains the
type and the identity of the tree. In other words, in the first phase
the ASBR advertises inter-AS auto-discovery routes, but with no
binding. Once this is done, in the second phase the ASBR advertises
binding based on the information acquired in the first phase.
When multiple inter-AS auto-discovery routes are bound onto the same
P-multicast tree advertised in the PMSI Tunnel attribute, the PMSI
Tunnel attribute MUST carry a MPLS upstream assigned label [MPLS-
UPSTREAM] that is associated with the inter-AS auto-discovery route.
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 constructed as follows:
+ The RD in this NLRI is set to the RD carried in the inter-AS
auto-discovery route received from that neighbor.
+ 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 ASBR.
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 to demultiplex the MVPN traffic received over a unicast
tunnel by the advertising router.
The leaf auto-discovery route MUST carry the same set of Route Target
communities as was carried in the received inter-AS auto-discovery
route.
The Next Hop field of the MP_REACH_NLRI attribute of the route is set
to a routable IP address of the ASBR.
To constrain the distribution scope of this route the route SHOULD
carry the NO_ADVERTISE BGP community ([RFC1997]).
8.2.2.2. Leaf Auto-Discovery Route received via EBGP
When an ASBR receives via EBGP a leaf auto-discovery route, the ASBR
finds an inter-AS auto-discovery route that has the same RD as 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 inter-AS auto-discovery route.
8.2.2.3. 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.
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)
the route was originated outside of the router'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 PE/ASBR, and (c) 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.
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.
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
auto-discovery route. If the PMSI Tunnel attribute carries a
(upstream) 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 received inter-AS auto-discovery route either does not carry
the PMSI Tunnel attribute, or carries the PMSI Tunnel attribute with
the Tunnel Type set to ingress replication, then the PE/ASBR
originates a new leaf auto-discovery route as follows.
The route carries a single MCAST-VPN NLRI constructed as follows:
+ The RD in the NLRI is set to the RD of the received inter-AS
auto-discovery route.
+ 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 ASBR. This address doesn't have to 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, 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 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 adds this
community to the Extended Community attribute of the leaf auto-
discovery route. The route MUST carry the NO_EXPORT Community.
Once the leaf auto-discovery route is constructed, the PE/ASBR
advertises this route into IBGP.
8.2.2.4. Leaf Auto-Discovery route received via IBGP
When an ASBR receives via IBGP a leaf auto-discovery route, the ASBR
finds an inter-AS auto-discovery route that has the same RD as the
leaf auto-discovery route.
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-tree rooted at the ASBR that would be used for the
intra-AS segment associated with the inter-AS 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 for the
auto-discovery routes. The export Route Targets are added to the
Route Targets used for unicast routing when originating VPN-IPv4
routes. The export Route Targets control the set of sites that could
receive multicast traffic originated by the sources within the local
site. The import Route Targets associated with a given VRF are used
to determine which of the received VPN-IPv4 routes should be accepted
into the VRF. The import Route Targets control the set of sites that
contain sources of multicast traffic that could be received within
the local site.
If an MVPN site is single-homed to a PE, then on this PE the VRF
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
should 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).
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 use RSVP
TE P2MP LSPs, 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, in which case the PE
originates an auto-discovery route with the PMSI Tunnel attribute
indicating ingress replication.
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
10.1.1. Constructing MCAST-VPN NLRI
Procedures for constructing MCAST-VPN NLRI depend on the multicast
routing protocol between CE and PE (C-multicast protocol).
10.1.1.1. 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> or <C-S, C-G, RPT-bit> or <C-*, C-*> state learnt by a
PE via the C-multicast protocol.
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. The source address in the MCAST-VPN NLRI of the
route is set to C-S, the group address is set of C-G. The MCAST-VPN
NLRI is carried as a source tree join route type. 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.
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. The source address in the MCAST-VPN
NLRI of the route is set to the C-RP address. The MCAST-VPN NLRI of
the route is carried as the shared tree join route type. 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.
Whenever a PE creates a new <C-S, C-G, RPT-bit> state in one of its
MVPN-TIBs (this state is created whenever the PE that has an existing
<C-*, C-G> state switches from the C-RP based tree to the C-S based
tree for C-G), if the C-RP is reachable through some other PE the
local PE originates a C-multicast route. The source address in the
MCAST-VPN NLRI of the route is set to C-S and the group address is
set to C-G. The MCAST-VPN NLRI of the route is carried as the prune
source from shared tree route type. The semantics of the route is to
indicate that the receivers for <C-S,C-G> no longer want to receive
<C-S, C-G> traffic via the C-RP based tree (the route has the (C-S,C-
G, RPT) Prune semantics). If later on the PE deletes a previously
created <C-S, C-G, RPT-bit> state, the PE withdraws the route (the
semantics of the withdrawn route is to indicate that <C-S, C-G>
traffic should be carried via the C-RP-based tree). The MCAST-VPN
NLRI of the withdrawn route is carried in the MP_UNREACH_NLRI
attribute.
Whenever a PE creates a <C-*, C-*> state in one of its MVPN-TIBs, if
the C-RP is reachable through some other PE the local PE originates a
C-multicast route. The source address in the MCAST-VPN NLRI of the
route is set to the C-RP address. The group address in the NLRI MUST
be set to a wildcard i.e. 0. The MCAST-VPN NLRI of the route is
carried as the shared tree join route type. Whenever a PE deletes a
previously created <C-*, C-*> state that had resulted in originating
a C-multicast route, the PE withdraws the route (the withdrawn route
has the (C-*, C-*) Prune semantics). The MCAST-VPN NLRI of the
withdrawn route is carried in the MP_UNREACH_NLRI attribute.
10.1.2. Constructing the rest of the route
The rest of the C-multicast 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). Note that for a C-multicast route that the PE originates in
response to creating a <C-S, C-G, RPT-bit> state, the remote PE is
the PE that originates the route to C-RP, not to C-S.
Irrespective of whether the local and the remote PE are in the same
or different ASes, the Extended Community attribute of the route MUST
include the import Route Target community associated with the VRF on
the remote PE.
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 ASes, then the local
PE finds in its VRF an inter-AS auto-discovery route whose RD embeds
the 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
constructs 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.
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 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.
10.1.3. 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 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 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.
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
auto-discovery route whose RD matches the RD carried in the C-
multicast route.
If the next hop for the found 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 auto-discovery
route is an IBGP neighbor of the ASBR, the ASBR re-advertises the
route into IBGP. If it is the ASBR that originated the found auto-
discovery route in the first place, then the ASBR just re-advertises
this route into IBGP.
Before re-advertising the C-Multicast route, the ASBR modifies the
Extended Community attribute of the 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 auto-discovery route, and Local Administrator field of this
community set to 0. The rest of the Extended Community attribute of
the route is passed unmodified.
The Originating Router's IP Address is set to 0.
The Next Hop field of the MP_REACH_NLRI attribute is set to a
routable IP address of the ASBR.
10.3. Receiving C-Multicast Routes by a PE
Procedures for a PE to process received C-multicast routes depend on
the multicast routing protocol between CE and PE (C-multicast
protocol).
10.3.1. PIM as the C-Multicast protocol
When a PE receives a C-multicast route the PE checks if any of the
Route Target communities carried in the Extended Community 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, as a local choice, may keep the route, but does not perform
any further processing of the route. If a match is found then the PE
proceeds as follows.
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
source address and group address 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.
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 source address, and C-G for
that state taken from the group address field 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.
If the received route has the route type set to prune source from
shared tree, then the PE creates a new <C-S, C-G, RPT-bit> state in
its MVPN-TIB from the source address and group address fields in 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.
11. 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
procedures 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
procedures (both intra-AS and inter-AS) specified in this document
with the following modifications:
1. 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;
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.
The above two points apply to both the inter-AS auto-discovery routes
and to the leaf auto-discovery routes.
12. Choosing a single forwarder PE
In certain cases it may be necessary to choose a single forwarder PE
to avoid packet duplication. Choosing of a single consistent upstream
PE as described in [MVPN] may not suffice. An example is a <C-*, C-G>
to <C-S, C-G> switch. Consider a set of PEs {PE2, PE4, PE6} that are
on the C-RP tree for <C-*, C-G> and have chosen a consistant 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 C-Multicast route towards the upstream PE
that is on the path to C-S, say PE3. PE3 also uses an MI-PMSI for <C-
S, 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 text describes how this is achieved.
Whenever a PE creates an <C-S,C-G> state as a result of receiving a
C-multicast route for <C-S, C-G> from some other PE, the PE that
creates the state SHOULD originate an auto-discovery route. The route
is being advertised using the same procedures as the MVPN auto-
discovery/binding (both intra-AS and inter-AS) specified in this
document with the following modifications:
1. The Multicast Source field MUST be set to C-S. The Multicast
Source Length field is set appropriately to reflect this.
2. The Multicast Group field MUST be set to C-G. The Multicast
Group Length field is set appropriately to reflect this.
The above two points apply to both the inter-AS auto-discovery routes
and to the leaf auto-discovery routes.
The route goes to all the PEs of the MVPN. When a PE receives this
route, it checks whether there are any receivers in the MVPN sites
attached to the PE for the group carried in the route. If yes, then
it generates a C-multicast route indicating Join for <C-S, C-G>.
This forces all the PEs to switch to the C-S tree for <C-S, C-G> from
the C-RP tree.
Whenever the PE deletes the <C-S, C-G> state that was previousely
created as a result of receiving a C-multicast route for <C-S, C-G>
from some other PE, the PE that deletes the state also withdraws the
auto-discovery route that was advertised when the state was created.
13. Co-locating C-RPs on a PE
Section 9 of [MVPN] describes two models for co-locating C-RPs on a
PE.
13.1. Anycast RP Based on C-(*, G) Advertisements
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. Further details will be described in the
future revision of this document.
13.2. Anycast RP Based on Propagating Active Sources
The second model of anycast RP is based on advertising active
sources.
13.2.1. Source Within a Site - Active Source Advertisement
When a PE receives a PIM-Register message from one of its directly
connected CEs that belong to a given MVPN, the PE follows the normal
PIM procedures. In addition the PE advertises the source and the
group of the multicast data packet caried in PIM-Register message
using an auto-discovery route. The route is being instantiated and
handled using the same procedures as the MVPN auto-discovery/binding
(both intra-AS and inter-AS) specified in this document with the
following modifications:
1. 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.
2. 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 above two points apply to both the inter-AS auto-discovery routes
and to the leaf auto-discovery routes.
The route goes to all the PEs of the MVPN. When a PE receives this
route, it checks whether there are any receivers in the MVPN sites
attached to the PE for the group carried in the route. If yes, then
it generates an advertisement for <C-S, C-G> as specified in the next
section.
13.2.2. Receiver(s) Within a Site
A PE which receives C-Join for <C-*, C-G> or <C-S, C-G> from one of
its connected CEs that belong to a given MVPN does not send the
information that it has receiver(s) for C-G until it receives an
auto-discovery route from some other PE indicating that there are
active sources for that G.
On receiving an auto-discovery route (described in the previous
section), the downstream PE will respond with a C-multicast route
indicating Join for <C-S, C-G>. The route is constructed as described
in Section "Originating C-Multicast Routes by a PE".
14. Scalability Considerations
A PE should use Route Target Constrain [RT-CONSTRAIN] to advertise
the Route Targets that the PE uses for the 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.
For a given inter-AS tunnel each of its intra-AS segments could be
constructed by its own mechanism. Moreover, by using upstream 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-IPv4 routes (although they may be
used for VPN-IPv4 routes as well).
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.
15. 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.
This document defines a new BGP optional transitive attribute, called
PMSI Tunnel.
16. Security Considerations
The mechanisms described in this document could re-use the existing
BGP security mechanisms.
17. References
17.1. Normative References
[MVPN] E. Rosen, R. Aggarwal [Editors], "Multicast in MPLS/BGP IP
VPNs", draft-ietf-l3vpn-2547bis-mcast-01.txt,
[RFC2119] "Key words for use in RFCs to Indicate Requirement
Levels.", Bradner, March 1997
[RFC4364] E. Rosen, Y. Rekhter, "BGP/MPLS IP Virtual Private Networks
(VPNs)", RFC4364, February 2006
17.2. Informative References
[MPLS-UPSTREAM] R. Aggrwal, Y. Rekhter, E. Rosen, " MPLS Upstream
Label Assignment and Context Specific Label Space", draft-raggarwa-
mpls-upstream-label-01.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
Distribution" draft-ietf-l3vpn-rt-constrain-02
18. 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
Email: thomas.morin@francetelecom.com
19. 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.
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.
20.
Copyright Notice
Copyright (C) The Internet Society (2006).
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
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
| PAFTECH AB 2003-2026 | 2026-04-22 09:53:12 |