idnits 2.17.1 draft-xiong-pce-pcep-extension-sr-tp-02.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 (October 22, 2018) is 2005 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-01 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-14 Summary: 1 error (**), 0 flaws (~~), 3 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 Fangwei Hu 4 Intended status: Standards Track Shuangping Zhan 5 Expires: April 25, 2019 ZTE Corporation 6 October 22, 2018 8 PCEP extensions for SR MPLS-TP 9 draft-xiong-pce-pcep-extension-sr-tp-02 11 Abstract 13 This document proposes a set of extensions to PCEP for Segment 14 Routing in MPLS Transport Profile (MPLS-TP) networks and defines a 15 mechanism to create the bi-directional SR tunnel in SR networks with 16 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 April 25, 2019. 35 Copyright Notice 37 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . 4 57 2.2. Associated Bi-directional SR tunnel . . . . . . . . . . . 5 58 3. PCEP extensions for SR MPLS-TP . . . . . . . . . . . . . . . 6 59 3.1. ERO extension . . . . . . . . . . . . . . . . . . . . . . 6 60 3.2. E bit in LSP object . . . . . . . . . . . . . . . . . . . 7 61 3.3. Processing Rules . . . . . . . . . . . . . . . . . . . . 7 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 7.1. Informative References . . . . . . . . . . . . . . . . . 8 67 7.2. Normative References . . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 The Path Computation Element Communication Protocol (PCEP) defined in 73 [RFC5440] provides mechanisms for Path Computation Elements (PCEs) to 74 perform path computations in response to Path Computation Clients 75 (PCCs) requests. 77 [I-D.ietf-pce-segment-routing] proposes extensions to PCEP that allow 78 a stateful PCE to compute Traffic Engineering (TE) paths in segment 79 routing (SR) networks. But it is applicable to Multi-protocol Label 80 Switching (MPLS) networks. [I-D.hu-spring-sr-tp-use-case] describes 81 the use case of SR tunnel to be deployed in MPLS Transport Profile 82 (MPLS-TP) network. It is required to extend the PCEP protocol to 83 meet the new requirements for SR MPLS-TP services. One of the 84 requirements is the bidirectional SR tunnel described in 85 [I-D.cheng-spring-mpls-path-segment]. 87 This document proposes a set of extensions to PCEP for Segment 88 Routing in MPLS Transport Profile networks and defines a mechanism to 89 create the bidirectional SR tunnel in SR networks with PCE. 91 1.1. Requirements Language 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 1.2. Terminology 99 The terminology is defined as [RFC5440], 100 [I-D.ietf-pce-segment-routing] , [I-D.cheng-spring-mpls-path-segment] 101 and [I-D.hu-spring-sr-tp-use-case]. 103 2. The SR MPLS-TP Architecture with PCE 105 As described in [I-D.hu-spring-sr-tp-use-case], in MPLS-TP networks, 106 the centralized controller may calculate the end to end SR paths, and 107 creates the ordered segment list. The centralized controller may be 108 replaced to PCE as the Figure 1 shown. The PCE can calculate the SR 109 paths and a SR path can be initiated by PCE or PCC. 111 | 112 | 113 V 114 +---+--+ 115 +--------------+ PCE +---------------+ 116 | +---+--+ | 117 +-------|-------------------------------------|--------+ 118 | | SR network | | 119 | | | | 120 | +---+--+ +---+--+ +---+--+ | 121 | | A +-----------+ B +-----------+ C + | 122 | +------+ +------+ +------+ | 123 | | 124 +------------------------------------------------------+ 126 Ingress Node: Egress Node: 128 Reverse Path Label Forward Path Label 129 (Incoming Label) (Outgoing Label) 131 SR Label Stacks: 133 +--------------------+ +--------------------+ 134 | Label A | | Label C | 135 +--------------------+ +--------------------+ 136 | ... | | ... | 137 +--------------------+ +--------------------+ 138 | Label C | | Label A | 139 +--------------------+ +--------------------+ 140 | Forward Path Label | | Reverse Path Label | 141 +--------------------+ +--------------------+ 143 Figure 1 The SR MPLS-TP Architecture with PCE 145 It is required to support bidirectional SR tunnel to meet the 146 requirement of MPLS-TP networks. A label named path segment at both 147 ends of the paths was defined to identify the direction of the SR 148 paths as defined in [I-D.cheng-spring-mpls-path-segment]. It mainly 149 aims to bind two unidirectional SR paths to a single bidirectional 150 tunnel. 152 As the Figure 1 shown, the forward and backward directions of the 153 bidirectional SR tunnel are identified by the forward and reverse 154 path label respectively. For the ingress node, the forward path 155 label shall be added to the bottom of the label stack and the reverse 156 path label shall be configured to the data plane as incoming label 157 for the SR LSP. And for the egress node, the reverse path label need 158 to be the last one label of the label stack and the forward path 159 label shall be used as outgoing label. 161 2.1. SR Path SID Allocation 163 [RFC8402] defined the IGP, BGP, and Binding segments for the SR-MPLS 164 and SRv6 data planes which can be referred to by Segment Identifier 165 (SID). And [I-D.cheng-spring-mpls-path-segment] defined a new type 166 of segment named path segment. So the path segment can also be 167 identified by SID called SR path SID. The path segment may be 168 associated with a unidirectional path. 170 The path SID allocation includes ingress PCC allocated, egress PCC 171 allocated and PCE allocated in the domain. In case of egress PCC 172 allocated, the ingress PCC needs to comunicate with PCE to send path 173 segment request to egress PCC as the Figure 2 shown. When the 174 ingress PCC requests PCE to compute the SR path with PCReq message, 175 the PCE needs to request egress PCC to allocate the path SID with the 176 PCUpd or PCInit message carrying the Tunnel 1 and LSP 1. The egress 177 PCC needs to identify the allocation function from the initiation 178 message and should not return back PCErr message when checking the 179 local address is not equal with the source address of Tunnel 1. This 180 document defines E bit in section 3.2 carried in LSP object to 181 indicate the egress PCC operation which may not trigger the LSP 182 initiation. 184 When the path SID is allocated by ingress PCC, it need to inform PCE 185 with the PCRpt message and the latter one sends the notification to 186 egress PCC with PCUpd or PCInit message carried LSP object which set 187 the E bit to 1. 189 When the path SID is allocated by PCE, it need to inform ingress and 190 egress PCC with PCUpd or PCInit message carrying the Tunnel 1 and LSP 191 1. But the message sent to egress PCC MUST set the E bit to 1 to 192 avoid triggering the LSP initiation. 194 +------+ 195 | PCE | 196 +------+ 197 PCReq ^ \ PCUpd/PCInit 198 Tunnel 1 / \ Tunnel 1 199 LSP1 / \ LSP1, E=1 200 / \ 201 / v 202 +--------+ LSP1 +-------+ 203 |Ingress |----------->|Egress | 204 |PCC |<-----------|PCC | 205 +--------+ LSP2 +-------+ 207 Figure 2 The path SID allocation with PCE 209 2.2. Associated Bi-directional SR tunnel 211 As [RFC5654] defined, MPLS-TP MUST support unidirectional, co-routed 212 bidirectional, and associated bidirectional point-to-point transport 213 paths. Based on the defination of co-routed bidirectional path, the 214 forward and backward directions follow the same route (links and 215 nodes) across the network and must be setup, monitored and protected 216 as a single entity. 218 However, as [RFC8402] defined, segment routing leverages the source 219 routing paradigm and the sourse node steers a packet through an 220 ordered segment list along a unidirectional path. So for 221 bidirectional SR tunnel, the forward and backward directional paths 222 may be setup by the source node and destination node seperately. So 223 the co-routed birectional SR paths can not be provisioned by PCE. 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 Double-sided initiation can be initiated by PCCs or PCE.The 233 forward and reverse directional paths can be co-routed or non- 234 corouted. The SR bidirectional tunnel may follow the same path in 235 the forward and reverse directions and initialed as a co-routed 236 associated bidirectional LSP. 238 3. PCEP extensions for SR MPLS-TP 240 3.1. ERO extension 242 As described in [I-D.hu-spring-sr-tp-use-case], it is required to 243 support bi-directional tunnel to meet the requirement of SR networks. 244 But it is the uni-directional tunnel for SR and engineering traffic 245 network as discussed in [I-D.ietf-pce-segment-routing]. The SR path 246 is carried in the Segment Routing Explicit Route Object (SR-ERO), 247 which consists of a sequence of SR subobjects. This document 248 proposes the extension of the SR-ERO Subobject to carry the bi- 249 directional tunnel information as the Figure 3 shown. The subobjects 250 with path SIDs need to be added to the list of the SR-ERO subobjects. 252 0 1 2 3 253 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 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 |L| Type | Length | NT | Flags |R|F|S|C|M| 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | SID | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 // NAI(variable,optional) // 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 Figure 3 Extension of SR-ERO Subobject format 264 NAI Type (NT) : A new type of NT = 6 is added in this document and it 265 indicates the type and format of the NAI associated with the path SID 266 contained in the object body. When NT is set to 6, the format of NAI 267 field is shown as figure 4. 269 R (Reverse Flag -- 1 bit): indicates the SR path direction, when it 270 is clear, it indicates the forward direction and when it is set, it 271 indicates the reverse direction. 273 The definition of other fields is the same with 274 [I-D.ietf-pce-segment-routing]. 276 0 1 2 3 277 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 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Path Label | TC |S| TTL | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 Figure 4 NAI for Path Label information 283 The format of Path Label information is specified as 284 [I-D.cheng-spring-mpls-path-segment]. 286 3.2. E bit in LSP object 288 The LSP object is defined in [RFC8231]. This document proposes the E 289 bit in flag field of the LSP object: 291 E (Egress PCC Operation bit): If the bit is set to 1, it indicates 292 that the egress PCC operation with PCUpd or PCInit message and no 293 need to trigger the LSP initiation. A PCE would set the bit to 1 in 294 SR network to request or inform the path SID information. 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | PLSP-ID | Flag |E| 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 // TLVs // 302 | | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Figure 5 The extension of LSP object 306 3.3. Processing Rules 308 As discussed in [I-D.cheng-spring-mpls-path-segment], the bi- 309 directional SR tunnel is created from two binding unidirectional SR 310 paths. As defined in [RFC8281], the stateful PCE calculates the SR 311 paths and initiates the bi-directional LSP with PCUpd or PCInit 312 message. 314 The B bit in SRP Object MUST be set and the two unidirectional SR 315 paths may be computed from the forward and reverse direction and sent 316 to the source and destination PCC respectively in SR-ERO object. The 317 path labels which binding the paths may be generated in PCE and sent 318 to the related PCC carried in the bottom of the SR-ERO. When the 319 PCCs at both ends receiving the PCInit message with the labels in SR- 320 ERO subobjects, they may forward the packets from bi-directional 321 tunnel in MPLS-TP networks. 323 4. Security Considerations 325 TBD. 327 5. IANA Considerations 329 TBD. 331 6. Acknowledgements 333 TBD. 335 7. References 337 7.1. Informative References 339 [I-D.hu-spring-sr-tp-use-case] 340 hu, f., Xiong, Q., Mirsky, G., and W. Cheng, "Segment 341 Routing Transport Profile Use Case", draft-hu-spring-sr- 342 tp-use-case-01 (work in progress), March 2018. 344 7.2. Normative References 346 [I-D.cheng-spring-mpls-path-segment] 347 Cheng, W., Wang, L., Li, H., Chen, M., Gandhi, R., Zigler, 348 R., and S. Zhan, "Path Segment in MPLS Based Segment 349 Routing Network", draft-cheng-spring-mpls-path-segment-03 350 (work in progress), October 2018. 352 [I-D.ietf-pce-association-bidir] 353 Barth, C., Gandhi, R., and B. Wen, "PCEP Extensions for 354 Associated Bidirectional Label Switched Paths (LSPs)", 355 draft-ietf-pce-association-bidir-01 (work in progress), 356 May 2018. 358 [I-D.ietf-pce-segment-routing] 359 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 360 and J. Hardwick, "PCEP Extensions for Segment Routing", 361 draft-ietf-pce-segment-routing-14 (work in progress), 362 October 2018. 364 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 365 Requirement Levels", BCP 14, RFC 2119, 366 DOI 10.17487/RFC2119, March 1997, 367 . 369 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 370 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 371 DOI 10.17487/RFC5440, March 2009, 372 . 374 [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., 375 Sprecher, N., and S. Ueno, "Requirements of an MPLS 376 Transport Profile", RFC 5654, DOI 10.17487/RFC5654, 377 September 2009, . 379 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 380 Computation Element Communication Protocol (PCEP) 381 Extensions for Stateful PCE", RFC 8231, 382 DOI 10.17487/RFC8231, September 2017, 383 . 385 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 386 Computation Element Communication Protocol (PCEP) 387 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 388 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 389 . 391 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 392 Decraene, B., Litkowski, S., and R. Shakir, "Segment 393 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 394 July 2018, . 396 Authors' Addresses 398 Quan Xiong 399 ZTE Corporation 400 No.6 Huashi Park Rd 401 Wuhan, Hubei 430223 402 China 404 Phone: +86 27 83531060 405 Email: xiong.quan@zte.com.cn 407 Fangwei Hu 408 ZTE Corporation 409 No.889 Bibo Rd 410 Shanghai 201203 411 China 413 Phone: +86 21 68896273 414 Email: hu.fangwei@zte.com.cn 415 Shuangping Zhan 416 ZTE Corporation 417 Liuxian Rd 418 Shenzhen 518057 419 China 421 Phone: +86 755 26773770 422 Email: zhan.shuangping@zte.com.cn