draft-ietf-mpls-mldp-recurs-fec-02.txt   draft-ietf-mpls-mldp-recurs-fec-03.txt 
MPLS Working Group IJsbrand Wijnands MPLS Working Group IJsbrand Wijnands
Internet Draft Eric C. Rosen Internet Draft Eric C. Rosen
Intended Status: Proposed Standard Cisco Systems, Inc. Intended Status: Proposed Standard Cisco Systems, Inc.
Expires: November 9, 2011 Expires: December 23, 2011
Maria Napierala Maria Napierala
AT&T AT&T
Nicolai Leymann Nicolai Leymann
Deutsche Telekom Deutsche Telekom
May 9, 2011 June 23, 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-02.txt draft-ietf-mpls-mldp-recurs-fec-03.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, if the route to the root node is a BGP
route, and the intermediate nodes are part of a BGP-free core, this route, and the intermediate nodes are part of a BGP-free core, this
is not possible. This document specifies procedures which enable a is not possible. This document specifies procedures which enable a
skipping to change at page 3, line 4 skipping to change at page 2, line 41
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 Unsegmented Inter-AS P-tunnels ........................ 7 3.2.1 Unsegmented 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 ............................... 11
6 Acknowledgments ....................................... 11 6 Acknowledgments ....................................... 11
7 Authors' Addresses .................................... 11 7 Authors' Addresses .................................... 11
8 Normative References .................................. 12 8 Normative References .................................. 12
9 Informative References ................................ 12
1. Introduction 1. Introduction
[mLDP] defines several LDP "Forwarding Equivalence Class" (FEC) The document [mLDP] extends LDP ("Label Distribution Protocol",
element encodings: Point-to-Multipoint (P2MP), Multipoint-to- [LDP]) to support multipoint label-switched paths. These extensions
Multipoint (MP2MP) Upstream, and MP2MP Downstream. are known as "Multipoint LDP", or more simply as "mLDP". [mLDP]
defines several LDP "Forwarding Equivalence Class" (FEC) element
encodings: "Point-to-Multipoint" (P2MP), "Multipoint-to-Multipoint
(MP2MP) Upstream", and "MP2MP Downstream".
The encoding for these three FEC elements is shown in Figure 1. The encoding for these three FEC elements, as defined in [mLDP], is
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 | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
skipping to change at page 3, line 40 skipping to change at page 3, line 44
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 a MP LSP to pass through a part of the
network in which there is no route to the root node. For instance, network in which there is no route to the root node. For instance,
consider the topology of Figure 2: consider the topology of Figure 2.
CE1----PE1---P1---- ...----P2 ----PE2----CE2----R CE1----PE1---P1---- ...----P2 ----PE2----CE2----R
Figure 2 Figure 2
where CE1 and CE2 are "customer edge routers", PE1 and PE2 are In Figure 2, CE1 and CE2 are "customer edge routers", R is a customer
"provider edge routers", but the provider's core is "BGP-free". That router at the same VPN site as CE2, PE1 and PE2 are "provider edge
is, PE1 has a BGP-learned route for R, in which PE2 is the BGP next routers". Suppose that the provider's core is "BGP-free". That is,
hop. However, the provider's interior routers (such as P1 and P2) do PE1 has a BGP-learned route for R, in which PE2 is the BGP next hop.
not have any BGP-learned routes, and in particular do not have any However, the provider's interior routers (such as P1 and P2) do not
routes to R. have any BGP-learned routes, and in particular do not have any routes
to R.
In such an environment, data packets from CE1 address to R would get In such an environment, unicast data packets from CE1 addressed to R
encapsulated by PE1, tunneled to PE2, decapsulated by PE2, and would get encapsulated by PE1, tunneled to PE2, decapsulated by PE2,
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 a 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 a 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 PE1. However, PE1 cannot use this same FEC element to identify to PE1. However, PE1 cannot use this same FEC element to identify
skipping to change at page 6, line 5 skipping to change at page 6, line 10
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 MUST create a new MP FEC element, whose root node PE1 therefore creates a new MP FEC element, whose root node address
address is the address of PE2, and whose opaque value is a Recursive is the address of PE2, and whose opaque value is a Recursive Opaque
Opaque Value whose value field contains CE1-FEC. We refer to this Value whose value field contains CE1-FEC. We refer to this FEC
FEC element as PE2-FEC. PE1 then MUST send this FEC element to P1. element as PE2-FEC:
PE2-FEC = <root=PE2, opaque_value=CE1-FEC>, or 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.
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 a 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
presumably further from CE2 to R. Note that CE1-FEC will contain the further from CE2 to R. Note that CE1-FEC will contain the LSP root
LSP root node specified by CE1; the presumption is that PE2 has a node specified by CE1; the presumption is that PE2 has a route to
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 one-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
skipping to change at page 7, line 21 skipping to change at page 7, line 21
| Route Distinguisher (8 octets) +-+-+-+-+-+-+-+-+ | Route Distinguisher (8 octets) +-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ~ ~ ~
| P2MP or MP2MP FEC Element | | P2MP or MP2MP FEC Element |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VPN-Recursive Opaque Value VPN-Recursive Opaque Value
Figure 3 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 eight-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 VPN-
Recursive Opaque Value thus includes the 8 octets of RD plus the 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. Unsegmented Inter-AS P-tunnels 3.2.1. Unsegmented Inter-AS P-tunnels
Consider the Inter-AS VPN scenario depicted in Figure 4. Consider the Inter-AS VPN scenario depicted in Figure 5.
PE1 --- P1 ---- ASBR1 ... ASBR2 ---- P2 ---- PE2 PE1 --- P1 ---- ASBR1 ... ASBR2 ---- P2 ---- PE2
Figure 4 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 MVPN
policy is to instantiate PMSIs [MVPN] using mLDP, and that policy is to instantiate PMSIs [MVPN] using mLDP, and that
"unsegmented inter-AS P-tunnels" [MVPN] are being used. "unsegmented 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
skipping to change at page 9, line 38 skipping to change at page 9, line 38
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 ("Virtual Routing and Forwarding Table"). Therefore
the FEC-element created by PE1 must contain some identifier that PE2 the FEC-element created by PE1 must contain some identifier that PE2
can use to find the proper VRF in which to look up the address of R. can use to find the proper VRF in 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 matching route. In this case, the new FEC element created by PE1 has
MUST have the address of PE2 as the root node address, and MUST have the address of PE2 as the root node address, and has a VPN-Recursive
a VPN-Recursive Opaque Value. The value field of the VPN-Recursive Opaque Value. The value field of the VPN-Recursive Opaque Value
Opaque Value MUST consist 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 a 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. Therefore
it MUST replace PE2-FEC with the contents of the VPN-Recursive Opaque it MUST replace PE2-FEC with the contents of the VPN-Recursive Opaque
Value (i.e., with CE1-FEC) before doing any further processing. It Value (i.e., with CE1-FEC) before doing any further processing. It
skipping to change at page 11, line 19 skipping to change at page 11, line 19
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 he multipoint LSPs to pass through parts of the network where cause he multipoint LSPs to pass through parts of the network where
they are not supposed to go. This could potentially be used as part they are not supposed to go. This could potentially be used as part
of an attack to illegitimately insert or intercept multicast traffic. of an 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
[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. Authors' Addresses
IJsbrand Wijnands IJsbrand Wijnands
Cisco Systems, Inc. Cisco Systems, Inc.
De kleetlaan 6a Diegem 1831 De kleetlaan 6a Diegem 1831
skipping to change at page 12, line 18 skipping to change at page 12, line 18
Germany Germany
E-mail: n.leymann@telekom.de E-mail: n.leymann@telekom.de
8. Normative References 8. Normative References
[LDP] "LDP Specification", RFC 5036, Andersson, Minei, Thomas, [LDP] "LDP Specification", RFC 5036, Andersson, Minei, Thomas,
October 2007 October 2007
[mLDP] "Label Distribution Protocol Extensions for Point-to- [mLDP] "Label Distribution Protocol Extensions for Point-to-
Multipoint and Multipoint-to-Multipoint Label Switched Paths", Minei, Multipoint and Multipoint-to-Multipoint Label Switched Paths", Minei,
Kompella, Wijnands, Thomas, draft-ietf-mpls-ldp-p2mp-12.txt, February Kompella, Wijnands, Thomas, draft-ietf-mpls-ldp-p2mp-13.txt, April
2011 2011
[MVPN] "Multicast in MPLS/BGP IP VPNs", Rosen, Aggarwal, et. al., [MVPN] "Multicast in MPLS/BGP IP VPNs", Rosen, Aggarwal, et. al.,
draft-ietf-l3vpn-2547bis-mcast-10.txt, January 2009 draft-ietf-l3vpn-2547bis-mcast-10.txt, January 2009
[RFC2119] "Key words for use in RFCs to Indicate Requirement [RFC2119] "Key words for use in RFCs to Indicate Requirement
Levels.", Bradner, March 1997 Levels.", Bradner, March 1997
[VPN] "BGP/MPLS IP Virtual Private Networks (VPNs)", Rosen, Rekhter, [VPN] "BGP/MPLS IP Virtual Private Networks (VPNs)", Rosen, Rekhter,
RFC 4364, February 2006 RFC 4364, February 2006
9. Informative References
[RFC5920] "Security Framework for MPLS and GMPLS Networks", L. Fang,
RFC 5920, July 2010
 End of changes. 20 change blocks. 
33 lines changed or deleted 44 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/