--- 1/draft-ietf-mpls-mldp-recurs-fec-02.txt 2011-06-23 20:15:39.000000000 +0200 +++ 2/draft-ietf-mpls-mldp-recurs-fec-03.txt 2011-06-23 20:15:39.000000000 +0200 @@ -1,26 +1,26 @@ MPLS Working Group IJsbrand Wijnands Internet Draft Eric C. Rosen Intended Status: Proposed Standard Cisco Systems, Inc. -Expires: November 9, 2011 +Expires: December 23, 2011 Maria Napierala AT&T Nicolai Leymann Deutsche Telekom - May 9, 2011 + June 23, 2011 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 The control protocol used for constructing Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths ("MP LSPs") contains a field that identifies the address of a "root node". Intermediate 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 route, and the intermediate nodes are part of a BGP-free core, this is not possible. This document specifies procedures which enable a @@ -73,28 +73,33 @@ 3 The VPN-Recursive Opaque Value ........................ 6 3.1 Encoding .............................................. 6 3.2 Procedures ............................................ 7 3.2.1 Unsegmented Inter-AS P-tunnels ........................ 7 3.2.2 Limited Carrier's Carrier Function .................... 9 4 IANA Considerations ................................... 10 5 Security Considerations ............................... 11 6 Acknowledgments ....................................... 11 7 Authors' Addresses .................................... 11 8 Normative References .................................. 12 + 9 Informative References ................................ 12 1. Introduction - [mLDP] defines several LDP "Forwarding Equivalence Class" (FEC) - element encodings: Point-to-Multipoint (P2MP), Multipoint-to- - Multipoint (MP2MP) Upstream, and MP2MP Downstream. + The document [mLDP] extends LDP ("Label Distribution Protocol", + [LDP]) to support multipoint label-switched paths. These extensions + 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 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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Root Node Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque Length | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + @@ -109,36 +114,37 @@ Note that a P2MP or MP2MP label switched path ("MP LSP") is 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 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 the root node. 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, - consider the topology of Figure 2: + consider the topology of Figure 2. CE1----PE1---P1---- ...----P2 ----PE2----CE2----R Figure 2 - where CE1 and CE2 are "customer edge routers", PE1 and PE2 are - "provider edge routers", but the provider's core is "BGP-free". That - is, PE1 has a BGP-learned route for R, in which PE2 is the BGP next - 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 - routes to R. + 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 + routers". Suppose that the provider's core is "BGP-free". That is, + PE1 has a BGP-learned route for R, in which PE2 is the BGP next 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 routes + to R. - In such an environment, data packets from CE1 address to R would get - encapsulated by PE1, tunneled to PE2, decapsulated by PE2, and - forwarded to CE2. + In such an environment, unicast data packets from CE1 addressed to R + would get encapsulated by PE1, tunneled to PE2, decapsulated by PE2, + and forwarded to CE2. 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 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 PE2, from PE2 to CE2, and from CE2 to R. 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 to PE1. However, PE1 cannot use this same FEC element to identify @@ -212,42 +218,44 @@ will refer to this FEC element as "CE1-FEC". We may think of CE1-FEC as an ordered pair, as follows: CE1-FEC = . 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 interior routers on the path to PE2 are "BGP-free", and thus have no route to R. - 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 - Opaque Value whose value field contains CE1-FEC. We refer to this - FEC element as PE2-FEC. PE1 then MUST send this FEC element to P1. + 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 + Value whose value field contains CE1-FEC. We refer to this FEC + element as PE2-FEC: - PE2-FEC = , or + PE2-FEC = , i.e., PE2-FEC = > + PE1 then sends this FEC element to P1. + 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 interpret the opaque value at all. 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 Value. Therefore PE2 MUST replace PE2-FEC with the contents of the 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 - 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 - route to this root node. + 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 + this root node. 3. The VPN-Recursive Opaque Value 3.1. Encoding 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. 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 @@ -258,39 +266,39 @@ | Route Distinguisher (8 octets) +-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ | P2MP or MP2MP FEC Element | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ VPN-Recursive Opaque Value - Figure 3 + Figure 4 The value field of the "VPN-Recursive Opaque Value" consists of an eight-octet Route Distinguisher (RD), followed by a P2MP or MP2MP FEC 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- Recursive Opaque Value thus includes the 8 octets of RD plus the lengths of the type, length, and values fields of the contained FEC element. 3.2. Procedures 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 - Figure 4 + Figure 5 Suppose this is an "option B" VPN interconnect ([VPN] section 10). This means that the Autonomous System Border Router (ASBR) in the 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 policy is to instantiate PMSIs [MVPN] using mLDP, and that "unsegmented inter-AS P-tunnels" [MVPN] are being used. 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 @@ -367,24 +375,24 @@ 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 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 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. 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 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 - MUST have the address of PE2 as the root node address, and MUST have - 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. + 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 + Opaque Value. The value field of the VPN-Recursive Opaque Value + consists of the 8-octet RD followed by CE1-FEC. 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 interpret the opaque value at all. 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, 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 Value (i.e., with CE1-FEC) before doing any further processing. It @@ -433,20 +441,23 @@ 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. + A description of general security issues for MPLS can be found in + [RFC5920]. + 6. Acknowledgments The authors wish to thank Toerless Eckert for his contribution to this work. 7. Authors' Addresses IJsbrand Wijnands Cisco Systems, Inc. De kleetlaan 6a Diegem 1831 @@ -470,21 +481,26 @@ Germany E-mail: 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-12.txt, February + 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