idnits 2.17.1 draft-ietf-mpls-rfc6374-sr-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 (25 July 2021) is 998 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) -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-13 == Outdated reference: A later version (-08) exists of draft-ietf-pim-sr-p2mp-policy-02 == Outdated reference: A later version (-19) exists of draft-ietf-spring-sr-replication-segment-04 == Outdated reference: A later version (-16) exists of draft-ietf-pce-binding-label-sid-08 == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-04 == Outdated reference: A later version (-10) exists of draft-ietf-lsr-ospf-l2bundles-01 == Outdated reference: A later version (-13) exists of draft-ietf-pce-sr-bidir-path-07 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group R. Gandhi, Ed. 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: 26 January 2022 D. Voyer 6 Bell Canada 7 S. Salsano 8 Universita di Roma "Tor Vergata" 9 M. Chen 10 Huawei 11 25 July 2021 13 Performance Measurement Using RFC 6374 for Segment Routing Networks with 14 MPLS Data Plane 15 draft-ietf-mpls-rfc6374-sr-03 17 Abstract 19 Segment Routing (SR) leverages the source routing paradigm. RFC 6374 20 specifies protocol mechanisms to enable the efficient and accurate 21 measurement of packet loss, one-way and two-way delay, as well as 22 related metrics such as delay variation in MPLS networks. This 23 document utilizes these mechanisms for Performance Delay and Loss 24 Measurements in SR networks with MPLS data plane (SR-MPLS), for both 25 SR-MPLS links and end-to-end SR-MPLS paths including Policies. In 26 addition, this document defines Return Path TLV and Block Number TLV 27 extensions for RFC 6374. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 26 January 2022. 46 Copyright Notice 48 Copyright (c) 2021 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Simplified BSD License text 57 as described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 64 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 65 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 66 2.3. Reference Topology . . . . . . . . . . . . . . . . . . . 4 67 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4. Query and Response Messages . . . . . . . . . . . . . . . . . 6 69 4.1. Query Message for SR-MPLS Links and Policies . . . . . . 6 70 4.1.1. Query Message for SR-MPLS Links . . . . . . . . . . . 6 71 4.1.2. Query Message for SR-MPLS Policies . . . . . . . . . 6 72 4.2. Response Message for SR-MPLS Links and Policies . . . . . 7 73 4.2.1. One-way Measurement Mode . . . . . . . . . . . . . . 7 74 4.2.2. Two-way Measurement Mode . . . . . . . . . . . . . . 8 75 4.2.3. Loopback Measurement Mode . . . . . . . . . . . . . . 8 76 5. Delay Measurement . . . . . . . . . . . . . . . . . . . . . . 9 77 5.1. Delay Measurement Message Format . . . . . . . . . . . . 9 78 5.2. Timestamps . . . . . . . . . . . . . . . . . . . . . . . 9 79 6. Loss Measurement . . . . . . . . . . . . . . . . . . . . . . 9 80 6.1. Loss Measurement Message Format . . . . . . . . . . . . . 10 81 6.2. Combined Loss/Delay Measurement Message Format . . . . . 10 82 6.3. Counters . . . . . . . . . . . . . . . . . . . . . . . . 10 83 7. TLV Extensions . . . . . . . . . . . . . . . . . . . . . . . 11 84 7.1. Return Path TLV Extension . . . . . . . . . . . . . . . . 11 85 7.1.1. Return Path Sub-TLV Extension . . . . . . . . . . . . 12 86 7.2. Block Number TLV Extension . . . . . . . . . . . . . . . 13 87 8. Performance Measurement for P2MP SR-MPLS Policies . . . . . . 13 88 9. ECMP for SR-MPLS Policies . . . . . . . . . . . . . . . . . . 15 89 10. SR-MPLS Link Extended TE Metrics Advertisements . . . . . . . 15 90 11. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 16 91 12. Security Considerations . . . . . . . . . . . . . . . . . . . 16 92 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 93 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 94 14.1. Normative References . . . . . . . . . . . . . . . . . . 18 95 14.2. Informative References . . . . . . . . . . . . . . . . . 18 96 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21 97 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 21 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 100 1. Introduction 102 Segment Routing (SR) leverages the source routing paradigm for 103 Software Defined Networks (SDNs). SR is applicable to both 104 Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. 105 SR takes advantage of the Equal-Cost Multipaths (ECMPs) between 106 source and transit nodes, between transit nodes and between transit 107 and destination nodes. SR Policies as defined in 108 [I-D.ietf-spring-segment-routing-policy] are used to steer traffic 109 through a specific, user-defined paths using a stack of Segments. 110 Built-in SR Performance Measurement (PM) is one of the essential 111 requirements to provide Service Level Agreements (SLAs). 113 [RFC6374] specifies protocol mechanisms to enable the efficient and 114 accurate measurement of performance metrics in MPLS networks using 115 query and response messages. [RFC7876] specifies mechanisms for 116 sending and processing out-of-band responses over an UDP return path 117 when receiving RFC 6374 based query messages. These mechanisms are 118 also well-suited in SR-MPLS networks. 120 This document utilizes the mechanisms defined in [RFC6374] for 121 Performance Delay and Loss Measurements in SR-MPLS networks, for both 122 SR-MPLS links and end-to-end SR-MPLS paths including Policies. In 123 addition, this document defines Return Path TLV and Block Number TLV 124 extensions for [RFC6374]. 126 2. Conventions Used in This Document 128 2.1. Requirements Language 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119] [RFC8174] 133 when, and only when, they appear in all capitals, as shown here. 135 2.2. Abbreviations 137 ACH: Associated Channel Header. 139 DM: Delay Measurement. 141 ECMP: Equal Cost Multi-Path. 143 G-ACh: Generic Associated Channel (G-ACh). 145 GAL: Generic Associated Channel (G-ACh) Label. 147 LM: Loss Measurement. 149 MPLS: Multiprotocol Label Switching. 151 NTP: Network Time Protocol. 153 PM: Performance Measurement. 155 PSID: Path Segment Identifier. 157 PTP: Precision Time Protocol. 159 SID: Segment ID. 161 SL: Segment List. 163 SR: Segment Routing. 165 SR-MPLS: Segment Routing with MPLS data plane. 167 TC: Traffic Class. 169 TE: Traffic Engineering. 171 URO: UDP Return Object. 173 2.3. Reference Topology 175 In the reference topology shown in Figure 1, the querier node Q1 176 initiates a query message and the responder node R1 sends a response 177 message for the query message received. The response message is sent 178 back to the querier node Q1 in-band on the same path (same set of 179 links and nodes) or a different path in the reverse direction. 181 SR is enabled with MPLS data plane on nodes Q1 and R1. The nodes Q1 182 and R1 may be directly connected via a link enabled with MPLS 183 (Section 2.9.1 of [RFC6374]) or a Point-to-Point (P2P) SR-MPLS path 184 [RFC8402]. The link may be a physical interface, virtual link, or 185 Link Aggregation Group (LAG) [IEEE802.1AX], or LAG member link. The 186 SR-MPLS path may be an SR-MPLS Policy 187 [I-D.ietf-spring-segment-routing-policy] on node Q1 (called head-end) 188 with destination to node R1 (called tail-end). 190 T1 T2 191 / \ 192 +-------+ Query +-------+ 193 | | - - - - - - - - - ->| | 194 | Q1 |=====================| R1 | 195 | |<- - - - - - - - - - | | 196 +-------+ Response +-------+ 197 \ / 198 T4 T3 199 Querier Responder 201 Figure 1: Reference Topology 203 3. Overview 205 For delay and loss measurement in SR-MPLS networks, the procedures 206 defined in [RFC6374] are used in this document. Note that the one- 207 way, two-way and round-trip delay measurements are defined in 208 Section 2.4 of [RFC6374] and are further described in this document 209 for SR-MPLS networks. Similarly, the packet loss measurement is 210 defined in Section 2.2 of [RFC6374] and is further described in this 211 document for SR-MPLS networks. 213 In SR-MPLS networks, the query and response messages defined in 214 [RFC6374] are sent as following: 216 * For delay measurement, the query messages are sent in-band (on the 217 same path as data traffic) for SR-MPLS links and end-to-end SR- 218 MPLS paths to collect transmit and receive timestamps. 220 * For loss measurement, the query messages are sent in-band (on the 221 same path as data traffic) for SR-MPLS links and end-to-end SR- 222 MPLS paths to collect transmit and receive traffic counters (e.g. 223 for traffic received on the incoming link for the link packet loss 224 and for the incoming Path Segment Identifier (PSID) 225 [I-D.ietf-spring-mpls-path-segment] for the end-to-end SR-MPLS 226 path packet loss). 228 It may be desired in SR-MPLS networks that the same path (same set of 229 links and nodes) between the querier and responder be used in both 230 directions of the measurement. This is achieved by using the SR-MPLS 231 Return Path TLV extension defined in this document. 233 The packet loss measurement using Alternate-Marking Method defined in 234 [RFC8321] requires collecting Block Number of the traffic counters. 235 This is achieved by using the Block Number TLV extension defined in 236 this document. 238 The performance measurement procedure for SR-MPLS links can be used 239 to compute extended Traffic Engineering (TE) metrics for delay and 240 loss as described in this document. The metrics are advertised in 241 the network using the routing protocol extensions defined in 242 [RFC7471], [RFC8570], and [RFC8571]. 244 4. Query and Response Messages 246 As described in Section 2.9.1 of [RFC6374], the query and response 247 messages flow over an MPLS Generic Associated Channel (G-ACh). These 248 query and response messages contain G-ACh Label (GAL) (value 13, with 249 S=1). The GAL is followed by an Associated Channel Header (ACH), 250 where Channel Type identifies the measurement message type, and the 251 message payload following the ACH as shown in Figure 2. 253 0 1 2 3 254 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 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | GAL (value 13) | TC |S| TTL | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 |0 0 0 1|Version| Reserved | Channel Type | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 Figure 2: RFC 6374 Query and Response Message Header 263 4.1. Query Message for SR-MPLS Links and Policies 265 4.1.1. Query Message for SR-MPLS Links 267 A query message as shown in Figure 2 is sent over the SR-MPLS links 268 for both delay and loss measurement using the procedures described in 269 [RFC6374]. For SR-MPLS links, the TTL value is set to 255 in the SR- 270 MPLS header. SR-MPLS encapsulation (e.g. using adjacency SID of the 271 link) can be added for transmitting the query messages for SR-MPLS 272 links. 274 4.1.2. Query Message for SR-MPLS Policies 276 An SR-MPLS Policy may contain a number of Segment Lists (SLs) (i.e. 277 stack of MPLS labels) [I-D.ietf-spring-segment-routing-policy]. The 278 query messages MUST be transmitted for each SL of the SR-MPLS Policy. 279 A query message for an end-to-end SR-MPLS Policy, for both delay and 280 loss measurement, contains an SR-MPLS label stack, with the G-ACh 281 Label (GAL) at the bottom of the stack (with S=1) as shown in 282 Figure 3. For SR-MPLS Policies, the TTL value is set to 255 in the 283 SR-MPLS header. 285 0 1 2 3 286 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 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Label(1) | TC |S| TTL | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 . . 291 . . 292 . . 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Label(n) | TC |S| TTL | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | GAL (value 13) | TC |S| TTL | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 |0 0 0 1|Version| Reserved | Channel Type | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 Figure 3: Example Query Message Header for an End-to-end SR-MPLS 302 Policy 304 The SR-MPLS label stack can be empty (format as shown in Figure 2) to 305 indicate the Implicit NULL label case. 307 For a P2P SR-MPLS Policy, in order to ensure that the query message 308 is processed by the intended responder, Destination Address TLV (Type 309 129) [RFC6374] containing the address of the responder can be sent in 310 the query message. The responder MUST return Success in "Control 311 Code" [RFC6374] if it is the intended destination for the query. 312 Otherwise, it MUST return 0x15: Error - Invalid Destination Node 313 Identifier [RFC6374]. 315 4.2. Response Message for SR-MPLS Links and Policies 317 4.2.1. One-way Measurement Mode 319 In one-way measurement mode defined in Section 2.4 of [RFC6374], the 320 querier can receive "out-of-band" response messages with IP/UDP 321 header by properly setting the UDP Return Object (URO) TLV in the 322 query message. The URO TLV (Type=131) is defined in [RFC7876] and 323 includes the UDP-Destination-Port and IP Address. When the querier 324 sets an IP address and an UDP port in the URO TLV, the response 325 message is sent to that IP address as the destination address and UDP 326 port as the destination port. In addition, the "Control Code" in the 327 query message is set to "out-of-band response requested" [RFC6374]. 329 In one-way delay measurement mode, as per Reference Topology in 330 Figure 1, the timestamps T1 and T2 are collected by the query and 331 response messages. Both these timestamps are used to measure one-way 332 delay as (T2 - T1). 334 4.2.2. Two-way Measurement Mode 336 In two-way measurement mode defined in Section 2.4 of [RFC6374], the 337 response messages are sent back to the querier in-band on the same 338 link or the same end-to-end SR-MPLS path (same set of links and 339 nodes) in the reverse direction. 341 For SR-MPLS links, the response message (format as shown in Figure 2) 342 is sent back on the same incoming link where the query message is 343 received. In this case, the "Control Code" in the query message is 344 set to "in-band response requested" [RFC6374]. 346 For end-to-end SR-MPLS paths, the responder transmits the response 347 message (example as shown in Figure 3) on a specific return SR-MPLS 348 path [I-D.ietf-pce-sr-bidir-path]. The querier can request in the 349 query message to the responder to send the response message back on a 350 given return path using the SR-MPLS Segment List sub-TLV in the 351 Return Path TLV defined in this document. 353 In two-way delay measurement mode, as per Reference Topology in 354 Figure 1, all four timestamps T1, T2, T3, and T4 are collected by the 355 query and response messages. All four timestamps are used to measure 356 two-way delay as ((T4 - T1) - (T3 - T2)). 358 4.2.3. Loopback Measurement Mode 360 The Loopback measurement mode defined in Section 2.8 of [RFC6374] is 361 used to measure round-trip delay for a bidirectional circular SR-MPLS 362 path [I-D.ietf-pce-sr-bidir-path]. In this mode, the received query 363 messages are not punted out of the fast path in forwarding (i.e. to 364 slow path or control- plane) at the responder. In other words, the 365 responder does not process them and generate response messages. The 366 loopback function simply returns the received query message to the 367 querier without responder modifications [RFC6374]. 369 The loopback mode is done by generating "queries" with the Response 370 flag set to 1 and adding the Loopback Request object (Type 3) 371 [RFC6374]. The label stack in query messages in this case carry both 372 the forward and reverse paths in the MPLS header. The GAL is still 373 carried at the bottom of the label stack (with S=1) (example as shown 374 in Figure 3). 376 In loopback delay measurement mode, as per Reference Topology in 377 Figure 1, the timestamps T1 and T4 are collected by the query 378 messages. Both these timestamps are used to measure round-trip delay 379 as (T4 - T1). In this mode, the round-trip delay includes the 380 processing delay on the responder. The responder processing delay 381 component includes only the time required to loop the test packet 382 from the incoming interface to the outgoing interface in forwarding 383 plane. 385 5. Delay Measurement 387 5.1. Delay Measurement Message Format 389 As defined in [RFC6374], MPLS DM query and response messages use 390 Associated Channel Header (ACH) (value 0x000C for delay measurement) 391 [RFC6374], which identifies the message type, and the message payload 392 following the ACH. For both SR-MPLS links and end-to-end SR-MPLS 393 Policies, the same MPLS DM ACH value is used. 395 The DM message payload as defined in Section 3.2 of [RFC6374] is used 396 for delay measurement, for both SR-MPLS links and end-to-end SR-MPLS 397 Policies. 399 5.2. Timestamps 401 The Section 3.4 of [RFC6374] defines timestamp format that can be 402 used for delay measurement. The IEEE 1588 Precision Time Protocol 403 (PTP) timestamp format [IEEE1588] is used by default as described in 404 Appendix A of [RFC6374]. 406 6. Loss Measurement 408 The LM protocol can perform two distinct kinds of loss measurement as 409 described in Section 2.9.8 of [RFC6374]. 411 * In inferred mode, LM will measure the loss of specially generated 412 test messages in order to infer the approximate data plane loss 413 level. Inferred mode LM provides only approximate loss 414 accounting. 416 * In direct mode, LM will directly measure data plane packet loss. 417 Direct mode LM provides perfect loss accounting, but may require 418 hardware support. 420 6.1. Loss Measurement Message Format 422 As defined in [RFC6374], MPLS LM query and response messages use 423 Associated Channel Header (ACH) (value 0x000A for direct loss 424 measurement or value 0x000B for inferred loss measurement), which 425 identifies the message type, and the message payload following the 426 ACH. For both SR-MPLS links and end-to-end SR-MPLS Policies, the 427 same MPLS LM ACH value is used. 429 The LM message payload as defined in Section 3.1 of [RFC6374] is used 430 for loss measurement, for both SR-MPLS links and end-to-end SR-MPLS 431 Policies. 433 6.2. Combined Loss/Delay Measurement Message Format 435 As defined in [RFC6374], Combined DM+LM query and response messages 436 use Associated Channel Header (ACH) (value 0x000D for direct loss and 437 delay measurement or value 0x000E for inferred loss and delay 438 measurement), which identifies the message type, and the message 439 payload following the ACH. For both SR-MPLS links and end-to-end SR- 440 MPLS Policies, the same MPLS DM+LM ACH value is used. 442 The message payload as defined in Section 3.3 of [RFC6374] is used 443 for combined delay and loss measurement, for both SR-MPLS links and 444 end-to-end SR-MPLS Policies. 446 6.3. Counters 448 The Path Segment Identifier (PSID) 449 [I-D.ietf-spring-mpls-path-segment] carried in the received data 450 packet for the traffic flow under measurement can be used for 451 accounting received traffic on the egress node of the SR-MPLS Policy. 452 In direct mode, the PSID in the received query message as shown in 453 Figure 4 can be used to associate the receive traffic counter on the 454 responder to detect the transmit packet loss for the end-to-end SR- 455 MPLS Policy. 457 In inferred mode, the PSID in the received query messages as shown in 458 Figure 4 can be used to count the received query messages on the 459 responder to detect the transmit packet loss for an end-to-end SR- 460 MPLS Policy. 462 0 1 2 3 463 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 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | PSID | TC |S| TTL | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | GAL (value 13) | TC |S| TTL | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 |0 0 0 1|Version| Reserved | Channel Type | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 Figure 4: Example With Path Segment Identifier for SR-MPLS Policy 474 Different values of PSID can be used to measure packet loss per SR- 475 MPLS Policy, per Candidate Path or per Segment List of the SR-MPLS 476 Policy [I-D.ietf-spring-segment-routing-policy]. 478 7. TLV Extensions 480 7.1. Return Path TLV Extension 482 In two-way measurement mode, the responder sends the response message 483 on a specific return path. The querier can request in the query 484 message to the responder to send a response message back on a given 485 return path (e.g. co-routed SR-MPLS path for two-way measurement). 486 This way the responder avoids creating and maintaining extra dynamic 487 SR states for the return paths for two-way measurement. 489 The querier may not be reachable from the responder. The querier in 490 this case MUST send its reachability path information to the 491 responder using the Return Path TLV. 493 [RFC6374] defines query and response messages those can include or 494 more optional TLVs. New TLV Type (TBA2) is defined in this document 495 for Return Path TLV to carry return path information in query 496 messages. The format of the Return Path TLV is shown in Figure 5: 498 0 1 2 3 499 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 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Type = TBA2 | Length | Reserved | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Return Path Sub-TLV | 504 . . 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 Figure 5: Return Path TLV 509 The Return Path TLV is a Mandatory TLV Type. The querier MUST only 510 insert one Return Path TLV in the query message. The responder that 511 supports this TLV, MUST only process the first Return Path TLV and 512 ignore the other Return Path TLVs if present. The responder that 513 supports this TLV, also MUST send response message back on the return 514 path specified in the Return Path TLV. The responder also MUST NOT 515 add Return Path TLV in the response message. The Reserved field MUST 516 be set to 0 and MUST be ignored on the receive side. 518 7.1.1. Return Path Sub-TLV Extension 520 The Return Path TLV contains a Sub-TLV to carry the return path. The 521 format of the SR-MPLS Segment List Sub-TLV is shown in Figure 6. The 522 SR-MPLS Segment List Sub-TLV contains SR-MPLS Label Stack. The Label 523 entries in the Segment List MUST be in network order. The SR-MPLS 524 Segment List Sub-TLV in the Return Path TLV is of the following Type: 526 * Type (value 1): SR-MPLS Segment List of the Return Path 528 0 1 2 3 529 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 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Type | Length | Reserved | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Label(1) | 534 . . 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 . . 537 . . 538 . . 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Label(n) (bottom of stack) | 541 . . 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 Figure 6: SR-MPLS Segment List Sub-TLV in Return Path TLV 546 An SR-MPLS Segment List Sub-TLV may carry only Binding SID 547 [I-D.ietf-pce-binding-label-sid] of the Return SR-MPLS Policy. 549 The Return Path TLV MUST carry only one Return Path Sub-TLV. The 550 responder that supports this Sub-TLV, MUST only process the first 551 Return Path Sub-TLV and ignore the other Return Path Sub-TLVs if 552 present. The responder that supports this Sub-TLV, also MUST send 553 response message back on the return path specified in the Return Path 554 Sub-TLV. The Reserved field MUST be set to 0 and MUST be ignored on 555 the receive side. 557 Note that in addition to the P2P SR-MPLS paths, the SR-MPLS Segment 558 List Sub-TLV is also applicable to the P2MP SR-MPLS paths. For 559 example, for P2MP SR-MPLS paths, it may only carry the Node Segment 560 Identifier of the querier in order for the response to follow an SR- 561 MPLS path back to the querier. 563 7.2. Block Number TLV Extension 565 The direct mode loss measurement using Alternate-Marking Method 566 defined in [RFC8321] requires collecting Block Number of the counters 567 for the data traffic flow under measurement. To be able to correlate 568 the transmit and receive traffic counters of the matching Block 569 Number, the Block Number of the traffic counters is carried in the LM 570 query and response messages. 572 [RFC6374] defines query and response messages those can include one 573 or more optional TLVs. New TLV Type (value TBA1) is defined in this 574 document to carry the Block Number (8-bit) of the traffic counters in 575 the LM query and response messages. The format of the Block Number 576 TLV is shown in Figure 7: 578 0 1 2 3 579 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 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | Type = TBA1 | Length | Reserved |R| Block Number | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 Figure 7: Block Number TLV 586 The Block Number TLV is a Mandatory TLV Type. The querier MUST only 587 insert one Block Number TLV in the query message to identify the 588 Block Number for the traffic counters in the forward direction. The 589 responder that supports this TLV, MUST only inert one Block Number 590 TLV in the response message to identify the Block Number for the 591 traffic counters in the reverse direction. The responder also MUST 592 return the first Block Number TLV from the query message and ignore 593 the other Block Number TLVs if present. The R Flag MUST be clear in 594 the query message and set in the response message. The Reserved 595 field MUST be set to 0 and MUST be ignored on the receive side. 597 8. Performance Measurement for P2MP SR-MPLS Policies 599 The Point-to-Multipoint (P2MP) SR-MPLS path that originates from a 600 root node terminates on multiple destinations called leaf nodes (e.g. 601 P2MP SR-MPLS Policy [I-D.ietf-pim-sr-p2mp-policy]). 603 The procedures for delay and loss measurement described in this 604 document for end-to-end P2P SR-MPLS Policies are also equally 605 applicable to the P2MP SR-MPLS Policies. The procedure for one-way 606 measurement is defined as following: 608 * The querier root node sends query messages using the Tree-SID 609 defined in [I-D.ietf-pim-sr-p2mp-policy] for the P2MP SR-MPLS 610 Policy as shown in Figure 8. The query messages may contain the 611 replication SID as defined in 612 [I-D.ietf-spring-sr-replication-segment]. 614 * Destination Address TLV (Type 129) [RFC6374] is not applicable to 615 the P2MP SR-MPLS Policy. 617 * Each responder leaf node MUST send its node address in the "Source 618 Address" TLV (Type 130) [RFC6374] in the response messages. This 619 TLV allows the querier root node to identify the responder leaf 620 nodes of the P2MP SR-MPLS Policy. 622 * The P2MP root node measures the delay and loss performance for 623 each P2MP leaf node individually. 625 0 1 2 3 626 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 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Tree-SID | TC |S| TTL | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 . . 631 . . 632 . . 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | GAL (value 13) | TC |S| TTL | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 |0 0 0 1|Version| Reserved | Channel Type | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 Figure 8: Example Query with Tree-SID for SR-MPLS Policy 641 The considerations for two-way measurement mode (e.g. for co-routed 642 bidirectional SR-MPLS path) and loopback measurement mode for P2MP 643 SR-MPLS Policy are outside the scope of this document. 645 9. ECMP for SR-MPLS Policies 647 An SR-MPLS Policy can have ECMPs between the source and transit 648 nodes, between transit nodes and between transit and destination 649 nodes. Usage of Anycast SID [RFC8402] by an SR-MPLS Policy can 650 result in ECMP paths via transit nodes part of that Anycast group. 651 The query and response messages SHOULD be sent to traverse different 652 ECMP paths to measure delay of each of the ECMP path of an SR-MPLS 653 Policy. 655 Forwarding plane has various hashing functions available to forward 656 packets on specific ECMP paths. For SR-MPLS Policy, sweeping of 657 entropy label [RFC6790] values can be used in query and response 658 messages to take advantage of the hashing function in forwarding 659 plane to influence the ECMP path taken by them. 661 The considerations for loss measurement for different ECMP paths of 662 an SR-MPLS Policy are outside the scope of this document. 664 10. SR-MPLS Link Extended TE Metrics Advertisements 666 The extended TE metrics for SR-MPLS link delay and loss can be 667 computed using the performance measurement procedures described in 668 this document to advertise in the routing domain as follows: 670 * For OSPF, ISIS, and BGP-LS, protocol extensions defined in 671 [RFC7471], [RFC8570], and [RFC8571], respectively, are used for 672 advertising the extended TE link delay and loss metrics in the 673 network. 675 * The extended TE link delay and loss metrics are advertised for 676 Layer-2 LAG bundle member links in OSPF 677 [I-D.ietf-lsr-ospf-l2bundles] and ISIS [RFC8668] using the same 678 protocol extensions defined in [RFC7471] and [RFC8570], 679 respectively. 681 * The advertised delay-variance metric, Packet Delay Variation (PDV) 682 is computed as described in Section 4.2 of [RFC5481]. 684 * In the absence of one-way delay measurement, the extended TE link 685 one-way delay metrics can be computed using the two-way and round- 686 trip delay values by dividing the values by 2. 688 11. Backwards Compatibility 690 The procedures defined in this document are backwards compatible with 691 the procedures defined in [RFC6374] at both querier and responder. 692 If the responder does not support the new Mandatory TLV Types defined 693 in this document, it MUST return Error 0x17: Unsupported Mandatory 694 TLV Object as per [RFC6374]. 696 12. Security Considerations 698 This document describes the procedures for performance delay and loss 699 measurement for SR-MPLS networks, for both SR-MPLS links and end-to- 700 end SR-MPLS Policies using the mechanisms defined in [RFC6374] and 701 [RFC7876]. The security considerations covered in [RFC6374], 702 [RFC7471], [RFC8570], [RFC8571], and [RFC7876] also apply to the 703 procedures in this document. 705 The procedure defined in this document is intended for deployment in 706 limited domains [RFC8799]. As such, it assumes that a querier node 707 involved in the measurement operation has previously verified the 708 integrity of the path and the identity of the far-end responder. 710 If desired, attacks can be mitigated by performing basic validation 711 and sanity checks, at the querier, of the timestamp and counter 712 fields in received response messages. The minimal state associated 713 with these protocols also limits the extent of measurement disruption 714 that can be caused by a corrupt or invalid message to a single test 715 cycle. 717 The extensions defined in this document may be used for potential 718 "proxying" attacks. For example, a querier may specify a return path 719 that has a destination different from that of the responder. But 720 normally, such attacks will not happen in an SR-MPLS domain where the 721 queriers and responders belong to the same domain [RFC8799]. In 722 order to prevent using the extension defined in this document for 723 proxying any possible attacks, the return path has destination to the 724 same node where the forward path is from. The responder may drop the 725 query messages when it cannot determine whether the Return Path has 726 the destination to the querier. 728 13. IANA Considerations 730 IANA is requested to allocate a value for the following Mandatory 731 Block Number TLV Type for [RFC6374] to be carried in the query and 732 response messages from the "MPLS Loss/Delay Measurement TLV Object" 733 registry contained within the "Generic Associated Channel (G-ACh) 734 Parameters" registry set: 736 * Type TBA1: Block Number TLV 738 IANA is also requested to allocate a value for the following 739 Mandatory Return Path TLV Type for [RFC6374] to be carried in the 740 query messages from the "MPLS Loss/Delay Measurement TLV Object" 741 registry contained within the "Generic Associated Channel (G-ACh) 742 Parameters" registry set: 744 * Type TBA2: Return Path TLV 746 IANA is requested to create the "Return Path Sub-TLV" sub-registry as 747 part of the Return Path TLV registry. All code points in the range 1 748 through 127 in this registry shall be allocated according to the 749 "IETF Review" procedure as specified in [RFC8126]. Code points in 750 the range 128 through 239 in this registry shall be allocated 751 according to the "First Come First Served" procedure as specified in 752 [RFC8126]. Remaining code points are allocated according to Table 1: 754 +===========+==============+===============+ 755 | Value | Description | Reference | 756 +===========+==============+===============+ 757 | 0 | Reserved | This document | 758 +-----------+--------------+---------------+ 759 | 1 - 127 | Unassigned | This document | 760 +-----------+--------------+---------------+ 761 | 128 - 239 | Unassigned | This document | 762 +-----------+--------------+---------------+ 763 | 240 - 249 | Experimental | This document | 764 +-----------+--------------+---------------+ 765 | 250 - 254 | Private Use | This document | 766 +-----------+--------------+---------------+ 767 | 255 | Reserved | This document | 768 +-----------+--------------+---------------+ 770 Table 1: Return Path Sub-TLV Type Sub- 771 Registry 773 This document defines the following new values in the Return Path 774 Sub-TLV sub-registry: 776 +=======+=========================================+===============+ 777 | Value | Description | Reference | 778 +=======+=========================================+===============+ 779 | 1 | SR-MPLS Segment List of the Return Path | This document | 780 +-------+-----------------------------------------+---------------+ 782 Table 2: Return Path Sub-TLV Types 784 14. References 786 14.1. Normative References 788 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 789 Requirement Levels", BCP 14, RFC 2119, 790 DOI 10.17487/RFC2119, March 1997, 791 . 793 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 794 Measurement for MPLS Networks", RFC 6374, 795 DOI 10.17487/RFC6374, September 2011, 796 . 798 [RFC7876] Bryant, S., Sivabalan, S., and S. Soni, "UDP Return Path 799 for Packet Loss and Delay Measurement for MPLS Networks", 800 RFC 7876, DOI 10.17487/RFC7876, July 2016, 801 . 803 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 804 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 805 May 2017, . 807 14.2. Informative References 809 [IEEE1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock 810 Synchronization Protocol for Networked Measurement and 811 Control Systems", March 2008. 813 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 814 Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, 815 March 2009, . 817 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 818 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 819 RFC 6790, DOI 10.17487/RFC6790, November 2012, 820 . 822 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 823 Previdi, "OSPF Traffic Engineering (TE) Metric 824 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 825 . 827 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 828 Writing an IANA Considerations Section in RFCs", BCP 26, 829 RFC 8126, DOI 10.17487/RFC8126, June 2017, 830 . 832 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 833 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 834 "Alternate-Marking Method for Passive and Hybrid 835 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 836 January 2018, . 838 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 839 Decraene, B., Litkowski, S., and R. Shakir, "Segment 840 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 841 July 2018, . 843 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 844 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 845 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 846 2019, . 848 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and 849 C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of 850 IGP Traffic Engineering Performance Metric Extensions", 851 RFC 8571, DOI 10.17487/RFC8571, March 2019, 852 . 854 [RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, 855 M., and E. Aries, "Advertising Layer 2 Bundle Member Link 856 Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668, 857 December 2019, . 859 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 860 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 861 . 863 [I-D.ietf-spring-segment-routing-policy] 864 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 865 P. Mattes, "Segment Routing Policy Architecture", Work in 866 Progress, Internet-Draft, draft-ietf-spring-segment- 867 routing-policy-13, 28 May 2021, 868 . 871 [I-D.ietf-pim-sr-p2mp-policy] 872 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 873 Zhang, "Segment Routing Point-to-Multipoint Policy", Work 874 in Progress, Internet-Draft, draft-ietf-pim-sr-p2mp- 875 policy-02, 19 February 2021, 876 . 879 [I-D.ietf-spring-sr-replication-segment] 880 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 881 Zhang, "SR Replication Segment for Multi-point Service 882 Delivery", Work in Progress, Internet-Draft, draft-ietf- 883 spring-sr-replication-segment-04, 18 February 2021, 884 . 887 [I-D.ietf-pce-binding-label-sid] 888 Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S., 889 and C. Li, "Carrying Binding Label/Segment Identifier in 890 PCE-based Networks.", Work in Progress, Internet-Draft, 891 draft-ietf-pce-binding-label-sid-08, 14 April 2021, 892 . 895 [I-D.ietf-spring-mpls-path-segment] 896 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 897 "Path Segment in MPLS Based Segment Routing Network", Work 898 in Progress, Internet-Draft, draft-ietf-spring-mpls-path- 899 segment-04, 11 April 2021, 900 . 903 [I-D.ietf-lsr-ospf-l2bundles] 904 Talaulikar, K. and P. Psenak, "Advertising L2 Bundle 905 Member Link Attributes in OSPF", Work in Progress, 906 Internet-Draft, draft-ietf-lsr-ospf-l2bundles-01, 27 April 907 2021, . 910 [I-D.ietf-pce-sr-bidir-path] 911 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 912 "Path Computation Element Communication Protocol (PCEP) 913 Extensions for Associated Bidirectional Segment Routing 914 (SR) Paths", Work in Progress, Internet-Draft, draft-ietf- 915 pce-sr-bidir-path-07, 12 July 2021, 916 . 919 [IEEE802.1AX] 920 IEEE Std. 802.1AX, "IEEE Standard for Local and 921 metropolitan area networks - Link Aggregation", November 922 2008. 924 Acknowledgments 926 The authors would like to thank Thierry Couture for the discussions 927 on the use-cases for the performance measurement in segment routing 928 networks. Authors would like to thank Patrick Khordoc for 929 implementing the mechanisms defined in this document. The authors 930 would like to thank Greg Mirsky for providing many useful comments 931 and suggestions. The authors would also like to thank Stewart 932 Bryant, Sam Aldrin, Tarek Saad, and Rajiv Asati for their review 933 comments. Thanks to Huaimo Chen, Yimin Shen, and Xufeng Liu for 934 MPLS-RT expert review. 936 Contributors 938 Sagar Soni 939 Cisco Systems, Inc. 940 Email: sagsoni@cisco.com 942 Zafar Ali 943 Cisco Systems, Inc. 944 Email: zali@cisco.com 946 Pier Luigi Ventre 947 CNIT 948 Italy 949 Email: pierluigi.ventre@cnit.it 951 Authors' Addresses 953 Rakesh Gandhi (editor) 954 Cisco Systems, Inc. 955 Canada 957 Email: rgandhi@cisco.com 959 Clarence Filsfils 960 Cisco Systems, Inc. 962 Email: cfilsfil@cisco.com 964 Daniel Voyer 965 Bell Canada 967 Email: daniel.voyer@bell.ca 968 Stefano Salsano 969 Universita di Roma "Tor Vergata" 970 Italy 972 Email: stefano.salsano@uniroma2.it 974 Mach(Guoyi) Chen 975 Huawei 977 Email: mach.chen@huawei.com