idnits 2.17.1 draft-gandhi-spring-sr-enhanced-plm-00.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 (March 5, 2020) is 1514 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 (-11) exists of draft-gandhi-spring-twamp-srpm-05 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-06 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-10 == Outdated reference: A later version (-16) exists of draft-ietf-pce-binding-label-sid-01 == Outdated reference: A later version (-13) exists of draft-ietf-pce-sr-bidir-path-01 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). 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: Standards Track Cisco Systems, Inc. 5 Expires: September 6, 2020 N. Vaghamshi 6 Reliance 7 M. Nagarajah 8 Telstra 9 March 5, 2020 11 Enhanced Performance and Liveness Monitoring in Segment Routing Networks 12 draft-gandhi-spring-sr-enhanced-plm-00 14 Abstract 16 Segment Routing (SR) leverages the source routing paradigm. SR is 17 applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 18 (SRv6) data planes. This document defines procedure for Enhanced 19 Performance and Liveness Monitoring (PLM) in Segment Routing 20 networks. The procedure uses the probe messages defined in RFC 5357 21 (Two-Way Active Measurement Protocol (TWAMP) Light) as well as STAMP 22 and is applicable to both SR-MPLS and SRv6 data planes. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 6, 2020. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 60 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Liveness Monitoring . . . . . . . . . . . . . . . . . . . . . 4 63 3.1. Loopback Mode for SR-MPLS . . . . . . . . . . . . . . . . 5 64 3.2. Loopback Mode for SRv6 . . . . . . . . . . . . . . . . . 6 65 4. Enhanced Performance and Liveness Monitoring . . . . . . . . 7 66 4.1. Loopback Mode Enabled with Network Programming for SR- 67 MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 4.1.1. Node Capability for Timestamp Label . . . . . . . . . 9 69 4.2. Loopback Mode Enabled with Network Programming for SRv6 . 9 70 5. ECMP Handling . . . . . . . . . . . . . . . . . . . . . . . . 10 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 75 8.2. Informative References . . . . . . . . . . . . . . . . . 12 76 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 79 1. Introduction 81 Segment Routing (SR) leverages the source routing paradigm and 82 greatly simplifies network operations for Software Defined Networks 83 (SDNs). SR is applicable to both Multiprotocol Label Switching (SR- 84 MPLS) and IPv6 (SRv6) data planes [RFC8402]. SR takes advantage of 85 the Equal-Cost Multipaths (ECMPs) between source and transit nodes, 86 between transit nodes and between transit and destination nodes. SR 87 Policies as defined in [I-D.ietf-spring-segment-routing-policy] are 88 used to steer traffic through a specific, user-defined paths using a 89 stack of Segments. Built-in Liveness Monitoring for detecting faults 90 as well as Performance Delay and Loss Monitoring are essential 91 requirements to provide Service Level Agreements (SLAs) in SR 92 networks. 94 The One-Way Active Measurement Protocol (OWAMP) defined in [RFC4656] 95 and Two-Way Active Measurement Protocol (TWAMP) defined in [RFC5357] 96 provide capabilities for the measurement of various performance 97 metrics in IP networks using probe messages. The TWAMP Light 98 [Appendix I in RFC 5357] provides simplified mechanisms for active 99 performance measurement in Customer IP networks by provisioning UDP 100 paths that eliminates the control-channel signaling. The Simple Two- 101 way Active Measurement Protocol (STAMP) [I-D.ietf-ippm-stamp] 102 alleviates the control-channel signaling by using configuration data 103 model to provision a test-channel. [I-D.gandhi-spring-twamp-srpm] 104 defines procedure for using TWAMP Light and STAMP messages with user- 105 defined IP/UDP paths in SR networks and is applicable to both SR-MPLS 106 and SRv6 data planes. 108 For Liveness Monitoring, Seamless Bidirectional Forwarding Detection 109 (S-BFD) [RFC7880] can be used in Segment Routing networks. However, 110 S-BFD requires protocol support on the reflector node to process the 111 S-BFD packets as packets are punted from forwarding path in order to 112 send reply thereby limiting the scale for number of sessions and 113 fault detection interval. In addition, S-BFD protocol does not have 114 the capability today to enable performance delay and loss monitoring 115 in SR networks. Enabling multiple protocols in SR networks, S-BFD 116 for liveness monitoring and TWAMP Light or STAMP for performance 117 delay and loss monitoring increases the operational complexity in SR 118 networks. 120 This document defines procedure for Enhanced Performance and Liveness 121 Monitoring (PLM) in Segment Routing networks. The procedure uses the 122 probe messages defined in [RFC5357] (Two-Way Active Measurement 123 Protocol (TWAMP) Light) as well as STAMP defined in 124 [I-D.ietf-ippm-stamp] in loopback mode. The procedure specified is 125 applicable to both SR-MPLS and SRv6 data planes. 127 The procedure defined in this document will be updated in a future 128 revision to include performance loss monitoring as well. 130 2. Conventions Used in This Document 132 2.1. Requirements Language 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119] [RFC8174] 137 when, and only when, they appear in all capitals, as shown here. 139 2.2. Abbreviations 141 BFD: Bidirectional Forwarding Detection. 143 BSID: Binding Segment ID. 145 DM: Delay Measurement. 147 ECMP: Equal Cost Multi-Path. 149 LM: Loss Measurement. 151 MPLS: Multiprotocol Label Switching. 153 OWAMP: One-Way Active Measurement Protocol. 155 PLM: Performance and Liveness Monitoring. 157 PM: Performance Measurement. 159 PTP: Precision Time Protocol. 161 SID: Segment ID. 163 SL: Segment List. 165 SR: Segment Routing. 167 SRH: Segment Routing Header. 169 SR-MPLS: Segment Routing with MPLS data plane. 171 SRv6: Segment Routing with IPv6 data plane. 173 STAMP: Simple Two-way Active Measurement Protocol. 175 TWAMP: Two-Way Active Measurement Protocol. 177 3. Liveness Monitoring 179 For liveness monitoring for an SR Policy, the loopback mode as 180 defined in Section 4.2.3 of [I-D.gandhi-spring-twamp-srpm] is used. 181 The TWAMP Light probe messages for delay measurement defined in 182 Section 4.2.1 of [RFC5357] or STAMP probe messages as defined in 183 [I-D.ietf-ippm-stamp] are sent by the sender (head-end) node R1 to 184 the reflector endpoint node R5 of the SR Policy using the user- 185 configured IP/UDP path as shown in Figure 1. 187 +-------+ t1 Probe +-------+ 188 | | - - - - - - - - - - | | 189 | R1 |--------------------|| R5 | 190 | |<- - - - - - - - - - | | 191 +-------+ t4 Return Probe +-------+ 192 Sender Reflector Endpoint 193 (Simply Forward) 195 Figure 1: Loopback Mode 197 The probe messages are sent using the Segment List (SL) of the SR 198 Policy. When an SR Policy has more than one Segment List, multiple 199 probe messages are sent, one using each Segment List. The Source and 200 Destination IP addresses in the probe messages are set to the 201 reflector endpoint and the sender head-end node addresses, 202 respectively. The IPv4 Time To Live (TTL), IPv6 Hop Limit (HL), 203 Router Alert (RA) Option and UDP checksum fields in the probe 204 messages are set using the procedures defined in 205 [I-D.gandhi-spring-twamp-srpm]. 207 The probe packets are not punted on the reflector node but are simply 208 forwarded just like data traffic. The probe messages are received 209 back by the sender node via IP/UDP [RFC0768] return path by default. 210 The Segment List of the return SR path can be added in the probe 211 message header to receive the probe message on a specific reverse 212 path using the mechanisms defined in [I-D.ietf-pce-binding-label-sid] 213 and [I-D.ietf-pce-sr-bidir-path]. In either case, the reflector node 214 must not drop the loopback probe messages, for example, due to a 215 local policy provisioned on the node. 217 Liveness failure is notified when consecutive N number of probe 218 messages are not received back at the sender, where N is locally 219 provisioned value. 221 3.1. Loopback Mode for SR-MPLS 223 The TWAMP Light or STAMP probe messages are sent using the label 224 stack of the SR Policy as shown in Figure 2 using the procedure 225 specified in [I-D.gandhi-spring-twamp-srpm]. The label stack can 226 contain a reverse SR-MPLS path to receive the reply on a specific 227 path. 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Label(1) | TC |S| TTL | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 . . 235 . . 236 . . 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Label(n) | TC |S| TTL | 239 +---------------------------------------------------------------+ 240 | IP Header | 241 . Source IP Address = Endpoint IPv4 or IPv6 Address . 242 . Destination IP Address = Sender IPv4 or IPv6 Address . 243 . Protocol = UDP . 244 . . 245 +---------------------------------------------------------------+ 246 | UDP Header | 247 . Source Port = As chosen by Sender . 248 . Destination Port = User-configured Port . 249 . . 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Payload as defined in Section 4.2.1 of RFC 5357 | 252 | Payload as defined in Section 4.2 of STAMP | 253 . . 254 +---------------------------------------------------------------+ 256 Figure 2: Probe Message Header for SR-MPLS 258 3.2. Loopback Mode for SRv6 260 The TWAMP Light or STAMP probe messages are sent using the SRH 261 containing the Segment Identifier (SID) List of the SR Policy as 262 shown in Figure 3 using the procedure specified in 263 [I-D.gandhi-spring-twamp-srpm]. The SID List can contain a reverse 264 SRv6 path to receive the reply on a specific path. 266 +---------------------------------------------------------------+ 267 | SRH | 268 . . 269 . . 270 +---------------------------------------------------------------+ 271 | IP Header | 272 . Source IP Address = Endpoint IPv6 Address . 273 . Destination IP Address = Sender IPv6 Address . 274 . Protocol = UDP . 275 . . 276 +---------------------------------------------------------------+ 277 | UDP Header | 278 . Source Port = As chosen by Sender . 279 . Destination Port = User-configured Port . 280 . . 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Payload as defined in Section 4.2.1 of RFC 5357 | 283 | Payload as defined in Section 4.2 of STAMP | 284 . . 285 +---------------------------------------------------------------+ 287 Figure 3: Probe Message Header for SRv6 289 4. Enhanced Performance and Liveness Monitoring 291 The enhanced performance and liveness monitoring for an SR Policy is 292 defined using the loopback mode enabled with network programming. 293 The network programming function optimizes the "operations of punt, 294 add receive timestamp and inject the probe packet" on the reflector 295 node and is implemented in hardware. In this mode, both transmit 296 (t1) and receive (t2) timestamps in data plane are collected by the 297 probe messages sent in loopback mode as shown in Figure 4. The 298 payload of the probe message is not modified by any intermediate 299 nodes. 301 +-------+ t1 Probe t2 +-------+ 302 | | - - - - - - - - - - | | 303 | R1 |--------------------|| R5 | 304 | |<- - - - - - - - - - | | 305 +-------+ Return Probe +-------+ 306 Sender Reflector Endpoint 307 (Timestamp, 308 Pop and Forward) 310 Figure 4: Loopback Mode Enabled with Network Programming 312 The sender node adds transmit (t1) timestamp in the payload of the 313 TWAMP Light or STAMP probe message and clears the receive (t2) 314 timestamp. The endpoint node adds the receive timestamp (at the 315 fixed location locally provisioned consistently in the network) in 316 the payload of the received TWAMP Light or STAMP probe message 317 without punting the probe message in control-plane. The reflector 318 endpoint node only adds the receive timestamp if the source address 319 in the probe message matches the local node address to ensure that 320 the receive timestamp is returned by the intended endpoint node. In 321 addition, the UDP port in the probe message must be locally 322 programmed for adding the timestamp in the probe message. The end- 323 to-end one-way delay is measured using the receive (t2) and transmit 324 (t1) timestamps in the probe message. 326 Timestamp format recommended is 64-bit PTPv2 [IEEE1588] as specified 327 in [RFC8186] implemented in hardware. Note that the timestamp format 328 can be locally provisioned as part of enabling the network 329 programming function. In addition to adding the timestamp in the 330 message, the "Error Estimate" field in the payload of the message is 331 updated using the procedure defined in [RFC4656]. 333 The network programming function is enabled to add receive timestamp 334 in the payload of the probe message at a specific location which is 335 also locally provisioned. In TWAMP Light message defined in 336 Section 4.2.1 of [RFC5357] or STAMP message defined in 337 [I-D.ietf-ippm-stamp] for delay measurement, the 64-bit receive 338 timestamp is added at byte-offset 16 which is from the start of the 339 payload. 341 Liveness failure is notified when consecutive N number of probe 342 messages are not received back at the sender, where N is locally 343 provisioned value. Similarly, delay metrics are notified when 344 consecutive M number of probe messages have measured delay values 345 violate user-configured threshold, where M is also locally 346 provisioned value. 348 4.1. Loopback Mode Enabled with Network Programming for SR-MPLS 350 In this document, new Timestamp Label (special purpose label with 351 value TBD1) is defined for SR-MPLS to enable network programming 352 function for timestamp, pop and forward the received packet. 354 In the loopback mode enabled with network programming for SR-MPLS, 355 Timestamp Label is added in the MPLS header as shown in Figure 5, to 356 collect "Receive Timestamp" field in the payload of the TWAMP Light 357 [RFC5357] or STAMP probe message. When a node receives a message 358 with Timestamp Label, other than timestamping the message at a fixed 359 location, the node pops the Timestamp Label and forwards the packet 360 using the next label or IP header in the packet (just like the 361 packets for the normal traffic). 363 0 1 2 3 364 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 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Label(1) | TC |S| TTL | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 . . 369 . . 370 . . 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Label(n) | TC |S| TTL | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Timestamp Label (TBA1) | TC |S| TTL | 375 +---------------------------------------------------------------+ 376 | IP Header | 377 . Source IP Address = Endpoint IPv4 or IPv6 Address . 378 . Destination IP Address = Sender IPv4 or IPv6 Address . 379 . Protocol = UDP . 380 . . 381 +---------------------------------------------------------------+ 382 | UDP Header | 383 . Source Port = As chosen by Sender . 384 . Destination Port = User-configured Port . 385 . . 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Payload as defined in Section 4.2.1 of RFC 5357 | 388 | Payload as defined in Section 4.2 of STAMP | 389 . . 390 +---------------------------------------------------------------+ 392 Figure 5: Probe Message Header for SR-MPLS with Timestamp Label 394 4.1.1. Node Capability for Timestamp Label 396 The ingress node needs to know if the egress node can process the 397 Timestamp Label. The signaling extension for this capability 398 exchange is outside the scope of this document. 400 Another way is to leverage a centralized controller (e.g., SDN 401 controller) to program the ingress and egress nodes. In this case, 402 the controller MUST make sure (e.g., by some capability discovery 403 mechanisms outside the scope of this document) that the egress node 404 can process the Timestamp Label. 406 4.2. Loopback Mode Enabled with Network Programming for SRv6 408 In this document, new Endpoint function "Timestamp and Forward (TSF)" 409 (value TBD2) is defined for Segment Routing Header (SRH) 411 [I-D.ietf-6man-segment-routing-header] for SRv6 to enable network 412 programming function for timestamp and forward the received message. 414 In the loopback mode enabled with network programming for SRv6, 415 END.TSF function is added for the Endpoint SID in SRH 416 [I-D.ietf-6man-segment-routing-header] as shown in Figure 6, to 417 collect "Receive Timestamp" field in the payload of the TWAMP Light 418 [RFC5357] or STAMP probe message. When a node receives a packet with 419 END.TSF function for the target SID which is local, other than 420 timestamping the packet at a fixed location, the node forwards the 421 packet using the next SID or IP header in the packet (just like the 422 packets for the normal traffic). 424 +---------------------------------------------------------------+ 425 | SRH | 426 . . 427 +---------------------------------------------------------------+ 428 | IP Header | 429 . Source IP Address = Endpoint IPv6 Address . 430 . Destination IP Address = Sender IPv6 Address . 431 . Protocol = UDP . 432 . . 433 +---------------------------------------------------------------+ 434 | UDP Header | 435 . Source Port = As chosen by Sender . 436 . Destination Port = User-configured Port . 437 . . 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Payload as defined in Section 4.2.1 of RFC 5357 | 440 | Payload as defined in Section 4.2 of STAMP | 441 . . 442 +---------------------------------------------------------------+ 444 Figure 6: Probe Message Header for SRv6 with Endpoint Function 446 5. ECMP Handling 448 An SR Policy can have ECMPs between the source and transit nodes, 449 between transit nodes and between transit and destination nodes. The 450 PM probe messages need to be sent to traverse different ECMP paths to 451 monitor the liveness for an SR Policy. 453 Forwarding plane has various hashing functions available to forward 454 packets on specific ECMP paths. In the IP header of the PM probe 455 messages, sweeping of Destination Addresses in 127/8 range for IPv4 456 or 0:0:0:0:0:FFFF:7F00/104 range for IPv6 can be used to exercise 457 different ECMP paths in loopback mode as long as the reverse path is 458 also an SR-MPLS or SRv6 path. The Flow Label field in the outer IPv6 459 header can also be used for sweeping ECMP paths. 461 6. Security Considerations 463 The Performance and Liveness Monitoring is intended for deployment in 464 the well-managed private and service provider networks. As such, it 465 assumes that a node involved in a monitoring operation has previously 466 verified the integrity of the path and the identity of the far-end 467 reflector node. If desired, attacks can be mitigated by performing 468 basic validation and sanity checks, at the sender, of the counter or 469 timestamp fields in received measurement response messages. The 470 minimal state associated with these protocols also limits the extent 471 of disruption that can be caused by a corrupt or invalid message to a 472 single query/response cycle. Use of HMAC-SHA-256 in the 473 authenticated mode protects the data integrity of the probe messages. 474 Cryptographic measures may be enhanced by the correct configuration 475 of access-control lists and firewalls. 477 7. IANA Considerations 479 IANA maintains the "Special-Purpose Multiprotocol Label Switching 480 (MPLS) Label Values" registry (see ). IANA is requested to 482 allocate Timestamp Label value from the "Extended Special-Purpose 483 MPLS Label Values" registry: 485 +-------------+-------------------------+---------------+ 486 | Value | Description | Reference | 487 +-------------+-------------------------+---------------+ 488 | TBA1 | Timestamp Label | This document | 489 +-------------+-------------------------+---------------+ 491 IANA is requested to allocate, within the "SRv6 Endpoint Behaviors 492 Registry" sub-registry belonging to the top-level "Segment-routing 493 with IPv6 data plane (SRv6) Parameters" registry 494 [I-D.ietf-spring-srv6-network-programming], the following 495 allocations: 497 +-------------+---------------------------------+---------------+ 498 | Value | Endpoint Behavior | Reference | 499 +-------------+---------------------------------+---------------+ 500 | TBA2 | END.TSF (Timestamp and Forward) | This document | 501 +-------------+---------------------------------+---------------+ 503 8. References 505 8.1. Normative References 507 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 508 DOI 10.17487/RFC0768, August 1980, 509 . 511 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 512 Requirement Levels", BCP 14, RFC 2119, 513 DOI 10.17487/RFC2119, March 1997, 514 . 516 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 517 Zekauskas, "A One-way Active Measurement Protocol 518 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 519 . 521 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 522 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 523 RFC 5357, DOI 10.17487/RFC5357, October 2008, 524 . 526 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 527 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 528 May 2017, . 530 [I-D.gandhi-spring-twamp-srpm] 531 Gandhi, R., Filsfils, C., Voyer, D., Chen, M., and B. 532 Janssens, "Performance Measurement Using TWAMP Light for 533 Segment Routing Networks", draft-gandhi-spring-twamp- 534 srpm-05 (work in progress), December 2019. 536 [I-D.ietf-ippm-stamp] 537 Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple 538 Two-way Active Measurement Protocol", draft-ietf-ippm- 539 stamp-10 (work in progress), October 2019. 541 8.2. Informative References 543 [IEEE1588] 544 IEEE, "1588-2008 IEEE Standard for a Precision Clock 545 Synchronization Protocol for Networked Measurement and 546 Control Systems", March 2008. 548 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 549 Pallagatti, "Seamless Bidirectional Forwarding Detection 550 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 551 . 553 [RFC8186] Mirsky, G. and I. Meilik, "Support of the IEEE 1588 554 Timestamp Format in a Two-Way Active Measurement Protocol 555 (TWAMP)", RFC 8186, DOI 10.17487/RFC8186, June 2017, 556 . 558 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 559 Decraene, B., Litkowski, S., and R. Shakir, "Segment 560 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 561 July 2018, . 563 [I-D.ietf-spring-segment-routing-policy] 564 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 565 P. Mattes, "Segment Routing Policy Architecture", draft- 566 ietf-spring-segment-routing-policy-06 (work in progress), 567 December 2019. 569 [I-D.ietf-spring-srv6-network-programming] 570 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 571 Matsushima, S., and Z. Li, "SRv6 Network Programming", 572 draft-ietf-spring-srv6-network-programming-10 (work in 573 progress), February 2020. 575 [I-D.ietf-6man-segment-routing-header] 576 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 577 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 578 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 579 progress), October 2019. 581 [I-D.ietf-pce-binding-label-sid] 582 Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., 583 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 584 in PCE-based Networks.", draft-ietf-pce-binding-label- 585 sid-01 (work in progress), November 2019. 587 [I-D.ietf-pce-sr-bidir-path] 588 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 589 "PCEP Extensions for Associated Bidirectional Segment 590 Routing (SR) Paths", draft-ietf-pce-sr-bidir-path-01 (work 591 in progress), February 2020. 593 Acknowledgments 595 TBD 597 Authors' Addresses 599 Rakesh Gandhi (editor) 600 Cisco Systems, Inc. 601 Canada 603 Email: rgandhi@cisco.com 605 Clarence Filsfils 606 Cisco Systems, Inc. 608 Email: cfilsfil@cisco.com 610 Navin Vaghamshi 611 Reliance 613 Email: Navin.Vaghamshi@ril.com 615 Moses Nagarajah 616 Telstra 618 Email: Moses.Nagarajah@team.telstra.com