idnits 2.17.1 draft-li-pce-sr-path-segment-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 : ---------------------------------------------------------------------------- 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 (October 22, 2018) is 2014 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 (-16) exists of draft-ietf-pce-segment-routing-14 == Outdated reference: A later version (-04) exists of draft-negi-pce-segment-routing-ipv6-03 == Outdated reference: A later version (-09) exists of draft-zhao-pce-pcep-extension-pce-controller-sr-03 == Outdated reference: A later version (-07) exists of draft-li-spring-srv6-path-segment-00 == Outdated reference: A later version (-16) exists of draft-li-pce-controlled-id-space-00 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group C. Li 3 Internet-Draft M. Chen 4 Intended status: Standards Track D. Dhody 5 Expires: April 25, 2019 Huawei Technologies 6 W. Cheng 7 China Mobile 8 J. Dong 9 Z. Li 10 Huawei Technologies 11 R. Gandhi 12 Cisco Systems, Inc. 13 October 22, 2018 15 Path Computation Element Communication Protocol (PCEP) Extension for 16 Path Segment in Segment Routing (SR) 17 draft-li-pce-sr-path-segment-03 19 Abstract 21 The Path Computation Element (PCE) provides path computation 22 functions in support of traffic engineering in Multiprotocol Label 23 Switching (MPLS) and Generalized MPLS (GMPLS) networks. 25 The Source Packet Routing in Networking (SPRING) architecture 26 describes how Segment Routing (SR) can be used to steer packets 27 through an IPv6 or MPLS network using the source routing paradigm. A 28 Segment Routed Path can be derived from a variety of mechanisms, 29 including an IGP Shortest Path Tree (SPT), explicit configuration, or 30 a Path Computation Element (PCE). 32 Path identification is needed for several use cases such as 33 performance measurement in Segment Routing (SR) network. This 34 document specifies extensions to the Path Computation Element 35 Protocol (PCEP) to support requesting, replying, reporting and 36 updating the Path Segment ID (Path SID) between PCEP speakers. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on April 25, 2019. 55 Copyright Notice 57 Copyright (c) 2018 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 75 3. Overview of Path Segment Extensions in PCEP . . . . . . . . . 4 76 4. Objects and TLVs . . . . . . . . . . . . . . . . . . . . . . 5 77 4.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 5 78 4.1.1. The SR PCE Capability sub-TLV . . . . . . . . . . . . 5 79 4.1.2. The SRv6 PCE Capability sub-TLV . . . . . . . . . . . 6 80 4.1.3. PCECC-CAPABILITY sub-TLV . . . . . . . . . . . . . . 6 81 4.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 7 82 4.2.1. Path Segment TLV . . . . . . . . . . . . . . . . . . 7 83 4.3. FEC Object . . . . . . . . . . . . . . . . . . . . . . . 9 84 4.4. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 10 85 5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 5.1. PCC Allocated Path Segment . . . . . . . . . . . . . . . 11 87 5.1.1. Egress PCC Allocated Path Segment . . . . . . . . . . 11 88 5.2. PCE Allocated Path Segment . . . . . . . . . . . . . . . 15 89 5.2.1. PCE Controlled Label Spaces Advertisement . . . . . . 15 90 5.2.2. Ingress PCC request Path Segment to PCE . . . . . . . 15 91 5.2.3. PCE allocated Path Segment on its own . . . . . . . . 16 92 6. Dataplane Considerations . . . . . . . . . . . . . . . . . . 17 93 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 94 7.1. SR PCE Capability Flags . . . . . . . . . . . . . . . . . 17 95 7.2. SRv6 PCE Capability Flags . . . . . . . . . . . . . . . . 18 96 7.3. New LSP Flag Registry . . . . . . . . . . . . . . . . . . 18 97 7.4. New PCEP TLV . . . . . . . . . . . . . . . . . . . . . . 18 98 7.4.1. Path Segment TLV . . . . . . . . . . . . . . . . . . 18 99 7.5. New CCI Flag Registry . . . . . . . . . . . . . . . . . . 19 100 7.6. New FEC Type Registry . . . . . . . . . . . . . . . . . . 19 101 7.7. PCEP Error Type and Value . . . . . . . . . . . . . . . . 20 102 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 103 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 104 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 105 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 106 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 107 11.2. Informative References . . . . . . . . . . . . . . . . . 22 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 110 1. Introduction 112 [RFC5440] describes the Path Computation Element (PCE) Communication 113 Protocol (PCEP). PCEP enables the communication between a Path 114 Computation Client (PCC) and a PCE, or between PCE and PCE, for the 115 purpose of computation of Multiprotocol Label Switching (MPLS) as 116 well as Generalzied MPLS (GMPLS) Traffic Engineering Label Switched 117 Path (TE LSP) characteristics. 119 [RFC8231] specifies a set of extensions to PCEP to enable stateful 120 control of TE LSPs within and across PCEP sessions in compliance with 121 [RFC4657]. It includes mechanisms to effect LSP State 122 Synchronization between PCCs and PCEs, delegation of control over 123 LSPs to PCEs, and PCE control of timing and sequence of path 124 computations within and across PCEP sessions. The model of operation 125 where LSPs are initiated from the PCE is described in [RFC8281]. 127 [I-D.zhao-pce-pcep-extension-for-pce-controller] specify the 128 procedures and PCEP protocol extensions for using the PCE as the 129 central controller for static LSPs, where LSPs can be provisioned as 130 explicit label instructions at each hop on the end-to-end path. 132 Segment routing (SR) [RFC8402] leverages the source routing and 133 tunneling paradigms and supports steering packets into an explicit 134 forwarding path at the ingress node. 136 An SR path needs to be identified in some use cases such as 137 performance measurement. For identifying an SR path, 138 [I-D.cheng-spring-mpls-path-segment] introduces a new segment that is 139 referred to as Path Segment. 141 [I-D.ietf-pce-segment-routing] specifies extensions to the Path 142 Computation Element Protocol (PCEP) [RFC5440] for SR networks, that 143 allow a stateful PCE to compute and initiate SR-TE paths, as well as 144 a PCC to request, report or delegate SR paths. 145 [I-D.negi-pce-segment-routing-ipv6] extend PCEP to support SR paths 146 for IPv6 data plane. 148 [I-D.zhao-pce-pcep-extension-pce-controller-sr] specifies the 149 procedures and PCEP protocol extensions when a PCE-based controller 150 is also responsible for configuring the forwarding actions on the 151 routers (SR SID distribution in this case), in addition to computing 152 the paths for packet flows in a segment routing network and telling 153 the edge routers what instructions to attach to packets as they enter 154 the network. 156 This document specifies a mechanism to carry the SR path 157 identification information in PCEP messages [RFC5440] [RFC8231] 158 [RFC8281]. The SR path identifier can be a Path Segment in SR-MPLS 159 [I-D.cheng-spring-mpls-path-segment], or a Path Segment in SRv6 160 [I-D.li-spring-srv6-path-segment] or other IDs that can identify an 161 SR path. This document also extends the PCECC-SR mechanism to inform 162 the Path Segment to the egress PCC. 164 2. Terminology 166 This memo makes use of the terms defined in [RFC4655], 167 [I-D.ietf-pce-segment-routing], and [RFC8402]. 169 2.1. Requirements Language 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 173 "OPTIONAL" in this document are to be interpreted as described in BCP 174 14 [RFC2119] [RFC8174] when, and only when, they appear in all 175 capitals, as shown here. 177 3. Overview of Path Segment Extensions in PCEP 179 This document specifies a mechanism of encoding (and allocating) Path 180 Segment in PCEP extensions. For supporting Path Segment in PCEP, 181 several TLVs and flags are defined. The formats of the objects and 182 TLVs are described in Section 4. The procedures of Path Segment 183 allocation are described in Section 5. 185 There are various modes of operations, such as - 187 o The Path Segment can be allocated by Egress PCC. The PCE should 188 request the Path Segment from Egress PCC. 190 o The PCE can allocate a Path Segment on its own accord and inform 191 the ingress/egress PCC, useful for PCE-initiated LSPs. 193 o Ingress PCC can also request PCE to allocate the Path Segment, in 194 this case, the PCE would either allocate and inform the assigned 195 Path Segment to the ingress/egress PCC using PCEP messages, or 196 first request egress PCC for Path Segment and then inform it to 197 the ingress PCC. 199 The path information to the ingress PCC and PCE is exchanged via an 200 extension to [I-D.ietf-pce-segment-routing] and 201 [I-D.negi-pce-segment-routing-ipv6]. The Path Segment information to 202 the egress PCC can be informed via an extension to the PCECC-SR 203 procedures [I-D.zhao-pce-pcep-extension-pce-controller-sr]. 205 For the PCE to allocate a Path Segment, the PCE SHOULD be aware of 206 the MPLS label space from the PCCs. This is done via mechanism as 207 described in [I-D.li-pce-controlled-id-space]. Otherwise, the PCE 208 should request the egress PCC for Path Segment allocation. 210 4. Objects and TLVs 212 4.1. The OPEN Object 214 4.1.1. The SR PCE Capability sub-TLV 216 [I-D.ietf-pce-segment-routing] defined a new Path Setup Type (PST) 217 and SR-PCE-CAPABILITY sub-TLV for SR. PCEP speakers use this sub-TLV 218 to exchange information about their SR capability. The TLV defines a 219 Flags field that includes one bit (L-flag) to indicate Local 220 Significance [I-D.ietf-pce-segment-routing]. 222 This document adds an additional flag for Path Segment allocation, as 223 follows - 225 P (Path Segment Identification bit): A PCEP speaker sets this flag 226 to 1 to indicate that it has the capability to encode SR path 227 identification (Path Segment, as per 228 [I-D.cheng-spring-mpls-path-segment]). 230 0 1 2 3 231 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 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Type=26 | Length=4 | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Reserved | Flags |P|N|L| MSD | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 Figure 1: P-flag in SR-PCE-CAPABILITY TLV 240 The figure is included for the ease of the reader and can be removed 241 at the time of publication. 243 4.1.2. The SRv6 PCE Capability sub-TLV 245 [I-D.negi-pce-segment-routing-ipv6] defined a new Path Setup Type 246 (PST) and SRv6-PCE-CAPABILITY sub-TLV for SRv6. PCEP speakers use 247 this sub-TLV to exchange information about their SRv6 capability. 248 The TLV includes a Flags field and one bit (L-flag) was allocated in 249 [I-D.negi-pce-segment-routing-ipv6]. 251 This document adds an additional flag for Path Segment allocation, as 252 follows - 254 P (Path Segment Identification bit): A PCEP speaker sets this flag 255 to 1 to indicate that it has the capability to encode SRv6 path 256 identification.(Path Segment, as per 257 [I-D.li-spring-srv6-path-segment]). 259 0 1 2 3 260 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 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Type=TBD1 | Length=4 | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | max-SL | Reserved | Flags |P|L| 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 Figure 2: P-flag in SRv6-PCE-CAPABILITY TLV 269 The figure is included for the ease of the reader and can be removed 270 at the time of publication. 272 4.1.3. PCECC-CAPABILITY sub-TLV 274 Along with the SR sub-TLVs, the PCECC Capability as per 275 [I-D.zhao-pce-pcep-extension-pce-controller-sr] should be advertised 276 if the PCE allocates the Path Segment and acts as a Central 277 Controller that manages the Label space. 279 The PCECC Capability should also be advertised on the egress PCEP 280 session, along with the SR sub-TLVs. This is needed to ensure that 281 the PCE can use the PCECC objects/mechanism to request/inform the 282 egress PCC of the Path Segment as described in this document. 284 4.2. LSP Object 286 The LSP Object is defined in Section 7.3 of [RFC8231]. This document 287 adds the following flags to the LSP Object: 289 P (Path Segment Allocation bit): If the bit is set to 1, it 290 indicates that the Path Segment needs to be allocated by the PCE 291 for this LSP. A PCC would set this bit to 1 to request for 292 allocation of Path Segment by the PCE in the PCReq or PCRpt 293 message. A PCE would also set this bit to 1 to indicate that the 294 Path Segment is allocated by PCE and encoded in the PCRep, PCUpd 295 or PCInitiate message (the PATH-SEGMENT TLV MUST be present in LSP 296 object). Further, a PCE would set this bit to 0 to indicate that 297 the Path Segment should be allocated by the PCC as described in 298 Section 5.1.1. 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | PLSP-ID | Flag|P|C| O |A|R|S|D| 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 // TLVs // 306 | | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Figure 3: P-flag in LSP Object 311 The figure is included for the ease of the reader and can be removed 312 at the time of publication. 314 4.2.1. Path Segment TLV 316 The PATH-SEGMENT TLV is an optional TLV for use in the LSP Object for 317 Path Segment allocation. The type of this TLV is to be allocated by 318 IANA (TBA4). The format is shown below. 320 0 1 2 3 321 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 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Type | Length | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | ST | Flag |L| Reserved | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 ~ (Variable length) Path Segment ~ 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 Figure 4: The PATH-SEGMENT TLV Format 332 The type (16-bit) of the TLV is TBA4 (to be allocated by IANA). The 333 length (16-bit) has a fixed value of 8 octets. The value contains 334 the following fields: 336 ST (The Segment type - 8 bits): The ST field specifies the type of 337 the Path Segment field, which carries a Path Segment corresponding 338 to the SR path. 340 * 0: MPLS Path Segment, which is an MPLS label as defined in 341 [I-D.cheng-spring-mpls-path-segment]. The PST type MUST be set 342 to SR (MPLS). 344 * 1: SRv6 Path Segment, which is a 128 bit IPv6 address as 345 defined in [I-D.li-spring-srv6-path-segment]. The PST type 346 MUST be set to SRv6. 348 Flags (8 bits): Two flags are currently defined: 350 * L-Bit (Local/Global - 1 bit): If set, then the Path Segment 351 carried by the PATH-SEGMENT TLV has local significance. If not 352 set, then the Path Segment carried by this TLV has global 353 significance (i.e. Path Segment is global within an SR 354 domain). 356 * The unassigned bits MUST be set to 0 and MUST be ignored at 357 receipt. 359 Reserved (16 bits): MUST be set to 0 and MUST be ignored at 360 receipt. 362 Path Segment: The Path Segment of an SR path. The Path Segment 363 type is indicated by the ST field. When the ST is 0, it is a MPLS 364 Path Segment [I-D.cheng-spring-mpls-path-segment] in the MPLS 365 label format. When the ST field is 1, it is a 128-bit SRv6 Path 366 Segment as defined in [I-D.li-spring-srv6-path-segment]. 368 In general, only one instance of PATH-SEGMENT TLV will be included in 369 LSP object. If more than one PATH-SEGMENT TLV is included, the first 370 one is processed and others MUST be ignored. Multiple Path Segment 371 allocation for use cases like alternate-making will be considered in 372 future version of this draft. 374 When the Path Segment allocation is enable, a PATH-SEGMENT TLV should 375 be included in the LSP object. 377 If the label space is maintained by PCC itself, and the Path Segment 378 is allocated by Egress PCC, then the PCE should request the Path 379 Segment from Egress PCC as described in Section 5.1.1. In this case, 380 the PCE should send a PCUpdate or PCInitiate message to the egress 381 PCC to request the Path Segment. The P-flag in LSP should be unset 382 in this case. 384 If the PCC requests the Path Segment to be allocated by the PCE, P 385 flag in LSP object is set to 1 and PATH-SEGMENT TLV MAY be skipped. 386 After the PCE has allocated a Path Segment, it MUST include the PATH- 387 SEGMENT TLV in a LSP object. 389 If the PCE allocated the Path Segment on its own accord, a PATH- 390 SEGMENT TLV MUST be included in a LSP object. 392 If a PCEP node does not recognize the PATH-SEGMENT TLV, it would 393 behave in accordance with [RFC5440] and ignore the TLV. If a PCEP 394 node recognizes the TLV but does not support the TLV, it MUST send 395 PCErr with Error-Type = 2 (Capability not supported). 397 4.3. FEC Object 399 The FEC Object [I-D.zhao-pce-pcep-extension-pce-controller-sr] is 400 used to specify the FEC information and MAY be carried within 401 PCInitiate or PCRpt message for the PCECC-SR operations. The PCE 402 MUST inform the Path Identification information to the Egress PCC. 403 To do this, this document extends the procedures of 404 [I-D.zhao-pce-pcep-extension-pce-controller-sr] by defining a new FEC 405 object type for Path. 407 FEC Object-Type is TBA6 'Path'. 409 0 1 2 3 410 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 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | | 413 // TLV(s) // 414 | | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 Figure 5: The path FEC object Format 419 One or more following TLV(s) are allowed in the 'path' FEC object - 421 o SYMBOLIC-PATH-NAME TLV: As defined in [RFC8231], it is a human- 422 readable string that identifies an LSP in the network. 424 o LSP-IDENTIFIERS TLVs: As defined in [RFC8231], it is optional for 425 SR, but could be used to encode the source, destination and other 426 identification information for the path. 428 o SPEAKER-ENTITY-ID TLV: As defined in [RFC8232], a unique 429 identifier for the PCEP speaker, it is used to identify the 430 Ingress PCC. 432 Either SYMBOLIC-PATH-NAME TLV or LSP-IDENTIFIERS TLV MUST be 433 included. SPEAKER-ENTITY-ID TLV is optional. Only one instance of 434 each TLV is processed, if more than one TLV of each type is included, 435 the first one is processed and others MUST be ignored. 437 4.4. CCI Object 439 The Central Control Instructions (CCI) Object is used by the PCE to 440 specify the forwarding instructions is defined in 441 [I-D.zhao-pce-pcep-extension-for-pce-controller]. Further 442 [I-D.zhao-pce-pcep-extension-pce-controller-sr] defined a CCI object 443 type for SR. 445 The Path Segment information is encoded directly in the CCI SR 446 object. The Path Segment TLV as described in the Section 4.2.1, MUST 447 also be included in the CCI SR object as the TLV (as it includes 448 additional information regarding the Path Segment identifier). 450 This document adds the following flags to the CCI Object: 452 o C (PCC Allocation bit): If the bit is set to 1, it indicates that 453 the allocation needs to be done by the PCC for this central 454 controller instruction. A PCE set this bit to request the PCC to 455 make an allocation from its SR label space. A PCC would set this 456 bit to indicate that it has allocated the CC-ID and report it to 457 the PCE. 459 0 1 2 3 460 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 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | CC-ID | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | MT-ID | Algorithm | Flags |C|N|E|V|L|O| 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 // SID/Label/Index (variable) // 467 +---------------------------------------------------------------+ 468 | | 469 // Optional TLV // 470 | | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 Figure 6: The CCI object for SR 475 (Editor's Note - An update is planned for 476 [I-D.zhao-pce-pcep-extension-pce-controller-sr] in the next revision 477 detailing this procedure, and the above text might move there.) 479 5. Operations 481 The Path Segment allocation and encoding is as per the stateful PCE 482 operations for segment routing. The procedures are as per the 483 corresponding extensions defined in [I-D.ietf-pce-segment-routing] 484 and [I-D.negi-pce-segment-routing-ipv6] (which are further based on 485 [RFC8231] and [RFC8281]). The additional operations for Path Segment 486 are defined in this section. 488 To notify (or request) the Path Segment to the Egress PCC, the 489 procedures are as per the PCECC-SR 490 [I-D.zhao-pce-pcep-extension-pce-controller-sr] (which is based on 491 [I-D.zhao-pce-pcep-extension-for-pce-controller]). The additional 492 operations are defined in this section. 494 5.1. PCC Allocated Path Segment 496 5.1.1. Egress PCC Allocated Path Segment 498 As defined in [I-D.cheng-spring-mpls-path-segment], a Path Segment 499 can be allocated by the egress PCC. In this case, the label space 500 may be maintained on the PCC itself. 502 On receiving a stateful path computation request with Path Segment 503 allocation request from an ingress PCC, or by initiating or updating 504 an LSP with Path Segment actively, a PCE can request the egress PCC 505 to allocate a Path Segment. This is needed if the PCE does not 506 control the Path Segment allocation for the egress PCC or the label 507 space is maintained by the egress PCC itself. 509 The mechanism of Path Segment request and reply may be achieved by 510 using PCInitiate and PCUpd message as described in this section. 512 5.1.1.1. Using CCI and FEC objects (PCECC) 514 The PCE can request the egress to allocate the Path Segment using the 515 PCInitiate message as described in 516 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. The C flag in the 517 CCI object is set to 1 and the CC-ID is set to a special value of 518 0x0000 to indicate that the allocation needs to be done by the PCC. 519 The PATH-SEGMENT TLV is also be included in CCI object along with the 520 FEC object identifying the SR-Path. The egress PCC would allocate 521 the Path Segment and would report to the PCE using the PCRpt message 522 as described in [I-D.zhao-pce-pcep-extension-pce-controller-sr] with 523 the allocated Path Segment in the CC-ID field as well as in the PATH- 524 SEGMENT TLV. 526 (Editor's Note - An update is planned for 527 [I-D.zhao-pce-pcep-extension-pce-controller-sr] in the next revision 528 detailing this procedure) 530 If the value of CC-ID/Path Segment is 0 and the C flag is set, it 531 indicates that the PCE is requesting a Path Segment for this LSP. If 532 the CC-ID/Path Segment is set to a value 'n' and the C flag is set in 533 the CCI object, it indicates that the PCE requests a specific value 534 'n' of Path Segment. If the Path Segment is allocated successfully, 535 the egress PCC should report the Path Segment via PCRpt message with 536 the CCI object along with the PATH-SEGMENT TLV. Else, it MUST send a 537 PCErr message with Error-Type = TBA7 ("Path SID failure") and Error 538 Value = 1 ("Invalid SID"). If the value of Path Segment in CCI 539 object is valid, but the PCC is unable to allocate the Path Segment, 540 it MUST send a PCErr message with Error-Type = TBA7 ("Path label/SID 541 failure") and Error Value = 2 ("Unable to allocate the specified 542 label/SID"). 544 Once the PCE receives the PCRpt message with the CCI object, it can 545 obtain the Path Segment information from the egress PCC and then 546 update the path with Path Segment or reply to the ingress PCC, the 547 path information with Path Segment. 549 If the SR-Path is setup the ingress PCC will acknowledge with a PCRpt 550 message to the PCE. In case of error, as described in 551 [I-D.ietf-pce-segment-routing], an PCErr message will be sent back to 552 the PCE. The PCE MUST request the withdraw of the Path Segment 553 allocation by sending a PCInitiate message to remove the central 554 controller instruction as per 555 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. When the LSP is 556 deleted or the Path Segment is removed, the PCE should synchronize 557 with the egress PCC. 559 If the egress PCC wishes to withdraw or modify a previously reported 560 Path Segment value, it MUST send a PCRpt message without any PATH- 561 SEGMENT TLV or with the PATH-SEGMENT TLV containing the new Path 562 Segment respectively in the CCI object. The PCE would further 563 trigger the removal of the central controller instruction as per 564 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. 566 If a PCE wishes to modify a previously requested Path Segment value, 567 it MUST send a new PCInitiate message with an allocation request CC- 568 ID/PATH-SEGMENT TLV containing the new Path Segment value and C flag 569 is set. The PCE should trigger the removal of the older Path Segment 570 next as per [I-D.zhao-pce-pcep-extension-pce-controller-sr]. 572 Ingress Egress 573 +-+-+ +-+-+ +-+-+ 574 |PCC| |PCE| |PCC| 575 +-+-+ +-+-+ +-+-+ 576 1) LSP State | ---- PCRpt ----> | | 577 Delegate | Delegate=1 | | 578 | P=1 |2) PCE update | 579 | | the LSP-DB and | 580 | | request Path SID | 581 | | | 582 | | --- PCInitiate ---> | Egress 583 | | CC-ID=0 | allocates 584 | | FEC=Path | a Path-SID 585 | | | from its 586 | | <----- PCRpt ------ | space 587 | | CC-ID= | 588 | | Path SID | 589 | | | 590 |<---- PCUpd ---- |3)Paths update with | 591 | PATH-SEGMENT TLV | Path SID | 592 | | | 593 4) LSP State | ----- PCRpt ---> | | 594 Report | | | 595 | | | 597 Figure 7: Egress PCC Allocated Path Segment 599 5.1.1.2. Using LSP objects (PCEP-SR) 601 The PATH-SEGMENT TLV MUST be included in an LSP object in the 602 PCInitiate message sent from the PCE to the egress to request path 603 identification allocation by the egress PCC. The P flag in LSP 604 object MUST be set to 0. This PCInitiate message to egress PCC would 605 be the similar to the one sent to ingress PCC as per 606 [I-D.ietf-pce-segment-routing], but the egress PCC would only 607 allocate the Path Segment and would not trigger the initiation/update 608 operation. 610 If the value of Path Segment is 0x0 it indicates that the PCE is 611 requesting a Path Segment for this LSP. If the Path Segment is set 612 to a value 'n' and the P flag is unset in the LSP object, it 613 indicates that the PCE requests a specific value 'n' of Path Segment. 614 If the Path Segment is allocated successfully, the egress PCC should 615 report the Path Segment via PCRpt message with PATH-SEGMENT TLV in 616 LSP object. Else, it MUST send a PCErr message with Error-Type = 617 TBA7 ("Path SID failure") and Error Value = 1 ("Invalid SID"). If 618 the value of Path Segment is valid, but the PCC is unable to allocate 619 the Path Segment, it MUST send a PCErr message with Error-Type = TBA7 620 ("Path label/SID failure") and Error Value = 2 ("Unable to allocate 621 the specified label/SID"). 623 Once the PCE receives the PCRpt message, it can obtain the Path 624 Segment information from the egress PCC and then update the path with 625 Path Segment or reply to the ingress PCC, the path information with 626 Path Segment. 628 If the SR-Path is setup the ingress PCC will acknowledge with a PCRpt 629 message to the PCE. In case of error, as described in 630 [I-D.ietf-pce-segment-routing], an PCErr message will be sent back to 631 the PCE. The PCE MUST request the withdraw of the Path Segment 632 allocation by sending a PCUpd message to remove the LSP and 633 associated Path Segment by setting the R flag in the SRP object. 634 When the LSP is deleted or the Path Segment is removed, the PCE 635 should send a PCUpd message to synchronize with the egress PCC. 637 If the egress PCC wishes to withdraw or modify a previously reported 638 Path Segment value, it MUST send a PCRpt message without any PATH- 639 SEGMENT TLV or with the PATH-SEGMENT TLV containing the new Path 640 Segment respectively. 642 If a PCE wishes to modify a previously requested Path Segment value, 643 it MUST send a PCUpd message with PATH-SEGMENT TLV containing the new 644 Path Segment value and P flag is LSP object would be unset. Absence 645 of the PATH-SEGMENT TLV in PCUpd message means that the PCE wishes to 646 withdraw the Path Segment. 648 If a PCC receives a valid Path Segment value from a PCE which is 649 different than the current Path Segment, it MUST try to allocate the 650 new value. If the new Path Segment is successfully allocated, the 651 PCC MUST report the new value to the PCE. Otherwise, it MUST send a 652 PCErr message with Error-Type = TBA7 ("Path label/SID failure") and 653 Error Value = 2 ("Unable to allocate the specified label/SID"). 655 Ingress Egress 656 +-+-+ +-+-+ +-+-+ 657 |PCC| |PCE| |PCC| 658 +-+-+ +-+-+ +-+-+ 659 1) LSP State | ---- PCRpt ----> | | 660 Delegate | Delegate=1 | | 661 | P=1 |2) PCE update | 662 | | the LSP-DB and | 663 | | request Path SID | 664 | | | 665 | | --- PCInitiate ---> | Egress 666 | | PATH-SEGMENT | allocates 667 | | TLV in LSP | a Path-SID 668 | | | from its 669 | | <----- PCRpt ------ | space 670 | | Path SID | 671 | | | 672 |<---- PCUpd ---- |3)Paths update with | 673 | PATH-SEGMENT TLV | Path SID | 674 | | | 675 4) LSP State | ----- PCRpt ---> | | 676 Report | | | 677 | | | 679 Figure 8: Egress PCC Allocated Path Segment 681 5.2. PCE Allocated Path Segment 683 5.2.1. PCE Controlled Label Spaces Advertisement 685 For allocating the Path Segments to SR paths by the PCEs, the PCE 686 controlled label space MUST be known at PCEs via configurations or 687 any other mechanism. The PCE controlled label spaces MAY be 688 advertised as described in [I-D.li-pce-controlled-id-space]. 690 5.2.2. Ingress PCC request Path Segment to PCE 692 The ingress PCC could request the Path Segment to be allocated by the 693 PCE via PCRpt message as per [RFC8231]. The delegate flag (D-flag) 694 MUST also be set for this LSP. Also, the P-flag in the LSP object 695 MUST be set. 697 If the ingress requests for an expected value of path segment, then a 698 PATH-SEGMENT TLV MUST be included with the expected value. Else, 699 there is no need to include a PATH-SEGMENT TLV in the LSP object. 701 If the Path Segment is allocated successfully, the PCE would further 702 respond to Ingress PCC with PCUpd message as per [RFC8231] and MUST 703 include the PATH-SEGMENT TLV in a LSP object. Else, it MUST send a 704 PCErr message with Error-Type = TBA7 ("Path SID failure") and Error 705 Value = 1 ("Invalid SID"). If the value of Path Segment is valid, 706 but the PCC is unable to allocate the Path Segment, it MUST send a 707 PCErr message with Error-Type = TBA7 ("Path label/SID failure") and 708 Error Value = 2 ("Unable to allocate the specified label/SID"). 710 The active PCE would allocate the Path Segment as per the PATH- 711 SEGMENT flags and in case PATH-SEGMENT is not included, the PCE MUST 712 act based on the local policy. 714 The PCE would further inform the egress PCC about the Path Segment 715 allocated by the PCE using the PCInitiate message as described in 716 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. 718 Ingress Egress 719 +-+-+ +-+-+ +-+-+ 720 |PCC| |PCE| |PCC| 721 +-+-+ +-+-+ +-+-+ 722 1) LSP State | ---- PCRpt ----> | | 723 Delegate | Delegate=1 | | 724 | P=1 |2) PCE update | 725 | | the LSP-DB and | 726 | | allocate Path SID | 727 |<---- PCUpd ---- |3)Paths update with | 728 | PATH-SEGMENT TLV | Path SID | 729 | | | 730 4) LSP State Report | ----- PCRpt ---> | | 731 | | | 732 |5) PCE informs the | --- PCInitiate ---> | 733 | Path SID to Egress| FEC=Path | 734 | | | 735 | | <-------- PCRpt --- | 736 | | | 738 Figure 9: Ingress PCC request Path Segment to PCE 740 5.2.3. PCE allocated Path Segment on its own 742 The PCE could allocate the Path Segment on its own for a PCE- 743 Initiated (or delegated LSP). The allocated Path Segment needs to be 744 informed to the Ingress and Egress PCC. The PCE would use the 745 PCInitiate message [RFC8281] or PCUpd message [RFC8231] towards the 746 Ingress PCC and MUST include the PATH-SEGMENT TLV in the LSP object. 747 The PCE would further inform the egress PCC about the Path Segment 748 allocated by the PCE using the PCInitiate message as described in 749 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. 751 Ingress Egress 752 +-+-+ +-+-+ +-+-+ 753 |PCC| |PCE| |PCC| 754 +-+-+ +-+-+ +-+-+ 755 | | | 756 | <--PCInitiate--- |1)Initiate LSP with | 757 | PATH-SEGMENT TLV | Path SID | 758 | | | 759 2)LSP delegation |---PCRpt, D=1---> | (Confirm) | 760 | | | 761 |3) PCE informs the | --- PCInitiate ---> | 762 | Path SID to Egress| FEC=Path | 763 | | | 764 | | <-------- PCRpt --- | 765 | | | 767 Figure 10: PCE allocated Path Segment on its own 769 6. Dataplane Considerations 771 As described in [I-D.cheng-spring-mpls-path-segment], in an SR-MPLS 772 network, when a packet is transmitted along an SR path, the labels in 773 the MPLS label stack will be swapped or popped. So that no label or 774 only the last label may be left in the MPLS label stack when the 775 packet reaches the egress node. Thus, the egress node cannot 776 determine from which SR path the packet comes. For this reason, it 777 introduces the Path Segment. 779 Apart from allocation and encoding of the Path Segment (described in 780 this document) for the LSP, it would also be included in the SID/ 781 Label stack of the LSP (usually for processing by the egress). To 782 support this, the Path Segment MAY also be a part of SR-ERO as 783 prepared by the PCE as per [I-D.ietf-pce-segment-routing]. The PCC 784 MAY also include the Path Segment while preparing the label stack 785 based on the local policy and use-case. 787 7. IANA Considerations 789 7.1. SR PCE Capability Flags 791 SR PCE Capability TLV is defined in [I-D.ietf-pce-segment-routing], 792 and the registry to manage the Flag field of the SR PCE Capability 793 TLV is requested in [I-D.ietf-pce-segment-routing]. IANA is 794 requested to make the following allocation in the aforementioned 795 registry. 797 Bit Description Reference 799 TBA1 Path Segment Allocation is supported(P) This document 801 7.2. SRv6 PCE Capability Flags 803 SRv6 PCE Capability TLV is defined in defined in 804 [I-D.negi-pce-segment-routing-ipv6], and the registry to manage the 805 Flag field of the SRv6 PCE Capability Flags is requested in 806 [I-D.negi-pce-segment-routing-ipv6]. IANA is requested to make the 807 following allocation in the aforementioned registry. 809 Bit Description Reference 811 TBA2 Path Segment Allocation is supported(P) This document 813 7.3. New LSP Flag Registry 815 [RFC8231] defines the LSP object; per that RFC, IANA created a 816 registry to manage the value of the LSP object's Flag field. IANA 817 has allocated a new bit in the "LSP Object Flag Field" subregistry, 818 as follows: 820 Bit Description Reference 822 TBA3 Request for Path Segment Allocation(P) This document 824 7.4. New PCEP TLV 826 IANA is requested to add the assignment of a new allocation in the 827 existing "PCEP TLV Type Indicators" subregistry as follows: 829 Value Description Reference 831 TBA4 PATH-SEGMENT TLV This document 833 7.4.1. Path Segment TLV 835 This document requests that a new subregistry named "PATH-SEGMENT TLV 836 Segment Type (ST) Field" to be created to manage the value of the ST 837 field in the PATH-SEGMENT TLV. 839 Value Description Reference 841 0 MPLS Path Segment(MPLS label) This document 842 1 SRv6 Path Segment(IPv6 address) This document 844 Further, this document also requests that a new subregistry named 845 "PATH-SEGMENT TLV Flag Field" to be created to manage the Flag field 846 in the PATH-SEGMENT TLV. New values are assigned by Standards Action 847 [RFC8126]. Each bit should be tracked with the following qualities: 849 o Bit number (counting from bit 0 as the most significant bit) 851 o Capability description 853 o Defining RFC 855 Bit Description Reference 857 7 Local Signification(L) This document 859 7.5. New CCI Flag Registry 861 CCI object is defined in defined in 862 [I-D.zhao-pce-pcep-extension-for-pce-controller], further 863 [I-D.zhao-pce-pcep-extension-pce-controller-sr] defined a CCI object 864 type for SR. and the subregistry to manage the Flag field of the CCI 865 object for SR is requested in 866 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. IANA is requested 867 to make the following allocation in the aforementioned subregistry. 869 Bit Description Reference 871 TBA5 PCC is requested to This document 872 allocate resource(C) 874 7.6. New FEC Type Registry 876 A new PCEP object called FEC is defined in 877 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. IANA is requested 878 to allocate a new Object-Type for FEC object in the "PCEP Objects" 879 subregistry. 881 Value Description Reference 883 TBA6 SR path This document 885 7.7. PCEP Error Type and Value 887 IANA is requested to allocate code-points in the "PCEP-ERROR Object 888 Error Types and Values" subregistry for the following new error-types 889 and error-values: 891 Error-Type Meaning Reference 893 TBA7 Path SID failure: This document 894 Error-value = 1 895 Invalid SID 897 Error-value = 2 898 Unable to allocate 899 Path SID 901 8. Security Considerations 903 TBA 905 9. Acknowledgments 907 10. Contributors 909 The following people have substantially contributed to this document: 911 Zafar Ali 912 Cisco Systems, Inc. 913 Email: zali@cisco.com 915 11. References 917 11.1. Normative References 919 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 920 Requirement Levels", BCP 14, RFC 2119, 921 DOI 10.17487/RFC2119, March 1997, 922 . 924 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 925 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 926 DOI 10.17487/RFC5440, March 2009, 927 . 929 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 930 Writing an IANA Considerations Section in RFCs", BCP 26, 931 RFC 8126, DOI 10.17487/RFC8126, June 2017, 932 . 934 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 935 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 936 May 2017, . 938 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 939 Computation Element Communication Protocol (PCEP) 940 Extensions for Stateful PCE", RFC 8231, 941 DOI 10.17487/RFC8231, September 2017, 942 . 944 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 945 and D. Dhody, "Optimizations of Label Switched Path State 946 Synchronization Procedures for a Stateful PCE", RFC 8232, 947 DOI 10.17487/RFC8232, September 2017, 948 . 950 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 951 Computation Element Communication Protocol (PCEP) 952 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 953 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 954 . 956 [I-D.ietf-pce-segment-routing] 957 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 958 and J. Hardwick, "PCEP Extensions for Segment Routing", 959 draft-ietf-pce-segment-routing-14 (work in progress), 960 October 2018. 962 [I-D.negi-pce-segment-routing-ipv6] 963 Negi, M., Dhody, D., Sivabalan, S., and P. Kaladharan, 964 "PCEP Extensions for Segment Routing leveraging the IPv6 965 data plane", draft-negi-pce-segment-routing-ipv6-03 (work 966 in progress), October 2018. 968 [I-D.zhao-pce-pcep-extension-pce-controller-sr] 969 Zhao, Q., Li, Z., Dhody, D., Karunanithi, S., Farrel, A., 970 and C. Zhou, "PCEP Procedures and Protocol Extensions for 971 Using PCE as a Central Controller (PCECC) of SR-LSPs", 972 draft-zhao-pce-pcep-extension-pce-controller-sr-03 (work 973 in progress), June 2018. 975 [I-D.zhao-pce-pcep-extension-for-pce-controller] 976 Zhao, Q., Li, Z., Dhody, D., Karunanithi, S., Farrel, A., 977 and C. Zhou, "PCEP Procedures and Protocol Extensions for 978 Using PCE as a Central Controller (PCECC) of LSPs", draft- 979 zhao-pce-pcep-extension-for-pce-controller-08 (work in 980 progress), June 2018. 982 [I-D.li-spring-srv6-path-segment] 983 Li, C., Chen, M., Dhody, D., Li, Z., Dong, J., and R. 984 Gandhi, "Path Segment for SRv6 (Segment Routing in IPv6)", 985 draft-li-spring-srv6-path-segment-00 (work in progress), 986 October 2018. 988 11.2. Informative References 990 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 991 Element (PCE)-Based Architecture", RFC 4655, 992 DOI 10.17487/RFC4655, August 2006, 993 . 995 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 996 Element (PCE) Communication Protocol Generic 997 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 998 2006, . 1000 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1001 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1002 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1003 July 2018, . 1005 [I-D.li-pce-controlled-id-space] 1006 Li, C., Chen, M., Dong, J., Li, Z., and D. Dhody, "PCE 1007 Controlled ID Space", draft-li-pce-controlled-id-space-00 1008 (work in progress), June 2018. 1010 [I-D.cheng-spring-mpls-path-segment] 1011 Cheng, W., Wang, L., Li, H., Chen, M., Gandhi, R., Zigler, 1012 R., and S. Zhan, "Path Segment in MPLS Based Segment 1013 Routing Network", draft-cheng-spring-mpls-path-segment-03 1014 (work in progress), October 2018. 1016 Authors' Addresses 1018 Cheng Li 1019 Huawei Technologies 1020 Huawei Campus, No. 156 Beiqing Rd. 1021 Beijing 100095 1022 China 1024 Email: chengli13@huawei.com 1026 Mach(Guoyi) Chen 1027 Huawei Technologies 1028 Huawei Campus, No. 156 Beiqing Rd. 1029 Beijing 100095 1030 China 1032 Email: Mach.chen@huawei.com 1034 Dhruv Dhody 1035 Huawei Technologies 1036 Divyashree Techno Park, Whitefield 1037 Bangalore, Karnataka 560066 1038 India 1040 Email: dhruv.ietf@gmail.com 1042 Weiqiang Cheng 1043 China Mobile 1044 China 1046 Email: chengweiqiang@chinamobile.com 1048 Jie Dong 1049 Huawei Technologies 1050 Huawei Campus, No. 156 Beiqing Rd. 1051 Beijing 100095 1052 China 1054 Email: jie.dong@huawei.com 1055 Zhenbin Li 1056 Huawei Technologies 1057 Huawei Campus, No. 156 Beiqing Rd. 1058 Beijing 100095 1059 China 1061 Email: lizhenbin@huawei.com 1063 Rakesh Gandhi 1064 Cisco Systems, Inc. 1065 Canada 1067 Email: rgandhi@cisco.com