idnits 2.17.1 draft-ietf-mpls-rfc6374-sr-04.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 (9 September 2021) is 957 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-03 == Outdated reference: A later version (-19) exists of draft-ietf-spring-sr-replication-segment-05 == Outdated reference: A later version (-16) exists of draft-ietf-pce-binding-label-sid-10 == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-05 == 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: 13 March 2022 D. Voyer 6 Bell Canada 7 S. Salsano 8 Universita di Roma "Tor Vergata" 9 M. Chen 10 Huawei 11 9 September 2021 13 Performance Measurement Using RFC 6374 for Segment Routing Networks with 14 MPLS Data Plane 15 draft-ietf-mpls-rfc6374-sr-04 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 13 March 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 . . . . . . . . . . . . . . . . . . 14 89 10. SR-MPLS Link Extended TE Metrics Advertisements . . . . . . . 15 90 11. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 15 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 an SR-MPLS Policy, in order to ensure that the query message is 308 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]. The Destination Address TLV is applicable to 314 P2P SR-MPLS Policy only. 316 4.2. Response Message for SR-MPLS Links and Policies 318 4.2.1. One-way Measurement Mode 320 In one-way measurement mode defined in Section 2.4 of [RFC6374], the 321 querier can receive "out-of-band" response messages with IP/UDP 322 header by properly setting the UDP Return Object (URO) TLV in the 323 query message. The URO TLV (Type=131) is defined in [RFC7876] and 324 includes the UDP-Destination-Port and IP Address. When the querier 325 sets an IP address and an UDP port in the URO TLV, the response 326 message is sent to that IP address as the destination address and UDP 327 port as the destination port. In addition, the "Control Code" in the 328 query message is set to "out-of-band response requested" [RFC6374]. 330 In one-way delay measurement mode, as per Reference Topology in 331 Figure 1, the timestamps T1 and T2 are collected by the query and 332 response messages. Both these timestamps are used to measure one-way 333 delay as (T2 - T1). 335 4.2.2. Two-way Measurement Mode 337 In two-way measurement mode defined in Section 2.4 of [RFC6374], the 338 response messages are sent back to the querier in-band on the same 339 link or the same end-to-end SR-MPLS path (same set of links and 340 nodes) in the reverse direction. 342 For SR-MPLS links, the response message (format as shown in Figure 2) 343 is sent back on the same incoming link where the query message is 344 received. In this case, the "Control Code" in the query message is 345 set to "in-band response requested" [RFC6374]. 347 For end-to-end SR-MPLS paths, the responder transmits the response 348 message (example as shown in Figure 3) on a specific return SR-MPLS 349 path [I-D.ietf-pce-sr-bidir-path]. The querier can request in the 350 query message to the responder to send the response message back on a 351 given return path using the SR-MPLS Segment List sub-TLV in the 352 Return Path TLV defined in this document. 354 In two-way delay measurement mode, as per Reference Topology in 355 Figure 1, all four timestamps T1, T2, T3, and T4 are collected by the 356 query and response messages. All four timestamps are used to measure 357 two-way delay as ((T4 - T1) - (T3 - T2)). 359 4.2.3. Loopback Measurement Mode 361 The Loopback measurement mode defined in Section 2.8 of [RFC6374] is 362 used to measure round-trip delay for a bidirectional circular SR-MPLS 363 path [I-D.ietf-pce-sr-bidir-path]. In this mode, the received query 364 messages are not punted out of the fast path in forwarding (i.e. to 365 slow path or control- plane) at the responder. In other words, the 366 responder does not process them and generate response messages. The 367 loopback function simply returns the received query message to the 368 querier without responder modifications [RFC6374]. 370 The loopback mode is done by generating "queries" with the Response 371 flag set to 1 and adding the Loopback Request object (Type 3) 372 [RFC6374]. The label stack in query messages in this case carry both 373 the forward and reverse paths in the MPLS header. The GAL is still 374 carried at the bottom of the label stack (with S=1) (example as shown 375 in Figure 3). 377 In loopback delay measurement mode, as per Reference Topology in 378 Figure 1, the timestamps T1 and T4 are collected by the query 379 messages. Both these timestamps are used to measure round-trip delay 380 as (T4 - T1). In this mode, the round-trip delay includes the 381 processing delay on the responder. The responder processing delay 382 component includes only the time required to loop the test packet 383 from the incoming interface to the outgoing interface in forwarding 384 plane. 386 5. Delay Measurement 388 5.1. Delay Measurement Message Format 390 As defined in [RFC6374], MPLS DM query and response messages use 391 Associated Channel Header (ACH) (value 0x000C for delay measurement) 392 [RFC6374], which identifies the message type, and the message payload 393 following the ACH. For both SR-MPLS links and end-to-end SR-MPLS 394 Policies, the same MPLS DM ACH value is used. 396 The DM message payload as defined in Section 3.2 of [RFC6374] is used 397 for delay measurement, for both SR-MPLS links and end-to-end SR-MPLS 398 Policies. 400 5.2. Timestamps 402 The Section 3.4 of [RFC6374] defines timestamp format that can be 403 used for delay measurement. The IEEE 1588 Precision Time Protocol 404 (PTP) timestamp format [IEEE1588] is used by default as described in 405 Appendix A of [RFC6374]. 407 6. Loss Measurement 409 The LM protocol can perform two distinct kinds of loss measurement as 410 described in Section 2.9.8 of [RFC6374]. 412 * In inferred mode, LM will measure the loss of specially generated 413 test messages in order to infer the approximate data plane loss 414 level. Inferred mode LM provides only approximate loss 415 accounting. 417 * In direct mode, LM will directly measure data plane packet loss. 418 Direct mode LM provides perfect loss accounting, but may require 419 hardware support. 421 6.1. Loss Measurement Message Format 423 As defined in [RFC6374], MPLS LM query and response messages use 424 Associated Channel Header (ACH) (value 0x000A for direct loss 425 measurement or value 0x000B for inferred loss measurement), which 426 identifies the message type, and the message payload following the 427 ACH. For both SR-MPLS links and end-to-end SR-MPLS Policies, the 428 same MPLS LM ACH value is used. 430 The LM message payload as defined in Section 3.1 of [RFC6374] is used 431 for loss measurement, for both SR-MPLS links and end-to-end SR-MPLS 432 Policies. 434 6.2. Combined Loss/Delay Measurement Message Format 436 As defined in [RFC6374], Combined DM+LM query and response messages 437 use Associated Channel Header (ACH) (value 0x000D for direct loss and 438 delay measurement or value 0x000E for inferred loss and delay 439 measurement), which identifies the message type, and the message 440 payload following the ACH. For both SR-MPLS links and end-to-end SR- 441 MPLS Policies, the same MPLS DM+LM ACH value is used. 443 The message payload as defined in Section 3.3 of [RFC6374] is used 444 for combined delay and loss measurement, for both SR-MPLS links and 445 end-to-end SR-MPLS Policies. 447 6.3. Counters 449 The Path Segment Identifier (PSID) 450 [I-D.ietf-spring-mpls-path-segment] carried in the received data 451 packet for the traffic flow under measurement can be used for 452 accounting received traffic on the egress node of the SR-MPLS Policy. 453 In direct mode, the PSID in the received query message as shown in 454 Figure 4 can be used to associate the receive traffic counter on the 455 responder to detect the transmit packet loss for the end-to-end SR- 456 MPLS Policy. 458 In inferred mode, the PSID in the received query messages as shown in 459 Figure 4 can be used to count the received query messages on the 460 responder to detect the transmit packet loss for an end-to-end SR- 461 MPLS Policy. 463 0 1 2 3 464 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 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | PSID | TC |S| TTL | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | GAL (value 13) | TC |S| TTL | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 |0 0 0 1|Version| Reserved | Channel Type | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 Figure 4: Example With Path Segment Identifier for SR-MPLS Policy 475 Different values of PSID can be used to measure packet loss per SR- 476 MPLS Policy, per Candidate Path or per Segment List of the SR-MPLS 477 Policy [I-D.ietf-spring-segment-routing-policy]. 479 7. TLV Extensions 481 7.1. Return Path TLV Extension 483 In two-way measurement mode, the responder sends the response message 484 on a specific return path. The querier can request in the query 485 message to the responder to send a response message back on a given 486 return path (e.g. co-routed SR-MPLS path for two-way measurement). 487 This way the responder avoids creating and maintaining extra dynamic 488 SR states for the return paths for two-way measurement. 490 The querier may not be reachable from the responder. The querier in 491 this case MUST send its reachability path information to the 492 responder using the Return Path TLV. 494 [RFC6374] defines query and response messages those can include or 495 more optional TLVs. New TLV Type (TBA2) is defined in this document 496 for Return Path TLV to carry return path information in query 497 messages. The format of the Return Path TLV is shown in Figure 5: 499 0 1 2 3 500 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 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Type = TBA2 | Length | Reserved | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Return Path Sub-TLV | 505 . . 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 Figure 5: Return Path TLV 510 The Return Path TLV is a Mandatory TLV Type. The querier MUST only 511 insert one Return Path TLV in the query message. The responder that 512 supports this TLV, MUST only process the first Return Path TLV and 513 ignore the other Return Path TLVs if present. The responder that 514 supports this TLV, also MUST send response message back on the return 515 path specified in the Return Path TLV. The responder also MUST NOT 516 add Return Path TLV in the response message. The Reserved field MUST 517 be set to 0 and MUST be ignored on the receive side. 519 7.1.1. Return Path Sub-TLV Extension 521 The Return Path TLV contains a Sub-TLV to carry the return path. The 522 format of the SR-MPLS Segment List Sub-TLV is shown in Figure 6. The 523 SR-MPLS Segment List Sub-TLV contains SR-MPLS Label Stack. The Label 524 entries in the Segment List MUST be in network order. The SR-MPLS 525 Segment List Sub-TLV in the Return Path TLV is of the following Type: 527 * Type (value 1): SR-MPLS Segment List of the Return Path 529 0 1 2 3 530 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 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Type | Length | Reserved | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | Label(1) | 535 . . 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 . . 538 . . 539 . . 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | Label(n) (bottom of stack) | 542 . . 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 Figure 6: SR-MPLS Segment List Sub-TLV in Return Path TLV 547 An SR-MPLS Segment List Sub-TLV may carry only Binding SID 548 [I-D.ietf-pce-binding-label-sid] of the Return SR-MPLS Policy. 550 The Return Path TLV MUST carry only one Return Path Sub-TLV. The 551 responder that supports this Sub-TLV, MUST only process the first 552 Return Path Sub-TLV and ignore the other Return Path Sub-TLVs if 553 present. The responder that supports this Sub-TLV, also MUST send 554 response message back on the return path specified in the Return Path 555 Sub-TLV. The Reserved field MUST be set to 0 and MUST be ignored on 556 the receive side. 558 Note that in addition to the P2P SR-MPLS paths, the SR-MPLS Segment 559 List Sub-TLV is also applicable to the P2MP SR-MPLS paths. For 560 example, for P2MP SR-MPLS paths, it may only carry the Node Segment 561 Identifier of the querier in order for the response to follow an SR- 562 MPLS path back to the querier. 564 7.2. Block Number TLV Extension 566 The direct mode loss measurement using Alternate-Marking Method 567 defined in [RFC8321] requires collecting Block Number of the counters 568 for the data traffic flow under measurement. To be able to correlate 569 the transmit and receive traffic counters of the matching Block 570 Number, the Block Number of the traffic counters is carried in the LM 571 query and response messages. 573 [RFC6374] defines query and response messages those can include one 574 or more optional TLVs. New TLV Type (value TBA1) is defined in this 575 document to carry the Block Number (8-bit) of the traffic counters in 576 the LM query and response messages. The format of the Block Number 577 TLV is shown in Figure 7: 579 0 1 2 3 580 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 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | Type = TBA1 | Length | Reserved |R| Block Number | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 Figure 7: Block Number TLV 587 The Block Number TLV is a Mandatory TLV Type. The querier MUST only 588 insert one Block Number TLV in the query message to identify the 589 Block Number for the traffic counters in the forward direction. The 590 responder that supports this TLV, MUST only inert one Block Number 591 TLV in the response message to identify the Block Number for the 592 traffic counters in the reverse direction. The responder also MUST 593 return the first Block Number TLV from the query message and ignore 594 the other Block Number TLVs if present. The R Flag MUST be clear in 595 the query message and set in the response message. The Reserved 596 field MUST be set to 0 and MUST be ignored on the receive side. 598 8. Performance Measurement for P2MP SR-MPLS Policies 600 The Point-to-Multipoint (P2MP) SR-MPLS path that originates from a 601 root node terminates on multiple destinations called leaf nodes (e.g. 602 P2MP SR-MPLS Policy [I-D.ietf-pim-sr-p2mp-policy]). 604 The procedures for delay and loss measurement described in this 605 document for end-to-end P2P SR-MPLS Policies are also equally 606 applicable to the P2MP SR-MPLS Policies. The procedure for one-way 607 measurement is defined as following: 609 * The querier root node sends query messages using the Tree-SID 610 defined in [I-D.ietf-pim-sr-p2mp-policy] for the P2MP SR-MPLS 611 Policy as shown in Figure 8. The query messages may contain the 612 replication SID as defined in 613 [I-D.ietf-spring-sr-replication-segment]. 615 * Each responder leaf node MUST send its node address in the "Source 616 Address" TLV (Type 130) [RFC6374] in the response messages. This 617 TLV allows the querier root node to identify the responder leaf 618 nodes of the P2MP SR-MPLS Policy. 620 * The P2MP root node measures the delay and loss performance for 621 each P2MP leaf node individually. 623 0 1 2 3 624 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 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Tree-SID | TC |S| TTL | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 . . 629 . . 630 . . 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | GAL (value 13) | TC |S| TTL | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 |0 0 0 1|Version| Reserved | Channel Type | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 Figure 8: Example Query with Tree-SID for SR-MPLS Policy 639 The considerations for two-way measurement mode (e.g. for co-routed 640 bidirectional SR-MPLS path) and loopback measurement mode for P2MP 641 SR-MPLS Policy are outside the scope of this document. 643 9. ECMP for SR-MPLS Policies 645 An SR-MPLS Policy can have ECMPs between the source and transit 646 nodes, between transit nodes and between transit and destination 647 nodes. Usage of Anycast SID [RFC8402] by an SR-MPLS Policy can 648 result in ECMP paths via transit nodes part of that Anycast group. 649 The query and response messages SHOULD be sent to traverse different 650 ECMP paths to measure delay of each of the ECMP path of an SR-MPLS 651 Policy. 653 Forwarding plane has various hashing functions available to forward 654 packets on specific ECMP paths. For SR-MPLS Policy, sweeping of 655 entropy label [RFC6790] values can be used in query and response 656 messages to take advantage of the hashing function in forwarding 657 plane to influence the ECMP path taken by them. 659 The considerations for loss measurement for different ECMP paths of 660 an SR-MPLS Policy are outside the scope of this document. 662 10. SR-MPLS Link Extended TE Metrics Advertisements 664 The extended TE metrics for SR-MPLS link delay and loss can be 665 computed using the performance measurement procedures described in 666 this document to advertise in the routing domain as follows: 668 * For OSPF, ISIS, and BGP-LS, protocol extensions defined in 669 [RFC7471], [RFC8570], and [RFC8571], respectively, are used for 670 advertising the extended TE link delay and loss metrics in the 671 network. 673 * The extended TE link delay and loss metrics are advertised for 674 Layer-2 LAG bundle member links in OSPF 675 [I-D.ietf-lsr-ospf-l2bundles] and ISIS [RFC8668] using the same 676 protocol extensions defined in [RFC7471] and [RFC8570], 677 respectively. 679 * The advertised delay-variance metric, Packet Delay Variation (PDV) 680 is computed as described in Section 4.2 of [RFC5481]. 682 * In the absence of one-way delay measurement, the extended TE link 683 one-way delay metrics can be computed using the two-way and round- 684 trip delay values by dividing the values by 2. 686 11. Backwards Compatibility 688 The procedures defined in this document are backwards compatible with 689 the procedures defined in [RFC6374] at both querier and responder. 690 If the responder does not support the new Mandatory TLV Types defined 691 in this document, it MUST return Error 0x17: Unsupported Mandatory 692 TLV Object as per [RFC6374]. 694 12. Security Considerations 696 This document describes the procedures for performance delay and loss 697 measurement for SR-MPLS networks, for both SR-MPLS links and end-to- 698 end SR-MPLS Policies using the mechanisms defined in [RFC6374] and 699 [RFC7876]. The security considerations covered in [RFC6374], 700 [RFC7471], [RFC8570], [RFC8571], and [RFC7876] also apply to the 701 procedures in this document. 703 The procedure defined in this document is intended for deployment in 704 limited domains [RFC8799]. As such, it assumes that a querier node 705 involved in the measurement operation has previously verified the 706 integrity of the path and the identity of the far-end responder. 708 If desired, attacks can be mitigated by performing basic validation 709 and sanity checks, at the querier, of the timestamp and counter 710 fields in received response messages. The minimal state associated 711 with these protocols also limits the extent of measurement disruption 712 that can be caused by a corrupt or invalid message to a single test 713 cycle. 715 The extensions defined in this document may be used for potential 716 "proxying" attacks. For example, a querier may specify a return path 717 that has a destination different from that of the responder. But 718 normally, such attacks will not happen in an SR-MPLS domain where the 719 queriers and responders belong to the same domain [RFC8799]. In 720 order to prevent using the extension defined in this document for 721 proxying any possible attacks, the return path has destination to the 722 same node where the forward path is from. The responder may drop the 723 query messages when it cannot determine whether the Return Path has 724 the destination to the querier. That means, the querier may send a 725 proper source address in the "Source Address" TLV according to the 726 specified Return Path to help the responder to make that decision. 728 13. IANA Considerations 730 IANA is requested to allocate values for the following Mandatory TLV 731 Types for [RFC6374] from the "MPLS Loss/Delay Measurement TLV Object" 732 registry contained within the "Generic Associated Channel (G-ACh) 733 Parameters" registry set: 735 +=======+==================+===============+ 736 | Value | Description | Reference | 737 +=======+==================+===============+ 738 | TBA1 | Block Number TLV | This document | 739 +-------+------------------+---------------+ 740 | TBA2 | Return Path TLV | This document | 741 +-------+------------------+---------------+ 743 Table 1: MPLS Loss/Delay Measurement TLV 744 Types 746 The Block Number TLV is carried in the query and response messages 747 and Return Path TLV is carried in the query messages. 749 IANA is requested to create a sub-registry for "Return Path Sub-TLV 750 Type". All code points in the range 1 through 175 in this registry 751 shall be allocated according to the "IETF Review" procedure as 752 specified in [RFC8126]. Code points in the range 176 through 239 in 753 this registry shall be allocated according to the "First Come First 754 Served" procedure as specified in [RFC8126]. Remaining code points 755 are allocated according to Table 2: 757 +===========+=========================+===============+ 758 | Value | Description | Reference | 759 +===========+=========================+===============+ 760 | 1 - 175 | IETF Review | This document | 761 +-----------+-------------------------+---------------+ 762 | 176 - 239 | First Come First Served | This document | 763 +-----------+-------------------------+---------------+ 764 | 240 - 251 | Experimental Use | This document | 765 +-----------+-------------------------+---------------+ 766 | 252 - 254 | Private Use | This document | 767 +-----------+-------------------------+---------------+ 769 Table 2: Return Path Sub-TLV Type Registry 771 This document defines the following values in the Return Path Sub-TLV 772 Type sub-registry: 774 +=======+=========================================+===============+ 775 | Value | Description | Reference | 776 +=======+=========================================+===============+ 777 | 0 | Reserved | This document | 778 +-------+-----------------------------------------+---------------+ 779 | 1 | SR-MPLS Segment List of the Return Path | This document | 780 +-------+-----------------------------------------+---------------+ 781 | 255 | Reserved | This document | 782 +-------+-----------------------------------------+---------------+ 784 Table 3: Return Path Sub-TLV Types 786 14. References 788 14.1. Normative References 790 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 791 Requirement Levels", BCP 14, RFC 2119, 792 DOI 10.17487/RFC2119, March 1997, 793 . 795 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 796 Measurement for MPLS Networks", RFC 6374, 797 DOI 10.17487/RFC6374, September 2011, 798 . 800 [RFC7876] Bryant, S., Sivabalan, S., and S. Soni, "UDP Return Path 801 for Packet Loss and Delay Measurement for MPLS Networks", 802 RFC 7876, DOI 10.17487/RFC7876, July 2016, 803 . 805 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 806 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 807 May 2017, . 809 14.2. Informative References 811 [IEEE1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock 812 Synchronization Protocol for Networked Measurement and 813 Control Systems", March 2008. 815 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 816 Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, 817 March 2009, . 819 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 820 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 821 RFC 6790, DOI 10.17487/RFC6790, November 2012, 822 . 824 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 825 Previdi, "OSPF Traffic Engineering (TE) Metric 826 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 827 . 829 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 830 Writing an IANA Considerations Section in RFCs", BCP 26, 831 RFC 8126, DOI 10.17487/RFC8126, June 2017, 832 . 834 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 835 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 836 "Alternate-Marking Method for Passive and Hybrid 837 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 838 January 2018, . 840 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 841 Decraene, B., Litkowski, S., and R. Shakir, "Segment 842 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 843 July 2018, . 845 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 846 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 847 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 848 2019, . 850 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and 851 C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of 852 IGP Traffic Engineering Performance Metric Extensions", 853 RFC 8571, DOI 10.17487/RFC8571, March 2019, 854 . 856 [RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, 857 M., and E. Aries, "Advertising Layer 2 Bundle Member Link 858 Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668, 859 December 2019, . 861 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 862 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 863 . 865 [I-D.ietf-spring-segment-routing-policy] 866 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 867 P. Mattes, "Segment Routing Policy Architecture", Work in 868 Progress, Internet-Draft, draft-ietf-spring-segment- 869 routing-policy-13, 28 May 2021, 870 . 873 [I-D.ietf-pim-sr-p2mp-policy] 874 (editor), D. V., Filsfils, C., Parekh, R., Bidgoli, H., 875 and Z. Zhang, "Segment Routing Point-to-Multipoint 876 Policy", Work in Progress, Internet-Draft, draft-ietf-pim- 877 sr-p2mp-policy-03, 23 August 2021, 878 . 881 [I-D.ietf-spring-sr-replication-segment] 882 (editor), D. V., Filsfils, C., Parekh, R., Bidgoli, H., 883 and Z. Zhang, "SR Replication Segment for Multi-point 884 Service Delivery", Work in Progress, Internet-Draft, 885 draft-ietf-spring-sr-replication-segment-05, 20 August 886 2021, . 889 [I-D.ietf-pce-binding-label-sid] 890 Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S., 891 and C. L. (editor), "Carrying Binding Label/Segment 892 Identifier in PCE-based Networks.", Work in Progress, 893 Internet-Draft, draft-ietf-pce-binding-label-sid-10, 10 894 July 2021, . 897 [I-D.ietf-spring-mpls-path-segment] 898 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 899 "Path Segment in MPLS Based Segment Routing Network", Work 900 in Progress, Internet-Draft, draft-ietf-spring-mpls-path- 901 segment-05, 21 August 2021, 902 . 905 [I-D.ietf-lsr-ospf-l2bundles] 906 Talaulikar, K. and P. Psenak, "Advertising L2 Bundle 907 Member Link Attributes in OSPF", Work in Progress, 908 Internet-Draft, draft-ietf-lsr-ospf-l2bundles-01, 27 April 909 2021, . 912 [I-D.ietf-pce-sr-bidir-path] 913 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 914 "Path Computation Element Communication Protocol (PCEP) 915 Extensions for Associated Bidirectional Segment Routing 916 (SR) Paths", Work in Progress, Internet-Draft, draft-ietf- 917 pce-sr-bidir-path-07, 12 July 2021, 918 . 921 [IEEE802.1AX] 922 IEEE Std. 802.1AX, "IEEE Standard for Local and 923 metropolitan area networks - Link Aggregation", November 924 2008. 926 Acknowledgments 928 The authors would like to thank Thierry Couture for the discussions 929 on the use-cases for the performance measurement in segment routing 930 networks. Authors would like to thank Patrick Khordoc for 931 implementing the mechanisms defined in this document. The authors 932 would like to thank Greg Mirsky for providing many useful comments 933 and suggestions. The authors would also like to thank Stewart 934 Bryant, Sam Aldrin, Tarek Saad, and Rajiv Asati for their review 935 comments. Thanks to Huaimo Chen, Yimin Shen, and Xufeng Liu for 936 MPLS-RT expert review. 938 Contributors 940 Sagar Soni 941 Cisco Systems, Inc. 942 Email: sagsoni@cisco.com 944 Zafar Ali 945 Cisco Systems, Inc. 946 Email: zali@cisco.com 948 Pier Luigi Ventre 949 CNIT 950 Italy 951 Email: pierluigi.ventre@cnit.it 953 Authors' Addresses 955 Rakesh Gandhi (editor) 956 Cisco Systems, Inc. 957 Canada 959 Email: rgandhi@cisco.com 960 Clarence Filsfils 961 Cisco Systems, Inc. 963 Email: cfilsfil@cisco.com 965 Daniel Voyer 966 Bell Canada 968 Email: daniel.voyer@bell.ca 970 Stefano Salsano 971 Universita di Roma "Tor Vergata" 972 Italy 974 Email: stefano.salsano@uniroma2.it 976 Mach(Guoyi) Chen 977 Huawei 979 Email: mach.chen@huawei.com