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/ |