idnits 2.17.1 draft-ietf-pwe3-mspw-er-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 10, 2014) is 3478 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Dutta 3 Internet-Draft M. Bocci 4 Intended status: Standards Track Alcatel-Lucent 5 Expires: March 14, 2015 L. Martini 6 Cisco Systems 7 September 10, 2014 9 Explicit Path Routing for Dynamic Multi-Segment Pseudowires 10 draft-ietf-pwe3-mspw-er-06 12 Abstract 14 Dynamic Multi-Segment Pseudowire (MS-PW) setup through an explicit 15 path may be required to provide a simple solution for 1:1 protection 16 with diverse primary and backup MS-PWs for a service, or to enable 17 controlled signaling (strict or loose) for special MS-PWs. This 18 document specifies the extensions and procedures required to enable 19 dynamic MS-PWs to be established along explicit paths. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on March 14, 2015. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Explicit Path in MS-PW Signaling . . . . . . . . . . . . . . 3 64 3.1. S-PE Addressing . . . . . . . . . . . . . . . . . . . . . 3 65 3.2. Explicit Route TLV (ER-TLV) . . . . . . . . . . . . . . . 3 66 3.3. Explicit Route Hop TLV (ER-Hop TLV) . . . . . . . . . . . 4 67 3.4. ER-Hop Semantics . . . . . . . . . . . . . . . . . . . . 4 68 3.4.1. ER-Hop Type: IPv4 Prefix . . . . . . . . . . . . . . 4 69 3.4.2. ER-Hop Type: IPv6 Prefix . . . . . . . . . . . . . . 4 70 3.4.3. ER-Hop Type: L2 PW Address . . . . . . . . . . . . . 4 71 4. Explicit Route TLV Processing . . . . . . . . . . . . . . . . 6 72 4.1. Next-Hop Selection . . . . . . . . . . . . . . . . . . . 6 73 4.2. Adding ER Hops to the Explicit Route TLV . . . . . . . . 7 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 77 8. Normative References . . . . . . . . . . . . . . . . . . . . 9 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 80 1. Introduction 82 Procedures for dynamically establishing multi-segment pseudowires 83 (MS-PWs), where their paths are automatically determined using a 84 dynamic routing protocol, are defined in [RFC7267]. For 1:1 85 protection of MS-PWs with primary and backup paths, MS-PWs need to be 86 established through a diverse set of S-PEs (Switching Provider-Edges) 87 to avoid any single points of failure at the PW level. [RFC7267] 88 allows this through BGP-based mechanisms. This document defines an 89 additional mechanism that allows the ST-PE (Source Terminating PEs) 90 to explicitly choose the path that a PW would take through the 91 intervening S-PEs. Explicit path routing of dynamic MS-PWs may also 92 be required for controlled set-up of dynamic MS-PWs and network 93 resource management. 95 Note that in many deployments the ST-PE will not have a view of the 96 topology of S-PEs and so the explicit route will need to be supplied 97 from a management application. How that management application 98 determines the explicit route is outside the scope of this document. 100 2. Terminology 102 This document uses the terminology defined in [RFC7267], [RFC4447]and 103 [RFC5036]. 105 The following additional terminology is used: 107 Abstract Node: A group of nodes (S-PEs) representing an explicit hop 108 along the path of an MS-PW. An abstract node is identified by an 109 IPv4, IPv6 or S-PE address. 111 3. Explicit Path in MS-PW Signaling 113 This section describes the LDP (Label Distribution Protocol) 114 extensions required for signaling explicit paths in dynamic MS-PW 115 set-up messages. An explicitly routed MS-PW is set up using a Label 116 Mapping message that carries an ordered list of the S-PEs which the 117 MS-PW is expected to traverse. The ordered list is encoded as a 118 series of Explicit Route (ER) Hop TLVs encoded in an ER-TLV that is 119 carried in a Label Mapping message. 121 3.1. S-PE Addressing 123 An S-PE address is used to identify a given S-PE among the set of 124 S-PEs belonging to the PSNs that may be used by an MS-PW. Each S-PE 125 MUST be assigned an address as specified in [RFC7267] Section 3.2. 126 An S-PE that is capable of dynamic MS-PW signaling, but has not been 127 assigned an S-PE address, and that receives a Label Mapping message 128 for a dynamic MS-PW MUST follow the procedures of [RFC7267] 129 Section 3.2. 131 3.2. Explicit Route TLV (ER-TLV) 133 The ER-TLV specifies the path to be taken by the MS-PW being 134 established. Each hop along the path is represented by an abstract 135 node, which is a group of one or more S-PEs, identified by an IPv4, 136 an IPv6 or an S-PE address. The ER-TLV format is as per Section 4.1 137 of [RFC3212]. 139 The ER-TLV contains one or more Explicit Route Hop TLVs (ER-Hop TLVs) 140 defined in Section 3.3. 142 3.3. Explicit Route Hop TLV (ER-Hop TLV) 144 The contents of an ER-TLV are a series of variable length ER-Hop 145 TLVs. Each hop contains the identification of an "Abstract Node" 146 that represents the hop to be traversed. The ER-Hop TLV format is as 147 specified in Section 4.2 of [RFC3212]. 149 [RFC3212] defines three ER-Hop TLV Types: IPv4 Prefix, IPv6 Prefix, 150 and Autonomous System. This document specifies the following new ER- 151 Hop TLV Type: 153 Value Type 154 ------ ------------------------ 155 0x0805 L2 PW address of PW Switching Point 157 ER-Hop TLV 159 Details of ER Hop semantics are defined in Section 3.4. 161 3.4. ER-Hop Semantics 163 This section describes the various semantics associated with ER-Hop 164 TLV. 166 3.4.1. ER-Hop Type: IPv4 Prefix 168 The semantics of the IPv4 ER-Hop TLV Type are specified in [RFC3212] 169 Section 4.7.1. 171 3.4.2. ER-Hop Type: IPv6 Prefix 173 The semantics of the IPv6 ER-Hop TLV Type are specified in [RFC3212] 174 Section 4.7.2. 176 3.4.3. ER-Hop Type: L2 PW Address 178 The semantics of the L2 PW Address ER-Hop TLV Type, which contains 179 the L2 PW Address derived from the Generalized PWid FEC AII type 2 180 defined in [RFC5003], are as follows. 182 0 1 2 3 183 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 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 |U|F| ER Hop Type | Length = 18 | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 |L| Reserved | PreLen | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | AII Type=02 | Length | Global ID | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Global ID (contd.) | Prefix | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Prefix (contd.) | AC ID | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | AC ID | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 U/F 199 These bits MUST be set to zero and the procedures of 200 [RFC5036] followed when the TLV is not known to the 201 receiving node. 203 Type 204 A fourteen-bit field carrying the value of the ER-Hop 3, 205 L2 PW Address, Value = TBD 207 Length 208 Specifies the length of the value field in bytes = 18. 210 L Bit 211 Set to indicate Loose hop. 212 Cleared to indicate a strict hop. 214 Reserved 215 Zero on transmission. Ignored on receipt. 217 PreLen 218 Prefix Length 1-96 (including the length of the Global ID, 219 Prefix and AC ID fields). 221 All other fields (AII Type, Length, Global ID, Prefix, and AC ID) 222 define the L2 PW Address and are to be set and interpreted as 223 defined in Section 3.2 of [RFC5003]. 225 4. Explicit Route TLV Processing 227 4.1. Next-Hop Selection 229 A PW Label Mapping Message containing an explicit route TLV specifies 230 the next hop for a given MS-PW path. Selection of this next hop by 231 the ST-PE or S-PE inserting the ER Hop TLV may involve a selection 232 from a set of possible alternatives. The mechanism for making a 233 selection from this set is implementation specific and is outside of 234 the scope of this document. The mechanism used to select a 235 particular path is also outside of the scope of this document, but 236 each node MUST determine a loop-free path if it is to signal the MS- 237 PW. [RFC6073] Section 7.6 provides a mechanism by which a node can 238 check that the path taken by an MS-PW does not include loops. 240 As noted in Section 1, in many deployments the ST-PE will not have a 241 view of the topology of S-PEs and so the path will need to be 242 supplied from a management application. 244 If a loop free path cannot be found by an ST-PE or S-PE, then a node 245 MUST NOT attempt to signal the MS-PW. For an S-PE, if it cannot 246 determine a loop free path, then the received Label Mapping MUST be 247 released with a status code of "PW Loop Detected" as per 248 Section 4.2.3 of [RFC7267]. 250 To determine the next hop for the MS-PW path, a node performs the 251 following steps. Note that these procedures assume that a valid S-PE 252 address has been assigned to the node, as per Section 3.1, above. 254 1. The node receiving the Label Mapping Message that contains an ER- 255 TLV MUST evaluate the first ER Hop. If the L bit is not set in 256 the first ER Hop and if the node is not part of the abstract node 257 described by the first ER Hop (i.e it does not lie within the 258 prefix as determined by the prefix length specified in the ER-Hop 259 TLV), it has received the message in error. Therefore, the node 260 MUST reply with a Label Release Message with a "Bad Initial ER 261 Hop Error" (0x04000004) status code. If the L bit is set and the 262 local node is not part of the abstract node described by the 263 first ER Hop, the node selects a next hop that is along the path 264 to the abstract node described by the first ER Hop. If there is 265 no ER-Hop TLV contained in the ER-TLV, the message is also in 266 error and the node SHOULD return a "Bad Explicit Routing TLV 267 Error" (0x04000001) status code in a Label Release Message sent 268 to upstream node. Note that this statement does not preclude a 269 Label mapping message with no ER-TLV. If a Label Mapping message 270 with no ER-TLV is received, then it MUST be processed as per 271 [RFC7267]. 273 2. If there are no further ER-Hop TLVs following the first ER-Hop 274 TLV, this indicates the end of the explicit route. The Explicit 275 Route TLV MUST be removed from the Label Mapping message. This 276 node may or may not be the end of the PW. Processing continues 277 as per Section 4.2, where a new explicit route TLV MAY be added 278 to the Label Mapping Message. 280 3. If a second ER Hop TLV does exist, and the node is also a part of 281 the abstract node described by the second ER-Hop, then the node 282 deletes the first ER-Hop and continues processing with step 2, 283 above. Note that this makes the second ER Hop into the first ER 284 Hop for the iteration for the next PW segment. 286 4. The node determines if it is topologically adjacent to the 287 abstract node described by the second ER Hop. That is, it is 288 directly connected to the next node by a PW control plane 289 adjacency. If so, the node selects a particular next hop which 290 is a member of the abstract node. The node then deletes the 291 first ER-Hop and continues processing as per Section 4.2, below. 293 5. Next, the node selects a next hop within the abstract node of the 294 first ER Hop that is along the path to the abstract node of the 295 second ER Hop. If no such path exists then there are two cases: 297 A. If the second ER Hop is a strict ER Hop, then there is an 298 error and the node MUST return a Label Release Message to 299 upstream node with "Bad Strict Node Error" (0x04000002) 300 status code. 302 B. Otherwise, if the second ER Hop is a loose ER Hop, then the 303 node selects any next hop that is along the path to the next 304 abstract node. If no path exists within the MPLS domain, 305 then there is an error, and the node MUST return a Label 306 Release Message to upstream node with "Bad Loose Node Error" 307 (0x04000003) status code. 309 6. Finally, the node replaces the first ER Hop with any ER Hop that 310 denotes an abstract node containing the next hop. This is 311 necessary so that when the explicit route is received by the next 312 hop, it will be accepted. 314 7. Progress the Label Mapping Message to the next hop. 316 4.2. Adding ER Hops to the Explicit Route TLV 318 After selecting a next hop, the node MAY alter the explicit route in 319 the following ways. 321 If, as part of executing the algorithm in Section 4.1, the explicit 322 route TLV is removed, the node MAY add a new explicit route TLV. 324 Otherwise, if the node is a member of the abstract node for the first 325 ER-Hop, then a series of ER Hops MAY be inserted before the First ER 326 Hop or the first ER Hop MAY be replaced. Each ER Hop in this series 327 MUST denote an abstract node that is a subset of the current abstract 328 node. 330 Alternately, if the first ER-Hop is a loose ER Hop, an arbitrary 331 series of ER Hops MAY be inserted prior to the first ER-Hop. 333 5. IANA Considerations 335 RFC5036 [RFC5036] defines the LDP TLV name space which is maintained 336 by IANA as "LDP TLV Registry". TLV types for the Explicit Route TLV, 337 IPv4 Prefix ER-Hop TLV, and the IPv6 Prefix ER-Hop TLV are already 338 defined in the LDP TLV Registry. 340 IANA is requested to assign a further code point from the IETF 341 consensus portion of this registry as follows: 343 TLV Type Value Reference 344 ------------------------------------ -------- --------- 345 L2 PW Address of Switching Point TBD This Document 347 A value of 0x0805 is requested. 349 6. Security Considerations 351 This document introduces no new security considerations over 352 [RFC5036], [RFC4447] and [RFC7267]. The security considerations 353 detailed in those documents apply to the protocol extensions 354 described in this RFC. 356 As with [RFC7267], it should be noted that the path selection 357 mechanisms specified in this document enable the network to 358 automatically select the S-PEs that are used to forward packets on 359 the MS-PW. Appropriate tools, such as the Virtual Circuit 360 Connectivity Verification (VCCV) trace mechanisms specified in 361 [RFC6073], can be used by an operator of the network to verify the 362 path taken by the MS-PW and therefore be satisfied that the path does 363 not represent an additional security risk. 365 7. Acknowledgements 367 The authors gratefully acknowledge the contribution of the 368 RFC3212[RFC3212] authors through the specification of TLVs, which are 369 reused by this document. The authors also gratefully acknowledge the 370 input of Lizhong Jin. 372 8. Normative References 374 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 375 Requirement Levels", BCP 14, RFC 2119, March 1997. 377 [RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, 378 L., Doolan, P., Worster, T., Feldman, N., Fredette, A., 379 Girish, M., Gray, E., Heinanen, J., Kilty, T., and A. 380 Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, 381 January 2002. 383 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 384 Heron, "Pseudowire Setup and Maintenance Using the Label 385 Distribution Protocol (LDP)", RFC 4447, April 2006. 387 [RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto, 388 "Attachment Individual Identifier (AII) Types for 389 Aggregation", RFC 5003, September 2007. 391 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 392 Specification", RFC 5036, October 2007. 394 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. 395 Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011. 397 [RFC7267] Martini, L., Bocci, M., and F. Balus, "Dynamic Placement 398 of Multi-Segment Pseudowires", RFC 7267, June 2014. 400 Authors' Addresses 402 Pranjal Kumar Dutta 403 Alcatel-Lucent 404 701 E Middlefield Road 405 Mountain View, California 94043 406 USA 408 Email: pranjal.dutta@alcatel-lucent.com 409 Matthew Bocci 410 Alcatel-Lucent 411 Voyager Place, Shoppenhangers Road 412 Maidenhead, Berks SL6 2PJ 413 UK 415 Email: matthew.bocci@alcatel-lucent.com 417 Luca Martini 418 Cisco Systems 419 9155 East Nichols Avenue, Suite 400 420 Englewood, Colorado 80112 421 USA 423 Email: lmartini@cisco.com