draft-ietf-mpls-mldp-recurs-fec-01.txt | draft-ietf-mpls-mldp-recurs-fec-02.txt | |||
---|---|---|---|---|
Network 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: October 4, 2011 | Expires: November 9, 2011 | |||
Maria Napierala | Maria Napierala | |||
AT&T | AT&T | |||
Nicolai Leymann | Nicolai Leymann | |||
Deutsche Telekom | Deutsche Telekom | |||
April 4, 2011 | May 9, 2011 | |||
Using mLDP through a Backbone where there is no Route to the Root | Using Multipoint LDP when the Backbone has no Route to the Root | |||
draft-ietf-mpls-mldp-recurs-fec-01.txt | draft-ietf-mpls-mldp-recurs-fec-02.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 | |||
MP LSP to be constructed through a BGP-free core. In these | MP LSP to be constructed through a BGP-free core. In these | |||
procedures, the root node address is temporarily replaced by an | procedures, the root node address is temporarily replaced by an | |||
address which is known to the intermediate nodes. | address that is known to the intermediate nodes and is on the path to | |||
the true root node. | ||||
Status of this Memo | Status of this Memo | |||
This Internet-Draft is submitted to IETF in full conformance with the | This Internet-Draft is submitted to IETF in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
skipping to change at page 2, line 28 | skipping to change at page 2, line 28 | |||
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 Type ....................... 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 MP FEC Element ...................... 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 | |||
1. Introduction | 1. Introduction | |||
[MLDP] defines several LDP FEC element encodings: P2MP, MP2MP | [mLDP] defines several LDP "Forwarding Equivalence Class" (FEC) | |||
Upstream, and MP2MP Downstream. | 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 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 | . | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | |||
~ ~ | ~ ~ | |||
| Opaque Value | | | Opaque Value | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
MLDP FEC Element Encoding | mLDP FEC Element Encoding | |||
Figure 1 | 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 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 | |||
skipping to change at page 4, line 12 | skipping to change at page 4, line 13 | |||
hop. However, the provider's interior routers (such as P1 and P2) do | hop. However, the provider's interior routers (such as P1 and P2) do | |||
not have any BGP-learned routes, and in particular do not have any | not have any BGP-learned routes, and in particular do not have any | |||
routes to R. | routes to R. | |||
In such an environment, data packets from CE1 address to R would get | In such an environment, data packets from CE1 address to R would get | |||
encapsulated by PE1, tunneled to PE2, decapsulated by PE2, and | encapsulated by PE1, tunneled to PE2, decapsulated by PE2, and | |||
forwarded to CE2. | 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 | |||
the LSP in the LDP messages it sends to P1, because P1 does not have | the LSP in the LDP messages it sends to P1, because P1 does not have | |||
a route to R. | a 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. What is needed is a method whereby: | R. 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 | 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, | |||
- PE2 can determine the original FEC element that CE1 passed to | - PE2 can determine the original FEC element that CE1 passed to | |||
PE1, so that PE2 can pass it on to CE2. | PE1, 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 "VPN Recursive Opaque Value". Whereas the | Section 3 defines a "Virtual Private Network (VPN) Recursive Opaque | |||
"Recursive Opaque Value" carries the original FEC, the "VPN Recursive | Value". Whereas the "Recursive Opaque Value" carries the original | |||
Opaque Value" carries the original FEC plus a Route Distinguisher | FEC, the "VPN Recursive Opaque Value" carries the original FEC plus a | |||
(RD). This has several possible uses in an L3VPN context. Details | Route Distinguisher (RD). This is applicable when MP LSPs are being | |||
are in section 3. | used to carry the multicast traffic of a VPN [MVPN]. Details are in | |||
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 Type | 2. The Recursive Opaque Value | |||
2.1. Encoding | 2.1. Encoding | |||
We define a new Opaque Value Type, the Recursive Opaque Value Type. | We define a new type of Opaque Value, the Recursive Opaque Value. | |||
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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Type = 6 | Length | | | | Type = TBD | Length | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | |||
~ ~ | ~ ~ | |||
| P2MP or MP2MP FEC Element | | | P2MP or MP2MP FEC Element | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Recursive Opaque Value Type | Recursive Opaque Value | |||
Figure 3 | Figure 3 | |||
The "opaque value" itself is a P2MP or MP2MP FEC element, encoded | The value field of the "Recursive Opaque Value" is itself is a P2MP | |||
exactly as specified in [MLDP], with a type field, a length field, | or MP2MP FEC element, encoded exactly as specified in [mLDP], with a | |||
and value field of is own. The length field of the Recursive Opaque | type field, a length field, and value field of its own. The length | |||
Value Type thus includes the type and length fields of the FEC | of the Recursive Opaque Value thus includes the lengths of the type, | |||
element that is the value field. | 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 MUST create a new MP FEC element, whose root node | PE1 therefore MUST create a new MP FEC element, whose root node | |||
address is the address of PE2, and whose opaque value is a Recursive | address is the address of PE2, and whose opaque value is a Recursive | |||
(type 6) Opaque Value whose value field contains CE1-FEC. We refer | Opaque Value whose value field contains CE1-FEC. We refer to this | |||
to this FEC element as PE2-FEC. PE1 then MUST send this FEC element | FEC element as PE2-FEC. PE1 then MUST send this FEC element to P1. | |||
to P1. | ||||
PE2-FEC = <root=PE2, opaque_value=CE1-FEC>, or | PE2-FEC = <root=PE2, opaque_value=CE1-FEC>, or | |||
PE2-FEC = <root=PE2, opaque_value=<root=R, | PE2-FEC = <root=PE2, opaque_value=<root=R, | |||
opaque_value=Q>> | opaque_value=Q>> | |||
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 is the identified root | When PE2-FEC arrives at PE2, PE2 notes that it (PE2) is the | |||
node, and that the opaque value is a Recursive (type 6) opaque value. | identified root node, and that the opaque value is a Recursive Opaque | |||
Therefore it MUST replace PE2-FEC with the contents of the type 6 | Value. Therefore PE2 MUST replace PE2-FEC with the contents of the | |||
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 | presumably 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 | LSP root node specified by CE1; the presumption is that PE2 has a | |||
route to this root node. | route to this root node. | |||
3. The VPN-Recursive MP FEC Element | 3. The VPN-Recursive Opaque Value | |||
3.1. Encoding | 3.1. Encoding | |||
We define a new Opaque Value Type, the VPN-Recursive Opaque Value | We define a new type of Opaque Value, the VPN-Recursive Opaque Value. | |||
Type. | 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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Type = 7 | Length | | | | Type = TBD | Length | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | |||
| | | | | | |||
| Route Distinguisher (8 octets) +-+-+-+-+-+-+-+-+ | | Route Distinguisher (8 octets) +-+-+-+-+-+-+-+-+ | |||
| | | | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | |||
~ ~ | ~ ~ | |||
| P2MP or MP2MP FEC Element | | | P2MP or MP2MP FEC Element | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
VPN-Recursive Opaque Value Type | VPN-Recursive Opaque Value | |||
Figure 3 | Figure 3 | |||
The "opaque value" consists of an eight-octet Route Distinguisher | The value field of the "VPN-Recursive Opaque Value" consists of an | |||
(RD), followed by a P2MP or MP2MP FEC element, encoded exactly as | eight-octet Route Distinguisher (RD), followed by a P2MP or MP2MP FEC | |||
specified in [MLDP], with a type field, a length field, and value | element, encoded exactly as specified in [mLDP], with a type field, a | |||
field of is own. The length field of the Recursive Opaque Value Type | length field, and value field of is own. The length of the VPN- | |||
thus includes the 8 octets of RD plus the type and length fields of | Recursive Opaque Value thus includes the 8 octets of RD plus the | |||
the FEC element that is the value field. | lengths of the type, length, and values fields of the contained FEC | |||
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 4. | |||
PE1 --- P1 ---- ASBR1 ... ASBR2 ---- P2 ---- PE2 | PE1 --- P1 ---- ASBR1 ... ASBR2 ---- P2 ---- PE2 | |||
Figure 4 | Figure 4 | |||
skipping to change at page 8, line 27 | skipping to change at page 8, line 27 | |||
Intra-AS I-PMSI A-D routes. Therefore one must use a Recursive FEC | Intra-AS I-PMSI A-D routes. Therefore one must use a Recursive FEC | |||
element that contains the RD as well as the as well as the address of | element that contains the RD as well as the as well as the address of | |||
PE2. The "VPN-Recursive FEC Element" defined herein is used for this | PE2. The "VPN-Recursive FEC Element" defined herein is used for this | |||
purpose. | 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] | |||
though the use of the MVPN Join Attribute. | though 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 VRF. PE1 looks up in that VRF the Intra-AS I-PMSI A-D | particular VPN Routing/Forwarding Table (VRF). PE1 looks up in that | |||
route originated by PE2. It finds that the BGP next hop of that | VRF the Intra-AS I-PMSI A-D route originated by PE2. It finds that | |||
route is ASBR1. So it creates a P2MP or MP2MP FEC element whose root | the BGP next hop of that route is ASBR1. So it creates a P2MP or | |||
is ASBR1, and whose opaque value is a VPN-Recursive FEC element. The | MP2MP FEC element whose root is ASBR1, and whose opaque value is a | |||
VPN-Recursive FEC element itself consists of a root, an RD, and an | VPN-Recursive FEC element. The VPN-Recursive FEC element itself | |||
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. (E.g., | |||
it may have been specified in a PMSI tunnel attribute originated | it may have been specified in a PMSI tunnel attribute originated | |||
by PE2.) We will refer to this opaque value as "Q". | 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 (type 7) FEC element. It | that the opaque value is a VPN-Recursive Opaque Value. It parses the | |||
parses the VPN-Recursive FEC element and extracts the root value, | VPN-Recursive Opaque value and extracts the root value, PE2. | |||
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 | |||
skipping to change at page 9, line 41 | skipping to change at page 9, line 40 | |||
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 | |||
MUST have the address of PE2 as the root node address, and MUST have | MUST have the address of PE2 as the root node address, and MUST have | |||
a VPN-Recursive (type 7) opaque value. The value field of the type 7 | a VPN-Recursive Opaque Value. The value field of the VPN-Recursive | |||
opaque value MUST consist of the 8-octet RD followed by CE1-FEC. | Opaque Value MUST consist 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 (type 7) opaque value. | and that the opaque value is a VPN-Recursive Opaque Value. Therefore | |||
Therefore it MUST replace PE2-FEC with the contents of the VPN- | it MUST replace PE2-FEC with the contents of the VPN-Recursive Opaque | |||
recursive opaque value (i.e., with CE1-FEC) before doing any further | Value (i.e., with CE1-FEC) before doing any further processing. It | |||
processing. It uses the VRF to lookup up the path to R. This will | uses the VRF to lookup up the path to R. This will result in CE1-FEC | |||
result in CE1-FEC being sent on to CE2, and presumably further from | being sent on to CE2, and presumably further from CE2 to R. | |||
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 | |||
unsegmented mLDP P-tunnels | unsegmented mLDP P-tunnels | |||
skipping to change at page 10, line 31 | skipping to change at page 10, line 29 | |||
- 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 Type". | [mLDP] defines a registry for "The LDP MP Opaque Value Element Basic | |||
This document requires the assignment of two new code points in this | Type". This document requires the assignment of two new code points | |||
registry: | in this registry: | |||
- Type 6. | - Recursive Opaque Value: Type TBD (requested value: 6) | |||
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]. | |||
- Type 7 | - VPN-Recursive Opaque Value: Type TBD (requested value: 7) | |||
An opaque value of this type consists of an eight-octet Route | An opaque value of this type consists of an eight-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 | |||
TBD | The security considerations of [LDP] and [mLDP] apply. | |||
Unauthorized modification of the FEC elements defined in this | ||||
document can disrupt the creation of the multipoint LSPs, or can | ||||
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 | ||||
of an attack to illegitimately insert or intercept multicast traffic. | ||||
However, since the FEC elements defined in this document are not | ||||
inherently more vulnerable to this form of attack than are the | ||||
previously defined FEC elements, this document does not add new | ||||
security vulnerabilities. | ||||
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. | |||
skipping to change at page 11, line 32 | skipping to change at page 12, line 4 | |||
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 | E-mail: erosen@cisco.com | |||
Maria Napierala | Maria Napierala | |||
AT&T Labs | AT&T Labs | |||
200 Laurel Avenue, Middletown, NJ 07748 | 200 Laurel Avenue, Middletown, NJ 07748 | |||
E-mail: mnapierala@att.com | E-mail: 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 | E-mail: n.leymann@telekom.de | |||
8. Normative References | 8. Normative References | |||
[MLDP] "Label Distribution Protocol Extensions for Point-to- | [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, | 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-12.txt, February | |||
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 | |||
End of changes. 39 change blocks. | ||||
75 lines changed or deleted | 89 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/ |