idnits 2.17.1 draft-xiong-pce-pcep-extension-sr-tp-03.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2019) is 1844 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) == Outdated reference: A later version (-14) exists of draft-ietf-pce-association-bidir-02 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-stateful-pce-gmpls-10 == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-00 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE WG Quan Xiong 3 Internet-Draft Shuangping Zhan 4 Intended status: Standards Track ZTE Corporation 5 Expires: September 12, 2019 Fangwei Hu 6 Individual 7 March 11, 2019 9 PCEP extensions for SR-MPLS-TP 10 draft-xiong-pce-pcep-extension-sr-tp-03 12 Abstract 14 This document proposes a set of extensions to PCEP for Transport 15 Profile of SR-MPLS (SR-MPLS-TP) networks and defines a mechanism to 16 create the bi-directional SR tunnel with PCE. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 12, 2019. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 54 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. The SR-MPLS-TP Architecture with PCE . . . . . . . . . . . . 3 56 2.1. SR Path SID Allocation . . . . . . . . . . . . . . . . . 5 57 2.2. Associated Bi-directional SR tunnel . . . . . . . . . . . 6 58 3. PCEP extensions for SR-MPLS-TP . . . . . . . . . . . . . . . 7 59 3.1. ERO extension . . . . . . . . . . . . . . . . . . . . . . 8 60 3.2. E bit in LSP object . . . . . . . . . . . . . . . . . . . 9 61 3.3. Processing Rules . . . . . . . . . . . . . . . . . . . . 9 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 65 7. Normative References . . . . . . . . . . . . . . . . . . . . 10 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 68 1. Introduction 70 The Path Computation Element Communication Protocol (PCEP) defined in 71 [RFC5440] provides mechanisms for Path Computation Elements (PCEs) to 72 perform path computations in response to Path Computation Clients 73 (PCCs) requests. 75 [I-D.ietf-pce-segment-routing] proposes extensions to PCEP that allow 76 a stateful PCE to compute Traffic Engineering (TE) paths in segment 77 routing (SR) networks. But it is applicable to Multi-protocol Label 78 Switching (MPLS) networks refered as to SR-MPLS. In the context of 79 the Transport Profile of SR-MPLS, referred to in this document as SR- 80 MPLS-TP, a Path Segment uniquely identifies an SR path in a specific 81 context. It is required to extend the PCEP protocol to meet the new 82 requirements for SR-MPLS-TP services. One of the requirements is the 83 bidirectional SR tunnel described in 84 [I-D.ietf-spring-mpls-path-segment]. 86 This document proposes a set of extensions to PCEP for SR-MPLS-TP 87 networks and defines a mechanism to create the bidirectional SR 88 tunnel with PCE. 90 1.1. Requirements Language 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 1.2. Terminology 98 The terminology is defined as [RFC5440], 99 [I-D.ietf-pce-segment-routing] and 100 [I-D.ietf-spring-mpls-path-segment]. 102 MPLS-TP: MPLS transport profile. 104 SR: Segment Routing. 106 SR-MPLS: Segment routing over MPLS data plane. 108 SR-MPLS-TP: Transport Profile of SR-MPLS. 110 2. The SR-MPLS-TP Architecture with PCE 112 As described in [I-D.ietf-spring-mpls-path-segment], in transport 113 networks, the centralized controller may calculate the end to end SR 114 paths, and creates the ordered segment list. The centralized 115 controller may be replaced to PCE as the Figure 1 shown. The PCE can 116 calculate the SR paths and a SR path can be initiated by PCE or PCC. 118 | 119 | 120 V 121 +---+--+ 122 +--------------+ PCE +---------------+ 123 | +---+--+ | 124 +-------|-------------------------------------|--------+ 125 | | SR network | | 126 | | | | 127 | +---+--+ +---+--+ +---+--+ | 128 | | A +-----------+ B +-----------+ C + | 129 | +------+ +------+ +------+ | 130 | | 131 +------------------------------------------------------+ 133 Ingress Node: Egress Node: 135 Reverse Path Label Forward Path Label 136 (Incoming Label) (Outgoing Label) 138 SR Label Stacks: 140 +--------------------+ +--------------------+ 141 | Label A | | Label C | 142 +--------------------+ +--------------------+ 143 | ... | | ... | 144 +--------------------+ +--------------------+ 145 | Label C | | Label A | 146 +--------------------+ +--------------------+ 147 | Forward Path Label | | Reverse Path Label | 148 +--------------------+ +--------------------+ 150 Figure 1 The SR-MPLS-TP Architecture with PCE 152 It is required to support bidirectional SR tunnel to meet the 153 requirement of SR-MPLS-TP networks. A label named path segment at 154 both ends of the paths was defined to identify the direction of the 155 SR paths as defined in [I-D.ietf-spring-mpls-path-segment]. It 156 mainly aims to bind two unidirectional SR paths to a single 157 bidirectional tunnel. 159 As the Figure 1 shown, the forward and reverse directions of the 160 bidirectional SR tunnel are identified by the forward and reverse 161 path label respectively. For the ingress node, the forward path 162 label shall be added to the bottom of the label stack and the reverse 163 path label shall be configured to the data plane as incoming label 164 for the SR LSP. And for the egress node, the reverse path label need 165 to be the last one label of the label stack and the forward path 166 label shall be used as outgoing label. 168 2.1. SR Path SID Allocation 170 [RFC8402] defined the IGP, BGP, and Binding segments for the SR-MPLS 171 and SRv6 data planes which can be referred as to Segment Identifier 172 (SID). And [I-D.ietf-spring-mpls-path-segment] defined a new type of 173 segment named path segment. So the path segment can also be 174 identified by SID called SR path SID. The path segment may be 175 associated with a unidirectional path. 177 The path SID allocation includes ingress PCC allocated, egress PCC 178 allocated and PCE allocated in the domain. In case of egress PCC 179 allocated, the ingress PCC needs to comunicate with PCE to send path 180 segment request to egress PCC as the Figure 2 shown. When the 181 ingress PCC requests PCE to compute the SR path with PCReq message, 182 the PCE needs to request egress PCC to allocate the path SID with the 183 PCUpd or PCInit message carrying the Tunnel 1 and LSP 1. The egress 184 PCC needs to identify the allocation function from the initiation 185 message and should not return back PCErr message when checking the 186 local address is not equal with the source address of Tunnel 1. This 187 document defines E bit in section 3.2 carried in LSP object to 188 indicate the egress PCC operation which may not trigger the LSP 189 initiation. 191 When the path SID is allocated by ingress PCC, it need to inform PCE 192 with the PCRpt message and the latter one sends the notification to 193 egress PCC with PCUpd or PCInit message carried LSP object which set 194 the E bit to 1. 196 When the path SID is allocated by PCE, it need to inform ingress and 197 egress PCC with PCUpd or PCInit message carrying the Tunnel 1 and LSP 198 1. But the message sent to egress PCC MUST set the E bit to 1 to 199 avoid triggering the LSP initiation. 201 +------+ 202 | PCE | 203 +------+ 204 PCReq ^ \ PCUpd/PCInit 205 Tunnel 1 / \ Tunnel 1 206 LSP1 / \ LSP1, E=1 207 / v 208 +--------+ LSP1 +-------+ 209 |Ingress |----------->|Egress | 210 |PCC |<-----------|PCC | 211 +--------+ LSP2 +-------+ 213 Figure 2 The path SID allocation with PCE 215 2.2. Associated Bi-directional SR tunnel 217 As [RFC5654] defined, MPLS-TP MUST support unidirectional, co-routed 218 bidirectional, and associated bidirectional point-to-point transport 219 paths. As [RFC8402] defined, segment routing leverages the source 220 routing paradigm and the sourse node steers a packet through an 221 ordered segment list along a unidirectional path. So for 222 bidirectional SR tunnel, the forward and backward directional paths 223 may be setup by the source node and destination node seperately. 225 As described in [I-D.ietf-pce-association-bidir], two reverse 226 unidirectional LSPs can be associated as an associated bidirectional 227 tunnel which can be initialed by single-sided and double-sided 228 methods. Based on the discussion above, the associated bidirectional 229 SR tunnel can only be provisioned on both ingress and egress node 230 (PCCs). 232 The Single-sided initiation can be initiated by ingress SR node and 233 initiate two unidirectional LSPs to headend SR nodes as shown in 234 Figure 3. The Double-sided initiation can be initiated by PCCs or 235 PCE as shown in Figure 4 and 5 respectively. The forward and reverse 236 directional paths can be co-routed or non-corouted. The SR 237 bidirectional tunnel may follow the same path in the forward and 238 reverse directions and initiated as a co-routed associated 239 bidirectional LSP. When the PCE initiated the LSP, the B flag need 240 to be set to indicate a bi-directional LSP as defined in 241 [I-D.ietf-pce-pcep-stateful-pce-gmpls]. 243 +---------+ 244 | PCE | 245 +---------+ 246 1,PCReq ^ /2,PCInit\ 2,PCInit 247 Tunnel 1 / / Tunnel 1 \ Tunnel 1 248 / / LSP1 \ LSP2 249 / v v 250 +--------+ LSP1 +-------+ 251 |Ingress |----------->|Egress | 252 |PCC |<-----------|PCC | 253 +--------+ LSP2 +-------+ 255 Figure 3 PCC-initiated Single-sided Associated Bi-directional LSPs 257 +---------+ 258 | PCE | 259 +---------+ 260 1,PCReq ^ /2,PCInit \ ^ 1,PCReq 261 Tunnel 1 / / Tunnel 1 \ \ Tunnel 1 262 LSP1 / / LSP1/LSP2 \ \ LSP2 263 / v v \ 264 +--------+ LSP1 +-------+ 265 |Ingress |----------->|Egress | 266 |PCC |<-----------|PCC | 267 +--------+ LSP2 +-------+ 269 Figure 4 PCC-initiated Double-sided Associated Bi-directional LSPs 271 +---------+ 272 | PCE | 273 +---------+ 274 PCInit / \ PCInit 275 Tunnel 1 / \ Tunnel 1 276 LSP1 / \ LSP2 277 v v 278 +--------+ LSP1 +-------+ 279 |Ingress |----------->|Egress | 280 |PCC |<-----------|PCC | 281 +--------+ LSP2 +-------+ 283 Figure 5 PCE-initiated Double-sided Associated Bi-directional LSPs 285 3. PCEP extensions for SR-MPLS-TP 286 3.1. ERO extension 288 As described in [I-D.ietf-spring-mpls-path-segment], it is required 289 to support bi-directional tunnel to meet the requirement of SR 290 networks. But it is the uni-directional tunnel for SR and 291 engineering traffic network as discussed in 292 [I-D.ietf-pce-segment-routing]. The SR path is carried in the 293 Segment Routing Explicit Route Object (SR-ERO), which consists of a 294 sequence of SR subobjects. This document proposes the extension of 295 the SR-ERO Subobject to carry the bi-directional tunnel information 296 as the Figure 6 shown. The subobjects with path SIDs need to be 297 added to the list of the SR-ERO subobjects. 299 0 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 |L| Type | Length | NT | Flags |R|F|S|C|M| 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | SID | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 // NAI(variable,optional) // 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Figure 6 Extension of SR-ERO Subobject format 311 NAI Type (NT) : A new type of NT = 6 is added in this document and it 312 indicates the type and format of the NAI associated with the path SID 313 contained in the object body. When NT is set to 6, the format of NAI 314 field is shown as Figure 7. 316 R (Reverse Flag -- 1 bit): indicates the SR path direction, when it 317 is clear, it indicates the forward direction and when it is set, it 318 indicates the reverse direction. 320 The definition of other fields is the same with 321 [I-D.ietf-pce-segment-routing]. 323 0 1 2 3 324 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 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Path Label | TC |S| TTL | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 Figure 7 NAI for Path Label information 330 The format of Path Label information is specified as 331 [I-D.ietf-spring-mpls-path-segment]. 333 3.2. E bit in LSP object 335 The LSP object is defined in [RFC8231]. This document proposes the E 336 bit in flag field of the LSP object as shown in Figure 8: 338 E (Egress PCC Operation bit): If the bit is set to 1, it indicates 339 that the egress PCC operation with PCUpd or PCInit message and no 340 need to trigger the LSP initiation. A PCE would set the bit to 1 in 341 SR network to request or inform the path SID information. 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | PLSP-ID | Flag |E| 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 // TLVs // 349 | | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 Figure 8 The extension of LSP object 353 3.3. Processing Rules 355 As discussed in [I-D.ietf-spring-mpls-path-segment], the bi- 356 directional SR tunnel is created from two binding unidirectional SR 357 paths. As defined in [RFC8281], the stateful PCE calculates the SR 358 paths and initiates the bi-directional LSP with PCUpd or PCInit 359 message. 361 The B bit in SRP Object MUST be set and the two unidirectional SR 362 paths may be computed from the forward and reverse direction and sent 363 to the source and destination PCC respectively in SR-ERO object. The 364 path labels which binding the paths may be generated in PCE and sent 365 to the related PCC carried in the bottom of the SR-ERO. When the 366 PCCs at both ends receiving the PCInit message with the labels in SR- 367 ERO subobjects, they may forward the packets from bi-directional 368 tunnel in MPLS-TP networks. 370 4. Security Considerations 372 TBD. 374 5. IANA Considerations 376 TBD. 378 6. Acknowledgements 380 TBD. 382 7. Normative References 384 [I-D.ietf-pce-association-bidir] 385 Barth, C., Gandhi, R., and B. Wen, "PCEP Extensions for 386 Associated Bidirectional Label Switched Paths (LSPs)", 387 draft-ietf-pce-association-bidir-02 (work in progress), 388 November 2018. 390 [I-D.ietf-pce-pcep-stateful-pce-gmpls] 391 Lee, Y., Zhang, F., Casellas, R., Dios, O., and Z. Ali, 392 "Path Computation Element (PCE) Protocol Extensions for 393 Stateful PCE Usage in GMPLS-controlled Networks", draft- 394 ietf-pce-pcep-stateful-pce-gmpls-10 (work in progress), 395 March 2019. 397 [I-D.ietf-pce-segment-routing] 398 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 399 and J. Hardwick, "PCEP Extensions for Segment Routing", 400 draft-ietf-pce-segment-routing-16 (work in progress), 401 March 2019. 403 [I-D.ietf-spring-mpls-path-segment] 404 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 405 "Path Segment in MPLS Based Segment Routing Network", 406 draft-ietf-spring-mpls-path-segment-00 (work in progress), 407 March 2019. 409 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 410 Requirement Levels", BCP 14, RFC 2119, 411 DOI 10.17487/RFC2119, March 1997, 412 . 414 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 415 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 416 DOI 10.17487/RFC5440, March 2009, 417 . 419 [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., 420 Sprecher, N., and S. Ueno, "Requirements of an MPLS 421 Transport Profile", RFC 5654, DOI 10.17487/RFC5654, 422 September 2009, . 424 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 425 Computation Element Communication Protocol (PCEP) 426 Extensions for Stateful PCE", RFC 8231, 427 DOI 10.17487/RFC8231, September 2017, 428 . 430 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 431 Computation Element Communication Protocol (PCEP) 432 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 433 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 434 . 436 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 437 Decraene, B., Litkowski, S., and R. Shakir, "Segment 438 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 439 July 2018, . 441 Authors' Addresses 443 Quan Xiong 444 ZTE Corporation 445 No.6 Huashi Park Rd 446 Wuhan, Hubei 430223 447 China 449 Phone: +86 27 83531060 450 Email: xiong.quan@zte.com.cn 452 Shuangping Zhan 453 ZTE Corporation 454 Liuxian Rd 455 Shenzhen 518057 456 China 458 Phone: +86 755 26773770 459 Email: zhan.shuangping@zte.com.cn 461 Fangwei Hu 462 Individual 464 Email: hufwei@gmail.com