draft-ietf-mpls-mldp-recurs-fec-04.txt   rfc6512.txt 
MPLS Working Group IJsbrand Wijnands Internet Engineering Task Force (IETF) IJ. Wijnands
Internet Draft Eric C. Rosen Request for Comments: 6512 E. Rosen
Intended Status: Proposed Standard Cisco Systems, Inc. Category: Standards Track Cisco Systems
Expires: January 25, 2012 ISSN: 2070-1721 M. Napierala
Maria Napierala
AT&T AT&T
N. Leymann
Nicolai Leymann
Deutsche Telekom Deutsche Telekom
February 2012
July 25, 2011 Using Multipoint LDP When the Backbone Has No Route to the Root
Using Multipoint LDP when the Backbone has no Route to the Root
draft-ietf-mpls-mldp-recurs-fec-04.txt
Abstract Abstract
The control protocol used for constructing Point-to-Multipoint and The control protocol used for constructing Point-to-Multipoint and
Multipoint-to-Multipoint Label Switched Paths ("MP LSPs") contains a Multipoint-to-Multipoint Label Switched Paths ("MP LSPs") contains a
field that identifies the address of a "root node". Intermediate field that identifies the address of a "root node". Intermediate
nodes are expected to be able to look up that address in their nodes are expected to be able to look up that address in their
routing tables. However, if the route to the root node is a BGP routing tables. However, this is not possible if the route to the
route, and the intermediate nodes are part of a BGP-free core, this root node is a BGP route and the intermediate nodes are part of a
is not possible. This document specifies procedures which enable a BGP-free core. This document specifies procedures that enable an MP
MP LSP to be constructed through a BGP-free core. In these LSP to be constructed through a BGP-free core. In these procedures,
procedures, the root node address is temporarily replaced by an the root node address is temporarily replaced by an address that is
address that is known to the intermediate nodes and is on the path to known to the intermediate nodes and is on the path to the true root
the true root node. node.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
The list of current Internet-Drafts can be accessed at Internet Standards is available in Section 2 of RFC 5741.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Information about the current status of this document, any errata,
http://www.ietf.org/shadow.html. and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6512.
Copyright and License Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1 Introduction .......................................... 3 1. Introduction ....................................................3
2 The Recursive Opaque Value ............................ 5 2. The Recursive Opaque Value ......................................5
2.1 Encoding .............................................. 5 2.1. Encoding ...................................................5
2.2 Procedures ............................................ 5 2.2. Procedures .................................................5
3 The VPN-Recursive Opaque Value ........................ 6 3. The VPN-Recursive Opaque Value ..................................6
3.1 Encoding .............................................. 6 3.1. Encoding ...................................................6
3.2 Procedures ............................................ 7 3.2. Procedures .................................................7
3.2.1 Non-segmented Inter-AS P-tunnels ...................... 7 3.2.1. Non-Segmented Inter-AS P-Tunnels ....................7
3.2.2 Limited Carrier's Carrier Function .................... 9 3.2.2. Limited Carrier's Carrier Function ..................9
4 IANA Considerations ................................... 10 4. IANA Considerations ............................................10
5 Security Considerations ............................... 11 5. Security Considerations ........................................10
6 Acknowledgments ....................................... 11 6. Acknowledgments ................................................10
7 Authors' Addresses .................................... 11 7. References .....................................................11
8 Normative References .................................. 12 7.1. Normative References ......................................11
9 Informative References ................................ 12 7.2. Informative References ....................................11
1. Introduction 1. Introduction
The document [mLDP] extends LDP ("Label Distribution Protocol", The document [mLDP] extends LDP [LDP] to support multipoint Label
[LDP]) to support multipoint label-switched paths. These extensions Switched Paths. These extensions are known as "Multipoint LDP", or
are known as "Multipoint LDP", or more simply as "mLDP". [mLDP] more simply, as "mLDP". [mLDP] defines several LDP Forwarding
defines several LDP "Forwarding Equivalence Class" (FEC) element Equivalence Class (FEC) element encodings: "Point-to-Multipoint"
encodings: "Point-to-Multipoint" (P2MP), "Multipoint-to-Multipoint (P2MP), "Multipoint-to-Multipoint (MP2MP) Upstream", and "MP2MP
(MP2MP) Upstream", and "MP2MP Downstream". Downstream".
The encoding for these three FEC elements, as defined in [mLDP], is The encoding for these three FEC elements, as defined in [mLDP], is
shown in Figure 1. shown in Figure 1.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Address Family | Address Length| | Type | Address Family | Address Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Root Node Address ~ ~ Root Node Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | . | | Opaque Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~ ~ ~
| Opaque Value | | Opaque Value |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
mLDP FEC Element Encoding Figure 1: mLDP FEC Element Encoding
Figure 1
Note that a P2MP or MP2MP label switched path ("MP LSP") is Note that a P2MP or MP2MP Label Switched Path ("MP LSP") is
identified by the combination of a "root node" and a variable length identified by the combination of a "root node" and a variable length
"opaque value". The root node also plays a special role in the mLDP "opaque value". The root node also plays a special role in the mLDP
procedures - mLDP messages that are "about" a particular MP LSP are procedures: mLDP messages that are "about" a particular MP LSP are
forwarded to the LDP adjacency that is the next hop on the route to forwarded to the LDP adjacency that is the next hop on the route to
the root node. the root node.
Sometimes it is desirable for a MP LSP to pass through a part of the Sometimes, it is desirable for an MP LSP to pass through a part of
network in which there is no route to the root node. For instance, the network in which there is no route to the root node. For
consider the topology of Figure 2. instance, consider the topology of Figure 2.
CE1----PE1---P1---- ...----P2 ----PE2----CE2----R CE1----PE1---P1---- ...----P2 ----PE2----CE2----R
Figure 2 Figure 2
In Figure 2, CE1 and CE2 are "customer edge routers", R is a customer In Figure 2, CE1 and CE2 are "Customer Edge routers", R is a customer
router at the same VPN site as CE2, PE1 and PE2 are "provider edge router at the same VPN site as CE2, and PE1 and PE2 are "Provider
routers". Suppose that the provider's core is "BGP-free". That is, Edge routers". Suppose that PE1 has a BGP-learned route for R, with
PE1 has a BGP-learned route for R, in which PE2 is the BGP next hop. PE2 as the BGP next hop. Suppose also that the provider's interior
However, the provider's interior routers (such as P1 and P2) do not routers (such as P1 and P2) do not have any BGP-learned routes and,
have any BGP-learned routes, and in particular do not have any routes in particular, do not have any routes to R.
to R.
In such an environment, unicast data packets from CE1 addressed to R In such an environment, unicast data packets from CE1 addressed to R
would get encapsulated by PE1, tunneled to PE2, decapsulated by PE2, would get encapsulated by PE1, tunneled to PE2, decapsulated by PE2,
and forwarded to CE2. and forwarded to CE2.
Suppose now that CE1 is trying to set up a MP LSP whose root is R, Suppose now that CE1 is trying to set up an MP LSP whose root is R,
and the intention is that the provider's network will participate in and the intention is that the provider's network will participate in
the construction of the LSP. Then the mLDP messages identifying the the construction of the LSP. Then, the mLDP messages identifying the
LSP must be passed from CE1 to PE1, from PE1 to P1, ..., from P2 to LSP must be passed from CE1 to PE1, from PE1 to P1, ..., from P2 to
PE2, from PE2 to CE2, and from CE2 to R. PE2, from PE2 to CE2, and from CE2 to R.
To begin the process, CE1 creates a MP FEC element with the address To begin the process, CE1 creates an MP FEC element with the address
of R as the root node address, and passes that FEC element via mLDP of R as the root node address and passes that FEC element via mLDP to
to PE1. However, PE1 cannot use this same FEC element to identify PE1. However, PE1 cannot use this same FEC element to identify the
the LSP in the LDP messages it sends to P1, because P1 does not have LSP in the LDP messages it sends to P1, because P1 does not have a
a route to R. route to R.
However, PE1 does know that PE2 is the "BGP next hop" on the path to However, PE1 does know that PE2 is the BGP next hop on the path to R.
R. What is needed is a method whereby: What is needed is a method whereby:
- PE1 can tell P1 to set up an LSP as if the root node were PE2, - PE1 can tell P1 to set up an LSP as if the root node were PE2,
and
- PE2 can determine that the LSP in question is really rooted at R, - PE2 can determine that the LSP in question is really rooted at R,
not at PE2 itself, not at PE2 itself, and
- PE2 can determine the original FEC element that CE1 passed to - PE2 can determine the original FEC element that CE1 passed to PE1,
PE1, so that PE2 can pass it on to CE2. so that PE2 can pass it on to CE2.
This document defines the procedures that allow CE1 to create an LSP This document defines the procedures that allow CE1 to create an LSP
rooted at R. These procedures require PE1 to modify the MP FEC rooted at R. These procedures require PE1 to modify the MP FEC
element before sending an mLDP message to P1. The modified FEC element before sending an mLDP message to P1. The modified FEC
element has PE2 as the root, and the original FEC element as the element has PE2 as the root and the original FEC element as the
opaque value. This requires a new type of opaque value. Since the opaque value. This requires a new type of opaque value. Since the
opaque value contains a FEC element, we call this a "Recursive Opaque opaque value contains a FEC element, we call this a "Recursive Opaque
Value". When PE2 sends an mLDP message to CE2, it replaces the FEC Value". When PE2 sends an mLDP message to CE2, it replaces the FEC
element with the opaque value, thus undoing the recursion. Details element with the opaque value, thus undoing the recursion. Details
are in section 2. are in Section 2.
Section 3 defines a "Virtual Private Network (VPN) Recursive Opaque Section 3 defines the "VPN-Recursive Opaque Value". Whereas the
Value". Whereas the "Recursive Opaque Value" carries the original "Recursive Opaque Value" carries the original FEC, the "VPN-Recursive
FEC, the "VPN Recursive Opaque Value" carries the original FEC plus a Opaque Value" carries the original FEC plus a Route Distinguisher
Route Distinguisher (RD). This is applicable when MP LSPs are being (RD). This is applicable when MP LSPs are being used to carry the
used to carry the multicast traffic of a VPN [MVPN]. Details are in multicast traffic of a VPN [MVPN]. Details are in Section 3.
section 3.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. The Recursive Opaque Value 2. The Recursive Opaque Value
2.1. Encoding 2.1. Encoding
We define a new type of Opaque Value, the Recursive Opaque Value. We define a new type of opaque value, the Recursive Opaque Value.
This is a "basic type", identified by a one-octet type field. This is a "basic type", identified by a 1-octet type field.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length | | | Type = 7 | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ~ ~ ~
| P2MP or MP2MP FEC Element | | P2MP or MP2MP FEC Element |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Recursive Opaque Value Figure 3: Recursive Opaque Value
Figure 3
The value field of the "Recursive Opaque Value" is itself is a P2MP The value field of the Recursive Opaque Value is itself a P2MP or
or MP2MP FEC element, encoded exactly as specified in [mLDP], with a MP2MP FEC element, encoded exactly as specified in [mLDP], with a
type field, a length field, and value field of its own. The length type field, a length field, and value field of its own. The length
of the Recursive Opaque Value thus includes the lengths of the type, of the Recursive Opaque Value thus includes the lengths of the type,
length, and value fields of the contained FEC element. length, and value fields of the contained FEC element.
2.2. Procedures 2.2. Procedures
In the topology of Figure 2, let us suppose that CE1 sends PE1 an MP In the topology of Figure 2, let us suppose that CE1 sends PE1 an MP
FEC element whose root node is R, and whose opaque value is Q. We FEC element whose root node is R and whose opaque value is Q. We
will refer to this FEC element as "CE1-FEC". We may think of CE1-FEC will refer to this FEC element as "CE1-FEC". We may think of CE1-FEC
as an ordered pair, as follows: as an ordered pair, as follows:
CE1-FEC = <root=R, opaque_value=Q>. CE1-FEC = <root=R, opaque_value=Q>.
PE1 determines that the root node R matches a BGP route, with a BGP PE1 determines that the root node R matches a BGP route, with a BGP
next hop of PE2. PE1 also knows by its configuration that the next hop of PE2. PE1 also knows by its configuration that the
interior routers on the path to PE2 are "BGP-free", and thus have no interior routers on the path to PE2 are "BGP-free" and thus have no
route to R. route to R.
PE1 therefore creates a new MP FEC element, whose root node address PE1 therefore creates a new MP FEC element, whose root node address
is the address of PE2, and whose opaque value is a Recursive Opaque is the address of PE2 and whose opaque value is a Recursive Opaque
Value whose value field contains CE1-FEC. We refer to this FEC Value whose value field contains CE1-FEC. We refer to this FEC
element as PE2-FEC: element as PE2-FEC:
PE2-FEC = <root=PE2, opaque_value=CE1-FEC>, i.e., PE2-FEC = <root=PE2, opaque_value=CE1-FEC>, i.e.,
PE2-FEC = <root=PE2, opaque_value=<root=R, PE2-FEC = <root=PE2, opaque_value=<root=R,
opaque_value=Q>> opaque_value=Q>>
PE1 then sends this FEC element to P1. PE1 then sends this FEC element to P1.
As far as the interior routers are concerned, they are being As far as the interior routers are concerned, they are being
requested to build a MP LSP whose root node is PE2. They MUST NOT requested to build an MP LSP whose root node is PE2. They MUST NOT
interpret the opaque value at all. interpret the opaque value at all.
When PE2-FEC arrives at PE2, PE2 notes that it (PE2) is the When PE2-FEC arrives at PE2, PE2 notes that it (PE2) is the
identified root node, and that the opaque value is a Recursive Opaque identified root node and that the opaque value is a Recursive Opaque
Value. Therefore PE2 MUST replace PE2-FEC with the contents of the Value. Therefore, PE2 MUST replace PE2-FEC with the contents of the
Recursive Opaque Value (i.e., with CE1-FEC) before doing any further Recursive Opaque Value (i.e., with CE1-FEC) before doing any further
processing. This will result in CE1-FEC being sent on to CE2, and processing. This will result in CE1-FEC being sent on to CE2, and
further from CE2 to R. Note that CE1-FEC will contain the LSP root further from CE2 to R. Note that CE1-FEC will contain the LSP root
node specified by CE1; the presumption is that PE2 has a route to node specified by CE1; the presumption is that PE2 has a route to
this root node. this root node.
3. The VPN-Recursive Opaque Value 3. The VPN-Recursive Opaque Value
3.1. Encoding 3.1. Encoding
We define a new type of Opaque Value, the VPN-Recursive Opaque Value. We define a new type of opaque value, the VPN-Recursive Opaque Value.
This is a "basic type", identified by a one-octet type field. This is a "basic type", identified by a 1-octet type field.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length | | | Type = 8 | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Route Distinguisher (8 octets) +-+-+-+-+-+-+-+-+ | Route Distinguisher (8 octets) +-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ~ ~ ~
| P2MP or MP2MP FEC Element | | P2MP or MP2MP FEC Element |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VPN-Recursive Opaque Value Figure 4: VPN-Recursive Opaque Value
Figure 4
The value field of the "VPN-Recursive Opaque Value" consists of an The value field of the VPN-Recursive Opaque Value consists of an
eight-octet Route Distinguisher (RD), followed by a P2MP or MP2MP FEC 8-octet Route Distinguisher (RD), followed by a P2MP or MP2MP FEC
element, encoded exactly as specified in [mLDP], with a type field, a element, encoded exactly as specified in [mLDP], with a type field, a
length field, and value field of is own. The length of the VPN- length field, and value field of is own. The length of the
Recursive Opaque Value thus includes the 8 octets of RD plus the VPN-Recursive Opaque Value thus includes the 8 octets of RD plus the
lengths of the type, length, and values fields of the contained FEC lengths of the type, length, and values fields of the contained FEC
element. element.
3.2. Procedures 3.2. Procedures
3.2.1. Non-segmented Inter-AS P-tunnels 3.2.1. Non-Segmented Inter-AS P-Tunnels
Consider the Inter-AS VPN scenario depicted in Figure 5. Consider the inter-AS (Autonomous System) VPN scenario depicted in
Figure 5.
PE1 --- P1 ---- ASBR1 ... ASBR2 ---- P2 ---- PE2 PE1 --- P1 ---- ASBR1 ... ASBR2 ---- P2 ---- PE2
Figure 5 Figure 5
Suppose this is an "option B" VPN interconnect ([VPN] section 10). Suppose this is an "option B" VPN interconnect ([VPN], Section 10).
This means that the Autonomous System Border Router (ASBR) in the This means that the Autonomous System Border Router (ASBR) in the
first Autonomous System (i.e., ASBR1) does not have a route to PE first Autonomous System (i.e., ASBR1) does not have a route to PE
routers in other ASes (such as PE2). Suppose also that the MVPN routers in other ASes (such as PE2). Suppose also that the Multicast
policy is to instantiate PMSIs [MVPN] using mLDP, and that VPN (MVPN) policy is to instantiate Provider Multicast Service
"non-segmented inter-AS P-tunnels" [MVPN] are being used. Interfaces (PMSIs) [MVPN] using mLDP and that "non-segmented inter-AS
P-tunnels" [MVPN] are being used.
In this scenario, PE1 may need to join a P2MP or MP2MP LSP whose root In this scenario, PE1 may need to join a P2MP or MP2MP LSP whose root
is PE2. P1 has no route to PE2, and all PE1 knows about the route to is PE2. P1 has no route to PE2, and all PE1 knows about the route to
PE2 is that ASBR1 is the BGP next hop. Since P1 has no root to PE2, PE2 is that ASBR1 is the BGP next hop. Since P1 has no root to PE2,
PE1 needs to originate an mLDP message with a FEC element that PE1 needs to originate an mLDP message with a FEC element that
identifies ASBR1 as the root. This FEC element must contain enough identifies ASBR1 as the root. This FEC element must contain enough
information to enable ASBR1 to find the next hop towards PE2 even information to enable ASBR1 to find the next hop towards PE2 even
though ASBR1 does not have a route to PE2. though ASBR1 does not have a route to PE2.
Although ASBR1 does not have a route to PE2, it does have a BGP Although ASBR1 does not have a route to PE2, it does have a BGP
Intra-AS I-PMSI A-D route [MVPN] whose NLRI contains PE2's IP address Intra-AS Inclusive PMSI (I-PMSI) auto-discovery (A-D) route [MVPN]
together with a particular RD. PE1 also has this Inter-AS I-PMSI A-D whose Network Layer Reachability Information (NLRI) contains PE2's IP
route. The LSP needs to be set up along the path established by the address together with a particular RD. PE1 also has this Inter-AS
Intra-AS I-PMSI A-D routes. Therefore one must use a Recursive FEC I-PMSI A-D route. The LSP needs to be set up along the path
element that contains the RD as well as the as well as the address of established by the Intra-AS I-PMSI A-D routes. Therefore, one must
PE2. The "VPN-Recursive FEC Element" defined herein is used for this use a Recursive FEC element that contains the RD as well as the
purpose. address of PE2. The "VPN-Recursive FEC Element" defined herein is
used for this purpose.
This enables us to provide the same functionality, for mLDP P-tunnels This enables us to provide the same functionality for mLDP P-tunnels
that is provided for PIM P-tunnels in section 8.1.3.2 of [MVPN] that is provided for PIM P-tunnels in Section 8.1.3.2 of [MVPN]
through the use of the MVPN Join Attribute. through the use of the MVPN Join Attribute.
At PE1 in Figure 4, the LSP to be created is associated with a At PE1 in Figure 4, the LSP to be created is associated with a
particular VPN Routing/Forwarding Table (VRF). PE1 looks up in that particular VPN Routing and Forwarding Table (VRF). PE1 looks up in
VRF the Intra-AS I-PMSI A-D route originated by PE2. It finds that that VRF the Intra-AS I-PMSI A-D route originated by PE2. It finds
the BGP next hop of that route is ASBR1. So it creates a P2MP or that the BGP next hop of that route is ASBR1. So, it creates a P2MP
MP2MP FEC element whose root is ASBR1, and whose opaque value is a or MP2MP FEC element whose root is ASBR1 and whose opaque value is a
VPN-Recursive FEC element. The VPN-Recursive FEC element itself VPN-Recursive FEC element. The VPN-Recursive FEC element itself
consists of a root, an RD, and an opaque value, set as follows: consists of a root, an RD, and an opaque value, set as follows:
- The root is PE2 - The root is PE2.
- The RD is the RD from the NLRI of the Intra-AS A-D route - The RD is the RD from the NLRI of the Intra-AS A-D route
originated by PE2. originated by PE2.
- The opaque value is chosen (by some method outside the scope of - The opaque value is chosen (by some method outside the scope of
this document) so as to be unique in the context of PE2. (E.g., this document) so as to be unique in the context of PE2. (For
it may have been specified in a PMSI tunnel attribute originated example, it may have been specified in a PMSI Tunnel Attribute
by PE2.) We will refer to this opaque value as "Q". originated by PE2.) We will refer to this opaque value as "Q".
The resulting FEC element can be informally represented as The resulting FEC element can be informally represented as
<root=ASBR1, opaque_value=<root=PE2, RD, opaque_value=Q>>. <root=ASBR1, opaque_value=<root=PE2, RD, opaque_value=Q>>.
PE1 can now begin setting up the LSP by using this FEC element in an PE1 can now begin setting up the LSP by using this FEC element in an
LDP label mapping message sent towards ASBR1. LDP Label Mapping message sent towards ASBR1.
When ASBR1 receives, over a non-VRF interface, an mLDP label mapping When ASBR1 receives, over a non-VRF interface, an mLDP Label Mapping
message containing this FEC element, it sees that it is the root, and message containing this FEC element, it sees that it is the root and
that the opaque value is a VPN-Recursive Opaque Value. It parses the that the opaque value is a VPN-Recursive Opaque Value. It parses the
VPN-Recursive Opaque value and extracts the root value, PE2. VPN-Recursive Opaque value and extracts the root value, PE2.
If ASBR1 has a route to PE2, it continues setting up the LSP by using If ASBR1 has a route to PE2, it continues setting up the LSP by using
the following FEC element: the following FEC element:
<root=PE2, opaque_value=Q> <root=PE2, opaque_value=Q>
However, if ASBR1 does not have a route to PE2, it looks for an However, if ASBR1 does not have a route to PE2, it looks for an
Intra-AS I-PMSI A-D route whose NLRI contains PE2's address along Intra-AS I-PMSI A-D route whose NLRI contains PE2's address along
with the specified RD value. Say the BGP next hop of that route is with the specified RD value. Say the BGP next hop of that route is
ASBR2. Then ASBR1 continues setting up the LSP by using the ASBR2. Then ASBR1 continues setting up the LSP by using the
following FEC element: following FEC element:
<root=ASBR2, opaque_value=<root=PE2, RD, opaque_value=Q>>. <root=ASBR2, opaque_value=<root=PE2, RD, opaque_value=Q>>.
Note that in this case, the root has changed from ASBR1 to ASBR2, but Note that in this case, the root has changed from ASBR1 to ASBR2, but
the opaque value is the unchanged VPN-Recursive FEC element. the opaque value is the unchanged VPN-Recursive FEC element.
3.2.2. Limited Carrier's Carrier Function 3.2.2. Limited Carrier's Carrier Function
Another possible use of the VPN recursive FEC is to provide a limited Another possible use of the VPN-Recursive FEC is to provide a limited
version of "Carrier's Carrier Service". Referring again to the version of "Carrier's Carrier Service". Referring again to the
topology of Figure 2, suppose that PE1/PE2 are offering "Carrier's topology of Figure 2, suppose that PE1/PE2 are offering "Carrier's
Carrier VPN Service" [VPN] to CE1/CE2. CE1 sends PE1 an MP FEC Carrier VPN Service" [VPN] to CE1/CE2. CE1 sends PE1 an MP FEC
element whose root node is R, and whose opaque value is Q. We will element whose root node is R and whose opaque value is Q. We will
refer to this FEC element as "CE1-FEC". However, PE1's route to R refer to this FEC element as "CE1-FEC". However, PE1's route to R
will be in a VRF ("Virtual Routing and Forwarding Table"). Therefore will be in a VRF. Therefore, the FEC element created by PE1 must
the FEC-element created by PE1 must contain some identifier that PE2 contain some identifier that PE2 can use to find the proper VRF in
can use to find the proper VRF in which to look up the address of R. which to look up the address of R.
When PE1 looks up the address of R in a VRF, it will find a route in When PE1 looks up the address of R in a VRF, it will find a route in
the VPN-IP address family. The next hop will be PE2, but there will the VPN-IP address family. The next hop will be PE2, but there will
also be a Route Distinguisher (RD) as part of that NLRI of the also be a Route Distinguisher (RD) as part of that NLRI of the
matching route. In this case, the new FEC element created by PE1 has matching route. In this case, the new FEC element created by PE1 has
the address of PE2 as the root node address, and has a VPN-Recursive the address of PE2 as the root node address and has a VPN-Recursive
Opaque Value. The value field of the VPN-Recursive Opaque Value Opaque Value. The value field of the VPN-Recursive Opaque Value
consists of the 8-octet RD followed by CE1-FEC. consists of the 8-octet RD followed by CE1-FEC.
As far as the interior routers are concerned, they are being As far as the interior routers are concerned, they are being
requested to build a MP LSP whose root node is PE2. They MUST NOT requested to build an MP LSP whose root node is PE2. They MUST NOT
interpret the opaque value at all. interpret the opaque value at all.
When an mLDP label mapping message containing PE2-FEC arrives at PE2 When an mLDP Label Mapping message containing PE2-FEC arrives at PE2
over a VRF interface, PE2 notes that it is the identified root node, over a VRF interface, PE2 notes that it is the identified root node
and that the opaque value is a VPN-Recursive Opaque Value. Therefore and that the opaque value is a VPN-Recursive Opaque Value.
it MUST replace PE2-FEC with the contents of the VPN-Recursive Opaque Therefore, it MUST replace PE2-FEC with the contents of the
Value (i.e., with CE1-FEC) before doing any further processing. It VPN-Recursive Opaque Value (i.e., with CE1-FEC) before doing any
uses the VRF to lookup up the path to R. This will result in CE1-FEC further processing. It uses the VRF to look up the path to R. This
being sent on to CE2, and presumably further from CE2 to R. will result in CE1-FEC being sent on to CE2, and presumably further
from CE2 to R.
In this scenario, the RD in the VPN-Recursive Opaque Value also In this scenario, the RD in the VPN-Recursive Opaque Value also
ensures uniqueness of the FEC Element within the inner carrier's ensures uniqueness of the FEC element within the inner carrier's
network. network.
This way of providing Carrier's Carrier service has limited This way of providing Carrier's Carrier service has limited
applicability, as it only works under the following conditions: applicability, as it only works under the following conditions:
- Both the inner carrier and the outer carrier are using - Both the inner carrier and the outer carrier are using non-
non-segmented mLDP P-tunnels segmented mLDP P-tunnels.
- The inner carrier is not aggregating the P-tunnels of the outer - The inner carrier is not aggregating the P-tunnels of the outer
carrier, but is content to carry each such P-tunnel in a single carrier but is content to carry each such P-tunnel in a single
P-tunnel of its own. P-tunnel of its own.
The carrier's carrier scenario can be distinguished from the inter-AS The Carrier's Carrier scenario can be distinguished from the inter-AS
scenario by the fact that in the former, the mLDP messages are being scenario by the fact that in the former, the mLDP messages are being
exchanged on VRF interfaces. exchanged on VRF interfaces.
4. IANA Considerations 4. IANA Considerations
[mLDP] defines a registry for "The LDP MP Opaque Value Element Basic [mLDP] defines a registry for "The LDP MP Opaque Value Element Basic
Type". This document requires the assignment of two new code points Type". Two new code points have been assigned in this registry:
in this registry:
- Recursive Opaque Value: Type TBD (requested value: 7) - Recursive Opaque Value: Type 7
An opaque value of this type is itself a TLV that encodes an mLDP An opaque value of this type is itself a TLV that encodes an mLDP
FEC type, as defined in [mLDP]. FEC type, as defined in [mLDP].
- VPN-Recursive Opaque Value: Type TBD (requested value: 8) - VPN-Recursive Opaque Value: Type 8
An opaque value of this type consists of an eight-octet Route An opaque value of this type consists of an 8-octet Route
Distinguisher as defined in [VPN], followed by a TLV that encodes Distinguisher as defined in [VPN], followed by a TLV that encodes
an mLDP FEC type, as defined in [mLDP]. an mLDP FEC type, as defined in [mLDP].
5. Security Considerations 5. Security Considerations
The security considerations of [LDP] and [mLDP] apply. The security considerations of [LDP] and [mLDP] apply.
Unauthorized modification of the FEC elements defined in this Unauthorized modification of the FEC elements defined in this
document can disrupt the creation of the multipoint LSPs, or can document can disrupt the creation of the multipoint LSPs or can cause
cause the multipoint LSPs to pass through parts of the network where the multipoint LSPs to pass through parts of the network where they
they are not supposed to go. This could potentially be used as part are not supposed to go. This could potentially be used as part of an
of an attack to illegitimately insert or intercept multicast traffic. attack to illegitimately insert or intercept multicast traffic.
However, since the FEC elements defined in this document are not However, since the FEC elements defined in this document are not
inherently more vulnerable to this form of attack than are the inherently more vulnerable to this form of attack than are the
previously defined FEC elements, this document does not add new previously defined FEC elements, this document does not add new
security vulnerabilities. security vulnerabilities.
A description of general security issues for MPLS can be found in A description of general security issues for MPLS can be found in
[RFC5920]. [RFC5920].
6. Acknowledgments 6. Acknowledgments
The authors wish to thank Toerless Eckert for his contribution to The authors wish to thank Toerless Eckert for his contribution to
this work. this work.
7. Authors' Addresses 7. References
7.1. Normative References
[LDP] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, October 2007.
[mLDP] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
Thomas, "Label Distribution Protocol Extensions for Point-
to-Multipoint and Multipoint-to-Multipoint Label Switched
Paths", RFC 6388, November 2011.
[MVPN] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in
MPLS/BGP IP VPNs", RFC 6513, February 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[VPN] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
7.2. Informative References
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
Authors' Addresses
IJsbrand Wijnands IJsbrand Wijnands
Cisco Systems, Inc. Cisco Systems, Inc.
De kleetlaan 6a Diegem 1831 De kleetlaan 6a Diegem 1831
Belgium Belgium
E-mail: ice@cisco.com EMail: ice@cisco.com
Eric C. Rosen Eric C. Rosen
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA, 01719 Boxborough, MA 01719
E-mail: erosen@cisco.com EMail: erosen@cisco.com
Maria Napierala Maria Napierala
AT&T Labs AT&T Labs
200 Laurel Avenue, Middletown, NJ 07748 200 Laurel Avenue
E-mail: mnapierala@att.com Middletown, NJ 07748
EMail: mnapierala@att.com
Nicolai Leymann Nicolai Leymann
Deutsche Telekom Deutsche Telekom
Winterfeldtstrasse 21 Winterfeldtstrasse 21
Berlin 10781 Berlin 10781
Germany Germany
E-mail: n.leymann@telekom.de EMail: n.leymann@telekom.de
8. Normative References
[LDP] "LDP Specification", RFC 5036, Andersson, Minei, Thomas,
October 2007
[mLDP] "Label Distribution Protocol Extensions for Point-to-
Multipoint and Multipoint-to-Multipoint Label Switched Paths", Minei,
Kompella, Wijnands, Thomas, draft-ietf-mpls-ldp-p2mp-13.txt, April
2011
[MVPN] "Multicast in MPLS/BGP IP VPNs", Rosen, Aggarwal, et. al.,
draft-ietf-l3vpn-2547bis-mcast-10.txt, January 2009
[RFC2119] "Key words for use in RFCs to Indicate Requirement
Levels.", Bradner, March 1997
[VPN] "BGP/MPLS IP Virtual Private Networks (VPNs)", Rosen, Rekhter,
RFC 4364, February 2006
9. Informative References
[RFC5920] "Security Framework for MPLS and GMPLS Networks", L. Fang,
RFC 5920, July 2010
 End of changes. 89 change blocks. 
201 lines changed or deleted 216 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/