idnits 2.17.1 draft-gandhi-spring-sr-mpls-pm-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 321 has weird spacing: '...) Field bein...' == Line 424 has weird spacing: '...) Field bein...' -- The document date (July 15, 2018) is 2112 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 7810 (Obsoleted by RFC 8570) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group R. Gandhi, Ed. 3 Internet-Draft C. Filsfils 4 Intended Status: Informational S. Soni 5 Expires: January 16, 2019 Cisco Systems, Inc. 6 D. Voyer 7 Bell Canada 8 S. Salsano 9 Universita di Roma "Tor Vergata" 10 P. L. Ventre 11 CNIT 12 M. Chen 13 Huawei 14 July 15, 2018 16 Performance Measurement in 17 Segment Routing Networks with MPLS Data Plane 18 draft-gandhi-spring-sr-mpls-pm-02 20 Abstract 22 RFC 6374 specifies protocol mechanisms to enable the efficient and 23 accurate measurement of packet loss, one-way and two-way delay, as 24 well as related metrics such as delay variation in MPLS networks 25 using probe messages. This document reviews how these mechanisms can 26 be used for Delay and Loss Performance Measurements (PM) in Segment 27 Routing (SR) networks with MPLS data plane (SR-MPLS), for both SR 28 links and end-to-end SR Policies. The performance measurements for 29 SR links are used to compute extended Traffic Engineering (TE) 30 metrics for delay and loss and are advertised in the network using 31 routing protocols. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 67 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 68 2.2. Reference Topology . . . . . . . . . . . . . . . . . . . . 4 69 3. Probe Query and Response Packets . . . . . . . . . . . . . . . 5 70 3.1. Probe Packet Header for SR-MPLS Policies . . . . . . . . . 5 71 3.2. Probe Packet Header for SR-MPLS Links . . . . . . . . . . 5 72 3.3. Probe Response Message for SR-MPLS Links and Policies . . 6 73 3.3.1. One-way Measurement Probe Response Message . . . . . . 6 74 3.3.2. Two-way Measurement Probe Response Message . . . . . . 6 75 4. Performance Delay Measurement . . . . . . . . . . . . . . . . 6 76 4.1. Delay Measurement Message Format . . . . . . . . . . . . . 6 77 4.2. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 8 78 5. Performance Loss Measurement . . . . . . . . . . . . . . . . . 8 79 5.1. Loss Measurement Message Format . . . . . . . . . . . . . 8 80 6. SR Link Extended TE Metrics Advertisements . . . . . . . . . . 10 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 85 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 86 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 90 1. Introduction 92 Service provider's ability to satisfy Service Level Agreements (SLAs) 93 depend on the ability to measure and monitor performance metrics for 94 packet loss and one-way and two-way delay, as well as related metrics 95 such as delay variation. The ability to monitor these performance 96 metrics also provides operators with greater visibility into the 97 performance characteristics of their networks, thereby facilitating 98 planning, troubleshooting, and network performance evaluation. 100 [RFC6374] specifies protocol mechanisms to enable the efficient and 101 accurate measurement of these performance metrics in MPLS networks 102 using probe messages. The One-Way Active Measurement Protocol 103 (OWAMP) defined in [RFC4656] and Two-Way Active Measurement Protocol 104 (TWAMP) defined in [RFC5357] provide capabilities for the measurement 105 of various performance metrics in IP networks. However, mechanisms 106 defined in [RFC6374] are more suitable for Segment Routing (SR) when 107 using MPLS data plane (SR-MPLS). In addition, [RFC6374] also 108 supports IEEE 1588 timestamps [IEEE1588] and "direct mode" Loss 109 Measurement (LM), which are required in SR networks. 111 [RFC7876] specifies the procedures to be used when sending and 112 processing out-of-band performance measurement probe replies over an 113 UDP return path when receiving RFC 6374 based probe queries. These 114 procedures can be used to send out-of-band PM replies for both SR 115 links and SR Policies for one-way measurement. 117 This document reviews how probe based mechanisms defined in [RFC6374] 118 can be used for Delay and Loss Performance Measurements (PM) in SR 119 networks with MPLS data plane, for both SR links and end-to-end SR 120 Policies. The performance measurements for SR links are used to 121 compute extended Traffic Engineering (TE) metrics for delay and loss 122 and are advertised in the network using routing protocols. 124 2. Conventions Used in This Document 126 2.1. Abbreviations 128 ACH: Associated Channel Header. 130 DFLag: Data Format Flag. 132 DM: Delay Measurement. 134 ECMP: Equal Cost Multi-Path. 136 G-ACh: Generic Associated Channel (G-ACh) 137 GAL: Generic Associated Channel (G-ACh) Label 139 LM: Loss Measurement. 141 MPLS: Multiprotocol Label Switching. 143 PM: Performance Measurement. 145 PTP: Precision Time Protocol. 147 SID: Segment ID. 149 SR: Segment Routing. 151 TC: Traffic Class. 153 TE: Traffic Engineering. 155 URO: UDP Return Object. 157 2.2. Reference Topology 159 In the reference topology shown in Figure 1, the querier node R1 160 initiates a performance measurement probe query and the responder 161 node R5 sends a probe response for the query message received. The 162 probe response is sent to the querier node R1. The nodes R1 and R5 163 may be directly connected via a link enabled with Segment Routing or 164 there exists an SR Policy [I-D.spring-segment-routing-policy] on node 165 R1 with destination to node R5. 167 +-------+ Query +-------+ 168 | | - - - - - - - - - ->| | 169 | R1 |---------------------| R5 | 170 | |<- - - - - - - - - - | | 171 +-------+ Response +-------+ 173 Figure 1: Reference Topology 175 Both delay and loss performance measurement is performed for the 176 traffic traversing between node R1 and node R5. One-way delay and 177 two-way delay measurements are defined in Section 2.4 of [RFC6374]. 178 Transmit and Receive packet loss measurements are defined in Section 179 2.2 of [RFC6374]. One-way loss measurement provides transmit packet 180 loss whereas two-way loss measurement provides both transmit and 181 receive packet loss. 183 3. Probe Query and Response Packets 185 3.1. Probe Packet Header for SR-MPLS Policies 187 As described in Section 2.9.1 of [RFC6374], MPLS PM probe query and 188 response messages flow over the MPLS Generic Associated Channel (G- 189 ACh). A probe packet for an end-to-end measurement for SR Policy 190 contains SR-MPLS label stack [I-D.spring-segment-routing-policy], 191 with the G-ACh Label (GAL) at the bottom of the stack. The GAL is 192 followed by an Associated Channel Header (ACH), which identifies the 193 message type and the message payload following the ACH as shown in 194 Figure 2. 196 0 1 2 3 197 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 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Label(0) | EXP |S| TTL | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 . . 202 . . 203 . . 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Label(n) | EXP |S| TTL | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | GAL | EXP |S| TTL | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 |0 0 0 1|Version| Reserved | GAL Channel Type | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 Figure 2: Probe Packet Header for an End-to-end SR-MPLS Policy 214 The SR-MPLS label stack can be empty to indicate Implicit NULL label 215 case. 217 3.2. Probe Packet Header for SR-MPLS Links 219 As described in Section 2.9.1 of [RFC6374], MPLS PM probe query and 220 response messages flow over the MPLS Generic Associated Channel (G- 221 ACh). A probe packet for SR-MPLS links contains G-ACh Label (GAL). 222 The GAL is followed by an Associated Channel Header (ACH), which 223 identifies the message type, and the message payload following the 224 ACH as shown in Figure 3. 226 0 1 2 3 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | GAL | EXP |S| TTL | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 |0 0 0 1|Version| Reserved | GAL Channel Type | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 Figure 3: Probe Packet Header for an SR-MPLS Link 236 3.3. Probe Response Message for SR-MPLS Links and Policies 238 3.3.1. One-way Measurement Probe Response Message 240 For one-way performance measurement [RFC7679], the PM querier node 241 can receive "out-of-band" probe replies by properly setting the UDP 242 Return Object (URO) TLV in the probe query message. The URO TLV 243 (Type=131) is defined in [RFC7876] and includes the 244 UDP-Destination-Port and IP Address. In particular, if the querier 245 sets its own IP address in the URO TLV, the probe response is sent 246 back by the responder node to the querier node. In addition, the 247 "control code" in the probe query message is set to "out-of-band 248 response requested". 250 3.3.2. Two-way Measurement Probe Response Message 252 For two-way performance measurement [RFC6374], when using a 253 bidirectional channel, the probe response message is sent back to the 254 querier node in-band on the reverse direction SR Link or SR Policy 255 using a message with format similar to their probe query message. In 256 this case, the "control code" in the probe query message is set to 257 "in-band response requested". 259 4. Performance Delay Measurement 261 4.1. Delay Measurement Message Format 263 As defined in [RFC6374], MPLS DM probe query and response messages 264 use Associated Channel Header (ACH) (value 0x000C for delay 265 measurement) [RFC6374], which identifies the message type, and the 266 message payload following the ACH. For both SR links and end-to-end 267 measurement for SR Policies, the same MPLS DM ACH value is used. 269 The DM message payload as defined in [RFC6374] is used for SR-MPLS 270 delay measurement, for both SR links and end-to-end SR Policies. The 271 DM message payload format is defined as following in [RFC6374]: 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 |Version| Flags | Control Code | Message Length | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | QTF | RTF | RPTF | Reserved | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Session Identifier | DS | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Timestamp 1 | 283 | | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 . . 286 . . 287 . . 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Timestamp 4 | 290 | | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 ~ TLV Block ~ 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 Figure 4: Delay Measurement Message Payload Format 297 The meanings of the fields are summarized in the following table, see 298 [RFC6374] for details. 300 Field Meaning 301 ------------------- ---------------------------------------------- 302 Version Protocol version 304 Flags Message control flags 306 Control Code Code identifying the query or response type 308 QTF Querier timestamp format 309 (see Section 3.4 of [RFC6374]) 311 RTF Responder timestamp format 312 (see Section 3.4 of [RFC6374]) 314 RPTF Responder's preferred timestamp format 316 Reserved Reserved for future specification 318 Session Identifier Set arbitrarily by the querier 320 Differentiated Differentiated Services Code Point (DSCP) 321 Services (DS) Field being measured 323 Timestamp 1-4 64-bit timestamp values 324 (see Section 3.4 of [RFC6374]) 326 TLV Block Optional block of Type-Length-Value fields 328 4.2. Timestamp 330 The Section 3.4 of [RFC6374] defines timestamp format that can be 331 used for delay measurement. The IEEE 1588 Precision Time Protocol 332 (PTP) timestamp format [IEEE1588] is used by default as described in 333 Appendix A of [RFC6374], but it may require hardware support. As an 334 alternative, Network Time Protocol (NTP) timestamp format can also be 335 used [RFC6374]. 337 Note that for one-way delay measurement, clock synchronization 338 between the querier and responder nodes using the methods detailed in 339 [RFC6374] is required. The two-way delay measurement does not 340 require clock to be synchronized between the querier and responder 341 nodes. 343 5. Performance Loss Measurement 345 The LM protocol can perform two distinct kinds of loss measurement as 346 described in Section 2.9.8 of [RFC6374]. 348 o In inferred mode, LM will measure the loss of specially generated 349 test messages in order to infer the approximate data plane loss 350 level. Inferred mode LM provides only approximate loss 351 accounting. 353 o In direct mode, LM will directly measure data plane packet loss. 354 Direct mode LM provides perfect loss accounting, but may require 355 hardware support. 357 For both of these modes of LM, path segment identifier 358 [I-D.spring-mpls-path-segment] can be used for measuring traffic on 359 the egress node. 361 5.1. Loss Measurement Message Format 363 As defined in [RFC6374], MPLS LM probe query and response messages 364 use Associated Channel Header (ACH) (value 0x000A for direct loss 365 measurement or value 0x000B for inferred loss measurement), which 366 identifies the message type, and the message payload following the 367 ACH. For both SR links and end-to-end measurement for SR Policies, 368 the same MPLS LM ACH value is used. 370 The LM message payload as defined in [RFC6374] is used for SR-MPLS 371 loss measurement, for both SR links and end-to-end SR Policies. The 372 LM message payload format is defined as following in [RFC6374]: 374 0 1 2 3 375 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 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 |Version| Flags | Control Code | Message Length | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | DFlags| OTF | Reserved | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Session Identifier | DS | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Origin Timestamp | 384 | | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Counter 1 | 387 | | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 . . 390 . . 391 . . 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Counter 4 | 394 | | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 ~ TLV Block ~ 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 Figure 5: Loss Measurement Message Payload Format 401 The meanings of the fields are summarized in the following table, see 402 [RFC6374] for details. 404 Field Meaning 405 -------------------- ---------------------------------------------- 406 Version Protocol version 408 Flags Message control flags 410 Control Code Code identifying the query or response type 412 Message Length Total length of this message in bytes 414 Data Format Flags Flags specifying the format of message data 415 (DFlags) 417 Origin Timestamp Format of the Origin Timestamp field 418 Format (OTF) 420 Reserved Reserved for future specification 421 Session Identifier Set arbitrarily by the querier 423 Differentiated Differentiated Services Code Point (DSCP) 424 Services (DS) Field being measured 426 Origin Timestamp 64-bit field for query message transmission 427 timestamp 429 Counter 1-4 64-bit fields for LM counter values 431 TLV Block Optional block of Type-Length-Value fields 433 6. SR Link Extended TE Metrics Advertisements 435 The extended TE metrics for SR link delay and loss computed using the 436 performance measurement procedures reviewed in this document can be 437 advertised in the routing domain as follows: 439 o For OSPF, ISIS, and BGP-LS, protocol extensions defined in 440 [RFC7471], [RFC7810] [I-D.lsr-isis-rfc7810bis], and 441 [I-D.idr-te-pm-bgp] are used, respectively for advertising the 442 extended TE link metrics in the network. 444 o The extended link delay metrics advertised are minimum-delay, 445 maximum-delay, average-delay and delay-variance for one-way. 447 o The delay-variance is computed as specified in Section 4.2 of 448 [RFC5481]. 450 o The one-way delay metrics can be computed using two-way 451 measurement by dividing the measured delay values by 2. 453 o The extended TE link loss metric advertised is one-way percentage 454 packet loss. 456 7. Security Considerations 458 This document reviews the procedures for performance measurement for 459 SR-MPLS networks, for both SR-MPLS links and end-to-end SR-MPLS 460 Policies using the mechanisms defined in [RFC6374]. This document 461 does not introduce any additional security considerations other than 462 those covered in [RFC6374], [RFC7471], [RFC7810]. 464 8. IANA Considerations 465 This document does not require any IANA actions. 467 9. References 469 9.1. Normative References 471 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 472 Measurement for MPLS networks', RFC 6374, September 2011. 474 [RFC7876] Bryant, S., Sivabalan, S., and Soni, S., "UDP Return Path 475 for Packet Loss and Delay Measurement for MPLS Networks", 476 RFC 7876, July 2016. 478 9.2. Informative References 480 [IEEE1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock 481 Synchronization Protocol for Networked Measurement and 482 Control Systems", March 2008. 484 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 485 Zekauskas, "A One-way Active Measurement Protoco (OWAMP)", 486 RFC 4656, September 2006. 488 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 489 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 490 RFC 5357, October 2008. 492 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 493 Applicability Statement", RFC 5481, March 2009. 495 [RFC7679] Almes, G., et al., "A One-Way Delay Metric for IP 496 Performance Metrics (IPPM)', RFC 7679, January 2016. 498 [RFC7471] Giacalone, S., et al., "OSPF Traffic Engineering (TE) 499 Metric Extensions", RFC 7471, March 2015. 501 [RFC7810] Previdi, S., et al., "IS-IS Traffic Engineering (TE) 502 Metric Extensions", RFC 7810, May 2016. 504 [I-D.lsr-isis-rfc7810bis] Ginsberg, L., et al., "IS-IS Traffic 505 Engineering (TE) Metric Extensions", 506 draft-ietf-lsr-isis-rfc7810bis, work in progress. 508 [I-D.idr-te-pm-bgp] Ginsberg, L. Ed., et al., "BGP-LS Advertisement 509 of IGP Traffic Engineering Performance Metric Extensions", 510 draft-ietf-idr-te-pm-bgp, work in progress. 512 [I-D.spring-segment-routing-policy] Filsfils, C., et al., "Segment 513 Routing Policy Architecture", 514 draft-ietf-spring-segment-routing-policy, work in 515 progress. 517 [I-D.spring-mpls-path-segment] Cheng, W., et al., 'Path Segment in 518 MPLS Based Segment Routing Network', 519 draft-cheng-spring-mpls-path-segment, work in progress. 521 Acknowledgments 523 To be added. 525 Contributors 527 Patrick Khordoc 528 Cisco Systems, Inc. 529 Email: pkhordoc@cisco.com 531 Zafar Ali 532 Cisco Systems, Inc. 533 Email: zali@cisco.com 535 Daniel Bernier 536 Bell Canada 537 Email: daniel.bernier@bell.ca 539 Authors' Addresses 541 Rakesh Gandhi (editor) 542 Cisco Systems, Inc. 543 Canada 544 Email: rgandhi@cisco.com 546 Clarence Filsfils 547 Cisco Systems, Inc. 548 Email: cfilsfil@cisco.com 550 Sagar Soni 551 Cisco Systems, Inc. 552 Email: sagsoni@cisco.com 554 Daniel Voyer 555 Bell Canada 556 Email: daniel.voyer@bell.ca 558 Stefano Salsano 559 Universita di Roma "Tor Vergata" 560 Italy 561 Email: stefano.salsano@uniroma2.it 563 Pier Luigi Ventre 564 CNIT 565 Italy 566 Email: pierluigi.ventre@cnit.it 568 Mach(Guoyi) Chen 569 Huawei 570 Email: mach.chen@huawei.com