idnits 2.17.1 draft-gandhi-spring-rfc6374-srpm-mpls-01.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 (May 15, 2019) is 1805 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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 Cisco Systems, Inc. 5 Expires: November 16, 2019 D. Voyer 6 Bell Canada 7 S. Salsano 8 Universita di Roma "Tor Vergata" 9 P. L. Ventre 10 CNIT 11 M. Chen 12 Huawei 13 May 15, 2019 15 Performance Measurement for 16 Segment Routing Networks with MPLS Data Plane 17 draft-gandhi-spring-rfc6374-srpm-mpls-01 19 Abstract 21 RFC 6374 specifies protocol mechanisms to enable the efficient and 22 accurate measurement of packet loss, one-way and two-way delay, as 23 well as related metrics such as delay variation in MPLS networks 24 using synthetic probe messages. This document reviews how these 25 mechanisms can be used for Performance Delay and Loss Measurements in 26 Segment Routing (SR) networks with MPLS data plane (SR-MPLS), for 27 both SR links and end-to-end SR Policies. The Performance 28 Measurements (PM) for SR links are used to compute extended Traffic 29 Engineering (TE) metrics for delay and loss and can be advertised in 30 the network using the routing protocol extensions. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 66 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 67 2.2. Reference Topology . . . . . . . . . . . . . . . . . . . . 4 68 3. Probe Query and Response Packets . . . . . . . . . . . . . . . 5 69 3.1. Probe Packet Header for SR-MPLS Policies . . . . . . . . . 5 70 3.2. Probe Packet Header for SR-MPLS Links . . . . . . . . . . 6 71 3.3. Probe Response Message for SR-MPLS Links and Policies . . 6 72 3.3.1. One-way Measurement Mode . . . . . . . . . . . . . . . 6 73 3.3.2. Two-way Measurement Mode . . . . . . . . . . . . . . . 7 74 3.3.2.1. Return Path TLV . . . . . . . . . . . . . . . . . 7 75 3.3.3. Loopback Measurement Mode . . . . . . . . . . . . . . 7 76 4. Performance Delay Measurement . . . . . . . . . . . . . . . . 7 77 4.1. Delay Measurement Message Format . . . . . . . . . . . . . 7 78 4.2. Timestamps . . . . . . . . . . . . . . . . . . . . . . . . 8 79 5. Performance Loss Measurement . . . . . . . . . . . . . . . . . 8 80 5.1. Loss Measurement Message Format . . . . . . . . . . . . . 9 81 5.1.1. Block Number TLV . . . . . . . . . . . . . . . . . . . 9 82 6. Performance Measurement for P2MP SR Policies . . . . . . . . . 9 83 7. ECMP for SR-MPLS Policies . . . . . . . . . . . . . . . . . . 10 84 8. SR Link Extended TE Metrics Advertisements . . . . . . . . . . 10 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 86 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 89 11.2. Informative References . . . . . . . . . . . . . . . . . 11 90 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 94 1. Introduction 96 Service provider's ability to satisfy Service Level Agreements (SLAs) 97 depend on the ability to measure and monitor performance metrics for 98 packet loss and one-way and two-way delay, as well as related metrics 99 such as delay variation. The ability to monitor these performance 100 metrics also provides operators with greater visibility into the 101 performance characteristics of their networks, thereby facilitating 102 planning, troubleshooting, and network performance evaluation. 104 [RFC6374] specifies protocol mechanisms to enable the efficient and 105 accurate measurement of performance metrics in MPLS networks using 106 probe messages. The One-Way Active Measurement Protocol (OWAMP) 107 defined in [RFC4656] and Two-Way Active Measurement Protocol (TWAMP) 108 defined in [RFC5357] provide capabilities for the measurement of 109 various performance metrics in IP networks. However, mechanisms 110 defined in [RFC6374] are more suitable for Segment Routing (SR) when 111 using MPLS data plane (SR-MPLS). [RFC6374] also supports IEEE 1588 112 timestamps [IEEE1588] and "direct mode" Loss Measurement (LM), which 113 are required in SR networks. 115 [RFC7876] specifies the procedures to be used when sending and 116 processing out-of-band performance measurement probe replies over an 117 UDP return path when receiving RFC 6374 based probe queries. These 118 procedures can be used to send out-of-band PM replies for both 119 SR-MPLS links and Policies [I-D.spring-segment-routing-policy] for 120 one-way measurement. 122 This document reviews how synthetic probe-based mechanisms defined in 123 [RFC6374] can be used for Performance Delay and Loss Measurements in 124 SR networks with MPLS data plane, for both SR links and end-to-end SR 125 Policies. The Performance Measurements (PM) for SR links are used to 126 compute extended Traffic Engineering (TE) metrics for delay and loss 127 and can be advertised in the network using the routing protocol 128 extensions. 130 2. Conventions Used in This Document 132 2.1. Abbreviations 134 ACH: Associated Channel Header. 136 DM: Delay Measurement. 138 ECMP: Equal Cost Multi-Path. 140 G-ACh: Generic Associated Channel (G-ACh). 142 GAL: Generic Associated Channel (G-ACh) Label. 144 LM: Loss Measurement. 146 MPLS: Multiprotocol Label Switching. 148 NTP: Network Time Protocol. 150 PM: Performance Measurement. 152 PSID: Path Segment Identifier. 154 PTP: Precision Time Protocol. 156 SID: Segment ID. 158 SL: Segment List. 160 SR: Segment Routing. 162 SR-MPLS: Segment Routing with MPLS data plane. 164 TC: Traffic Class. 166 TE: Traffic Engineering. 168 URO: UDP Return Object. 170 2.2. Reference Topology 172 In the reference topology shown in Figure 1, the querier node R1 173 initiates a performance measurement probe query and the responder 174 node R5 sends a probe response for the query message received. The 175 probe response is typically sent back to the querier node R1. The 176 nodes R1 and R5 may be directly connected via a link enabled with 177 Segment Routing or there exists a Point-to-Point (P2P) SR Policy 178 [I-D.spring-segment-routing-policy] on node R1 with destination to 179 node R5. In case of Point-to-Multipoint (P2MP), SR Policy 180 originating from source node R1 may terminate on multiple destination 181 leaf nodes [I-D.spring-sr-p2mp-policy]. 183 +-------+ Query +-------+ 184 | | - - - - - - - - - ->| | 185 | R1 |---------------------| R5 | 186 | |<- - - - - - - - - - | | 187 +-------+ Response +-------+ 189 Figure 1: Reference Topology 191 For delay and loss measurements, for both links and end-to-end SR 192 Policies, no PM session is created on the responder node R5. One-way 193 delay and two-way delay measurements are defined in Section 2.4 of 194 [RFC6374]. Transmit and Receive packet loss measurements are defined 195 in Section 2.2 and Section 2.6 of [RFC6374]. One-way loss 196 measurement provides receive packet loss whereas two-way loss 197 measurement provides both transmit and receive packet loss. 199 For Performance Measurement, synthetic probe query and response 200 messages are used as following: 202 o For Delay Measurement, the probe messages are sent on the 203 congruent path of the data traffic by the querier node, and are 204 used to measure the delay experienced by the actual data traffic 205 flowing on the links and SR Policies. 207 o For Loss Measurement, the probe messages are sent on the congruent 208 path of the data traffic by the querier node, and are used to 209 collect the receive traffic counters for the incoming link or 210 incoming SID where the probe query messages are received at the 211 responder node (incoming link or incoming SID used as the 212 responder node has no PM session state present). 214 The In-Situ Operations, Administration, and Maintenance (IOAM) 215 mechanisms for SR-MPLS defined in [I-D.spring-ioam-sr-mpls] are used 216 to carry PM information in-band as part of the data traffic, and are 217 outside the scope of this document. 219 3. Probe Query and Response Packets 221 3.1. Probe Packet Header for SR-MPLS Policies 223 As described in Section 2.9.1 of [RFC6374], MPLS PM probe query and 224 response messages flow over the MPLS Generic Associated Channel 225 (G-ACh). A probe packet for an end-to-end measurement for SR Policy 226 contains SR-MPLS label stack [I-D.spring-segment-routing-policy], 227 with the G-ACh Label (GAL) at the bottom of the stack (with S=1). 228 The GAL is followed by an Associated Channel Header (ACH), which 229 identifies the message type, and the message payload following the 230 ACH as shown in Figure 2. 232 0 1 2 3 233 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 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Label(1) | TC |S| TTL | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 . . 238 . . 239 . . 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Label(n) | TC |S| TTL | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | GAL (value 13) | TC |S| TTL | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 |0 0 0 1|Version| Reserved | GAL Channel Type | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Figure 2: Probe Packet Header for an End-to-end SR-MPLS Policy 250 The SR-MPLS label stack can be empty (as shown in Figure 3) to 251 indicate Implicit NULL label case. 253 3.2. Probe Packet Header for SR-MPLS Links 255 As described in Section 2.9.1 of [RFC6374], MPLS PM probe query and 256 response messages flow over the MPLS Generic Associated Channel 257 (G-ACh). A probe packet for SR-MPLS links contains G-ACh Label (GAL) 258 (with S=1). The GAL is followed by an Associated Channel Header 259 (ACH), which identifies the message type, and the message payload 260 following the ACH as shown in Figure 3. 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | GAL (value 13) | TC |S| TTL | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 |0 0 0 1|Version| Reserved | GAL Channel Type | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Figure 3: Probe Packet Header for an SR-MPLS Link 272 3.3. Probe Response Message for SR-MPLS Links and Policies 274 3.3.1. One-way Measurement Mode 276 In one-way performance measurement mode [RFC7679], the PM querier 277 node can receive "out-of-band" probe replies by properly setting the 278 UDP Return Object (URO) TLV in the probe query message. The URO TLV 279 (Type=131) is defined in [RFC7876] and includes the 280 UDP-Destination-Port and IP Address. In particular, if the querier 281 sets its own IP address in the URO TLV, the probe response is sent 282 back by the responder node to the querier node. In addition, the 283 "control code" in the probe query message is set to "out-of-band 284 response requested". The "Source Address" TLV (Type 130), and 285 "Return Address" TLV (Type 1), if present in the probe query message, 286 are not used to send probe response message. 288 3.3.2. Two-way Measurement Mode 290 In two-way performance measurement mode [RFC6374], when using a 291 bidirectional path, the probe response message is sent back to the 292 querier node on the congruent path of the data traffic on the reverse 293 direction SR Link or SR Policy using a message with format similar to 294 their probe query message. In this case, the "control code" in the 295 probe query message is set to "in-band response requested". 297 A Path Segment Identifier (PSID) [I-D.spring-mpls-path-segment] of 298 the forward SR-MPLS Policy can be used to find the reverse SR-MPLS 299 Policy and to send back the probe response message for two-way 300 measurement. 302 3.3.2.1. Return Path TLV 304 For two-way performance measurement, the querier node can request the 305 responder node to send a response message back on a given reverse 306 path (typically co-routed path for two-way measurement). Return Path 307 TLV defined in [I-D.spring-rfc6374-srpm-udp] can be used to carry 308 reverse SR path information as part of the payload of the probe query 309 message. 311 3.3.3. Loopback Measurement Mode 313 The Loopback measurement mode defined in Section 2.8 of [RFC6374] can 314 be used to measure round-trip delay for a bidirectional SR Path. The 315 probe query messages in this case carries the reverse SR Path label 316 stack as part of the MPLS header. The GAL is still carried at the 317 bottom of the label stack (with S=1). The responder node does not 318 process the PM probe messages and generate response messages. 320 4. Performance Delay Measurement 322 4.1. Delay Measurement Message Format 323 As defined in [RFC6374], MPLS DM probe query and response messages 324 use Associated Channel Header (ACH) (value 0x000C for delay 325 measurement) [RFC6374], which identifies the message type, and the 326 message payload following the ACH. For both SR links and end-to-end 327 measurement for SR-MPLS Policies, the same MPLS DM ACH value is used. 329 The DM message payload as defined in Section 3.2 of [RFC6374] is used 330 for SR-MPLS delay measurement, for both SR links and end-to-end SR 331 Policies. 333 4.2. Timestamps 335 The Section 3.4 of [RFC6374] defines timestamp format that can be 336 used for delay measurement. The IEEE 1588 Precision Time Protocol 337 (PTP) timestamp format [IEEE1588] is used by default as described in 338 Appendix A of [RFC6374], preferred with hardware support. As an 339 alternative, Network Time Protocol (NTP) timestamp format can also be 340 used [RFC6374]. 342 Note that for one-way delay measurement mode, clock synchronization 343 between the querier and responder nodes using the methods detailed in 344 [RFC6374] is required. The two-way delay measurement mode and 345 loopback measurement mode do not require clock synchronization 346 between the querier and responder nodes. 348 5. Performance Loss Measurement 350 The LM protocol can perform two distinct kinds of loss measurement as 351 described in Section 2.9.8 of [RFC6374]. 353 o In inferred mode, LM will measure the loss of specially generated 354 test messages in order to infer the approximate data plane loss 355 level. Inferred mode LM provides only approximate loss 356 accounting. 358 o In direct mode, LM will directly measure data plane packet loss. 359 Direct mode LM provides perfect loss accounting, but may require 360 hardware support. 362 For both of these modes of LM, Path Segment Identifier (PSID) 363 [I-D.spring-mpls-path-segment] is used for accounting received 364 traffic on the egress node of the SR-MPLS Policy as shown in Figure 365 4. Different values of PSID can be used to measure packet loss per 366 SR-MPLS Policy, per Candidate Path or per Segment List of the SR 367 Policy. 369 0 1 2 3 370 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 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | PSID | TC |S| TTL | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | GAL (value 13) | TC |S| TTL | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 |0 0 0 1|Version| Reserved | GAL Channel Type | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 Figure 4: With Path Segment Identifier for SR-MPLS Policy 381 5.1. Loss Measurement Message Format 383 As defined in [RFC6374], MPLS LM probe query and response messages 384 use Associated Channel Header (ACH) (value 0x000A for direct loss 385 measurement or value 0x000B for inferred loss measurement), which 386 identifies the message type, and the message payload following the 387 ACH. For both SR links and end-to-end measurement for SR-MPLS 388 Policies, the same MPLS LM ACH value is used. 390 The LM message payload as defined in Section 3.1 of [RFC6374] is used 391 for SR-MPLS loss measurement, for both SR links and end-to-end SR 392 Policies. 394 5.1.1. Block Number TLV 396 The Loss Measurement using Alternate-Marking method defined in 397 [RFC8321] requires to identify the Block Number (or color) of the 398 traffic counters carried by the probe query and response messages. 399 Block Number TLV defined in [I-D.spring-rfc6374-srpm-udp] is used to 400 carry Block Number for the traffic counters in the probe query and 401 response messages for loss measurement. 403 6. Performance Measurement for P2MP SR Policies 405 The procedures for delay and loss measurement reviewed in this 406 document for Point-to-Point (P2P) SR-MPLS Policies 407 [I-D.spring-segment-routing-policy] are also equally applicable to 408 the Point-to-Multipoint (P2MP) SR-MPLS Policies 409 [I-D.spring-sr-p2mp-policy] as following: 411 o The querier root node sends probe query messages using the either 412 Spray P2MP segment or TreeSID P2MP segment defined in 413 [I-D.spring-sr-p2mp-policy] over the P2MP SR Policy as shown in 414 Figure 5. 416 o Each responder leaf node adds the "Source Address" TLV (Type 130) 417 [RFC6374] with its IP address in the probe response messages. 418 This TLV allows the querier root node to identify the responder 419 leaf nodes of the P2MP SR Policy. 421 o The P2MP root node measures the end-to-end delay and loss 422 performance for each P2MP leaf node. 424 0 1 2 3 425 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 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | TreeSID OR Spray SID | TC |S| TTL | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | GAL (value 13) | TC |S| TTL | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 |0 0 0 1|Version| Reserved | GAL Channel Type | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 Figure 5: With P2MP Segment Identifier for SR-MPLS Policy 436 7. ECMP for SR-MPLS Policies 438 An SR Policy can have ECMPs between the source and transit nodes, 439 between transit nodes and between transit and destination nodes. 440 Usage of Anycast SID [RFC8402] by an SR Policy can result in ECMP 441 paths via transit nodes part of that Anycast group. The PM probe 442 messages need to be sent to traverse different ECMP paths to measure 443 performance delay of an SR Policy. 445 Forwarding plane has various hashing functions available to forward 446 packets on specific ECMP paths. For SR-MPLS Policy, entropy label 447 [RFC6790] can be used in PM probe messages to take advantage of the 448 hashing function in forwarding plane to influence the ECMP path taken 449 by them. 451 8. SR Link Extended TE Metrics Advertisements 453 The extended TE metrics for SR link delay and loss computed using the 454 performance measurement procedures reviewed in this document can be 455 advertised in the routing domain as follows: 457 o For OSPF, ISIS, and BGP-LS, protocol extensions defined in 458 [RFC7471], [RFC8570], and [RFC8571] are used, respectively for 459 advertising the extended TE link metrics in the network. 461 o The extended TE link delay metrics advertised are minimum-delay, 462 maximum-delay, average-delay, and delay-variance for one-way. 464 o The delay-variance metric is computed as specified in Section 4.2 465 of [RFC5481]. 467 o The one-way delay metrics can be computed using two-way delay 468 measurement or round-trip delay measurement from loopback mode by 469 dividing the measured delay values by 2. 471 o The extended TE link loss metric advertised is one-way percentage 472 packet loss. 474 9. Security Considerations 476 This document reviews the procedures for performance delay and loss 477 measurement for SR-MPLS networks, for both links and end-to-end SR 478 Policies using the mechanisms defined in [RFC6374] and [RFC7876]. 479 This document does not introduce any additional security 480 considerations other than those covered in [RFC6374], [RFC7471], 481 [RFC8570], [RFC8571], and [RFC7876]. 483 10. IANA Considerations 485 This document does not require any IANA actions. 487 11. References 489 11.1. Normative References 491 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 492 Measurement for MPLS networks', RFC 6374, September 2011. 494 [RFC7876] Bryant, S., Sivabalan, S., and Soni, S., "UDP Return Path 495 for Packet Loss and Delay Measurement for MPLS Networks", 496 RFC 7876, July 2016. 498 11.2. Informative References 500 [IEEE1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock 501 Synchronization Protocol for Networked Measurement and 502 Control Systems", March 2008. 504 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 505 Zekauskas, "A One-way Active Measurement Protocol 506 (OWAMP)", RFC 4656, September 2006. 508 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 509 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 510 RFC 5357, October 2008. 512 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 513 Applicability Statement", RFC 5481, March 2009. 515 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 516 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 517 RFC 6790, November 2012. 519 [RFC7679] Almes, G., et al., "A One-Way Delay Metric for IP 520 Performance Metrics (IPPM)', RFC 7679, January 2016. 522 [RFC7471] Giacalone, S., et al., "OSPF Traffic Engineering (TE) 523 Metric Extensions", RFC 7471, March 2015. 525 [RFC8321] Fioccola, G. Ed., "Alternate-Marking Method for Passive 526 and Hybrid Performance Monitoring", RFC 8321, January 527 2018. 529 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 530 Decraene, B., Litkowski, S., and R. Shakir, "Segment 531 Routing Architecture", RFC 8402, July 2018. 533 [RFC8570] Ginsberg, L. Ed., et al., "IS-IS Traffic Engineering (TE) 534 Metric Extensions", RFC 8570, March 2019. 536 [RFC8571] Ginsberg, L. Ed., et al., "BGP - Link State (BGP-LS) 537 Advertisement of IGP Traffic Engineering Performance 538 Metric Extensions", RFC 8571, March 2019. 540 [I-D.spring-segment-routing-policy] Filsfils, C., et al., "Segment 541 Routing Policy Architecture", 542 draft-ietf-spring-segment-routing-policy, work in 543 progress. 545 [I-D.spring-sr-p2mp-policy] Voyer, D. Ed., et al., "SR Replication 546 Policy for P2MP Service Delivery", 547 draft-voyer-spring-sr-p2mp-policy, work in progress. 549 [I-D.spring-mpls-path-segment] Cheng, W., et al., "Path Segment in 550 MPLS Based Segment Routing Network", 551 draft-ietf-spring-mpls-path-segment, work in progress. 553 [I-D.spring-rfc6374-srpm-udp] Gandhi, R. Ed., et al., "Performance 554 Measurement Using UDP Path for Segment Routing Networks", 555 draft-gandhi-spring-rfc6374-srpm-udp, work in progress. 557 [I-D.spring-ioam-sr-mpls] Gandhi, R. Ed., et al., "Segment Routing 558 with MPLS Data Plane Encapsulation for In-situ OAM Data", 559 draft-gandhi-spring-ioam-sr-mpls, work in progress. 561 Acknowledgments 563 The authors would like to thank Thierry Couture for various 564 discussions on the use-cases for the performance measurement in 565 segment routing networks. The authors would like to thank Greg 566 Mirsky for providing many useful comments and suggestions. The 567 authors would also like to thank Stewart Bryant and Rajiv Asati for 568 their review comments. 570 Contributors 572 Sagar Soni 573 Cisco Systems, Inc. 574 Email: sagsoni@cisco.com 576 Patrick Khordoc 577 Cisco Systems, Inc. 578 Email: pkhordoc@cisco.com 580 Zafar Ali 581 Cisco Systems, Inc. 582 Email: zali@cisco.com 584 Authors' Addresses 586 Rakesh Gandhi (editor) 587 Cisco Systems, Inc. 588 Canada 589 Email: rgandhi@cisco.com 591 Clarence Filsfils 592 Cisco Systems, Inc. 593 Email: cfilsfil@cisco.com 595 Daniel Voyer 596 Bell Canada 597 Email: daniel.voyer@bell.ca 599 Stefano Salsano 600 Universita di Roma "Tor Vergata" 601 Italy 602 Email: stefano.salsano@uniroma2.it 604 Pier Luigi Ventre 605 CNIT 606 Italy 607 Email: pierluigi.ventre@cnit.it 609 Mach(Guoyi) Chen 610 Huawei 611 Email: mach.chen@huawei.com