idnits 2.17.00 (12 Aug 2021) /tmp/idnits28395/draft-ietf-mpls-rfc6374-sr-05.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 document date (28 February 2022) is 75 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 (-22) exists of draft-ietf-spring-segment-routing-policy-18 == Outdated reference: A later version (-04) exists of draft-ietf-pim-sr-p2mp-policy-03 == Outdated reference: A later version (-07) exists of draft-ietf-spring-sr-replication-segment-06 == Outdated reference: A later version (-15) exists of draft-ietf-pce-binding-label-sid-13 == Outdated reference: A later version (-03) exists of draft-ietf-lsr-ospf-l2bundles-02 == Outdated reference: A later version (-09) exists of draft-ietf-pce-sr-bidir-path-08 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). 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: 1 September 2022 D. Voyer 6 Bell Canada 7 S. Salsano 8 Universita di Roma "Tor Vergata" 9 M. Chen 10 Huawei 11 28 February 2022 13 Performance Measurement Using RFC 6374 for Segment Routing Networks with 14 MPLS Data Plane 15 draft-ietf-mpls-rfc6374-sr-05 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 1 September 2022. 46 Copyright Notice 48 Copyright (c) 2022 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 Revised BSD License text as 57 described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Revised 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 . . . . . . . . . 7 72 4.2. Response Message for SR-MPLS Links and Policies . . . . . 7 73 4.2.1. One-way Measurement Mode . . . . . . . . . . . . . . 8 74 4.2.2. Two-way Measurement Mode . . . . . . . . . . . . . . 8 75 4.2.3. Loopback Measurement Mode . . . . . . . . . . . . . . 9 76 5. Delay Measurement . . . . . . . . . . . . . . . . . . . . . . 9 77 5.1. Delay Measurement Message Format . . . . . . . . . . . . 9 78 5.2. Timestamps . . . . . . . . . . . . . . . . . . . . . . . 9 79 6. Loss Measurement . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . . 17 93 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 94 14.1. Normative References . . . . . . . . . . . . . . . . . . 18 95 14.2. Informative References . . . . . . . . . . . . . . . . . 19 96 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21 97 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 21 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 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. A 110 comprehensive SR Performance Measurement (PM) toolset is one of the 111 essential requirements to measure network performance to provide 112 Service Level Agreements (SLAs). 114 [RFC6374] specifies protocol mechanisms to enable the efficient and 115 accurate measurement of performance metrics in MPLS networks using 116 query and response messages. [RFC7876] specifies mechanisms for 117 sending and processing out-of-band responses over an UDP return path 118 when receiving RFC 6374 based query messages. These mechanisms are 119 also well-suited in SR-MPLS networks. 121 This document utilizes the mechanisms defined in [RFC6374] for 122 Performance Delay and Loss Measurements in SR-MPLS networks, for both 123 SR-MPLS links and end-to-end SR-MPLS paths including Policies. In 124 addition, this document defines Return Path TLV and Block Number TLV 125 extensions for [RFC6374]. 127 2. Conventions Used in This Document 129 2.1. Requirements Language 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119] [RFC8174] 134 when, and only when, they appear in all capitals, as shown here. 136 2.2. Abbreviations 138 ACH: Associated Channel Header. 140 DM: Delay Measurement. 142 ECMP: Equal Cost Multi-Path. 144 G-ACh: Generic Associated Channel (G-ACh). 146 GAL: Generic Associated Channel (G-ACh) Label. 148 LM: Loss Measurement. 150 MPLS: Multiprotocol Label Switching. 152 NTP: Network Time Protocol. 154 PM: Performance Measurement. 156 PSID: Path Segment Identifier. 158 PTP: Precision Time Protocol. 160 SID: Segment ID. 162 SL: Segment List. 164 SR: Segment Routing. 166 SR-MPLS: Segment Routing with MPLS data plane. 168 TC: Traffic Class. 170 TE: Traffic Engineering. 172 URO: UDP Return Object. 174 2.3. Reference Topology 176 In the reference topology shown in Figure 1, the querier node Q1 177 initiates a query message and the responder node R1 transmits a 178 response message for the query message received. The response 179 message may be sent back to the querier node Q1 in-band on the same 180 path (same set of links and nodes) or a different path in the reverse 181 direction. 183 SR is enabled with MPLS data plane on nodes Q1 and R1. The nodes Q1 184 and R1 may be directly connected via a link enabled with MPLS 185 (Section 2.9.1 of [RFC6374]) or a Point-to-Point (P2P) SR-MPLS path 186 [RFC8402]. The link may be a physical interface, virtual link, or 187 Link Aggregation Group (LAG) [IEEE802.1AX], or LAG member link. The 188 SR-MPLS path may be an SR-MPLS Policy 189 [I-D.ietf-spring-segment-routing-policy] on node Q1 (called head-end) 190 with destination to node R1 (called tail-end). 192 T1 T2 193 / \ 194 +-------+ Query +-------+ 195 | | - - - - - - - - - ->| | 196 | Q1 |=====================| R1 | 197 | |<- - - - - - - - - - | | 198 +-------+ Response +-------+ 199 \ / 200 T4 T3 201 Querier Responder 203 Figure 1: Reference Topology 205 3. Overview 207 For delay and loss measurement in SR-MPLS networks, the procedures 208 defined in [RFC6374] are used in this document. Note that the one- 209 way, two-way and round-trip delay measurements are defined in 210 Section 2.4 of [RFC6374] and are further described in this document 211 for SR-MPLS networks. Similarly, the packet loss measurement is 212 defined in Section 2.2 of [RFC6374] and is further described in this 213 document for SR-MPLS networks. 215 In SR-MPLS networks, the query and response messages defined in 216 [RFC6374] are sent as following: 218 * For delay measurement, the query messages MUST be sent in-band (on 219 the same path as data traffic) for SR-MPLS links and end-to-end 220 SR-MPLS paths to collect transmit and receive timestamps. 222 * For loss measurement, the query messages MUST be sent in-band (on 223 the same path as data traffic) for SR-MPLS links and end-to-end 224 SR-MPLS paths to collect transmit and receive traffic counters 225 (e.g. for traffic received on the incoming link for the link 226 packet loss and for the incoming Path Segment Identifier (PSID) 227 [I-D.ietf-spring-mpls-path-segment] for the end-to-end SR-MPLS 228 path packet loss). 230 It may be desired in SR-MPLS networks that the same path (same set of 231 links and nodes) between the querier and responder be used in both 232 directions of the measurement. This is achieved by using the SR-MPLS 233 Return Path TLV extension defined in this document. 235 The packet loss measurement using Alternate-Marking Method defined in 236 [RFC8321] requires collecting Block Number of the traffic counters. 237 This is achieved by using the Block Number TLV extension defined in 238 this document. 240 The performance measurement procedure for SR-MPLS links can be used 241 to compute extended Traffic Engineering (TE) metrics for delay and 242 loss as described in this document. The metrics are advertised in 243 the network using the routing protocol extensions defined in 244 [RFC7471], [RFC8570], and [RFC8571]. 246 4. Query and Response Messages 248 As described in Section 2.9.1 of [RFC6374], the query and response 249 messages flow over an MPLS Generic Associated Channel (G-ACh). These 250 query and response messages contain G-ACh Label (GAL) (value 13, with 251 S=1). The GAL is followed by an Associated Channel Header (ACH), 252 where Channel Type identifies the measurement message type, and the 253 message payload following the ACH as shown in Figure 2. 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | GAL (value 13) | TC |S| TTL | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 |0 0 0 1|Version| Reserved | Channel Type | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 Figure 2: RFC 6374 Query and Response Message Header 265 4.1. Query Message for SR-MPLS Links and Policies 267 4.1.1. Query Message for SR-MPLS Links 269 A query message as shown in Figure 2 is sent over the SR-MPLS links 270 for both delay and loss measurement using the procedures described in 271 [RFC6374]. For SR-MPLS links, the TTL value MUST be set to 255 in 272 the SR-MPLS header. SR-MPLS encapsulation (e.g. using adjacency SID 273 of the link) can be added for transmitting the query messages for SR- 274 MPLS links. 276 4.1.2. Query Message for SR-MPLS Policies 278 An SR-MPLS Policy may contain a number of Segment Lists (SLs) (i.e. 279 stack of MPLS labels) [I-D.ietf-spring-segment-routing-policy]. The 280 query messages MUST be transmitted for each SL of the SR-MPLS Policy. 281 A query message for an end-to-end SR-MPLS Policy, for both delay and 282 loss measurement, contains an SR-MPLS label stack, with the G-ACh 283 Label (GAL) at the bottom of the stack (with S=1) as shown in 284 Figure 3. For SR-MPLS Policies, the TTL value MUST be set to 255 in 285 the SR-MPLS header. 287 0 1 2 3 288 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 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Label(1) | TC |S| TTL | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 . . 293 . . 294 . . 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Label(n) | TC |S| TTL | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | GAL (value 13) | TC |S| TTL | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 |0 0 0 1|Version| Reserved | Channel Type | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 Figure 3: Example Query Message Header for an End-to-end SR-MPLS 304 Policy 306 The SR-MPLS label stack can be empty (format as shown in Figure 2) to 307 indicate the Implicit NULL label case. 309 For an SR-MPLS Policy, in order to ensure that the query message is 310 processed by the intended responder, Destination Address TLV (Type 311 129) [RFC6374] containing the address of the responder can be sent in 312 the query message. The responder that supports this TLV MUST return 313 Success in "Control Code" [RFC6374] if it is the intended destination 314 for the query. Otherwise, it MUST return 0x15: Error - Invalid 315 Destination Node Identifier [RFC6374]. The Destination Address TLV 316 is applicable to P2P SR-MPLS Policy only. 318 4.2. Response Message for SR-MPLS Links and Policies 319 4.2.1. One-way Measurement Mode 321 In one-way measurement mode defined in Section 2.4 of [RFC6374], the 322 querier can receive "out-of-band" response messages with IP/UDP 323 header by properly setting the UDP Return Object (URO) TLV in the 324 query message. The URO TLV (Type=131) is defined in [RFC7876] and 325 includes the UDP-Destination-Port and IP Address. When the querier 326 sets an IP address and an UDP port in the URO TLV, the response 327 message MUST be sent to that IP address as the destination address 328 and UDP port as the destination port. In addition, the "Control 329 Code" in the query message MUST be set to "out-of-band response 330 requested" [RFC6374]. 332 In one-way delay measurement mode, as per Reference Topology in 333 Figure 1, the timestamps T1 and T2 are collected by the query and 334 response messages. Both these timestamps are used to measure one-way 335 delay as (T2 - T1). 337 4.2.2. Two-way Measurement Mode 339 In two-way measurement mode defined in Section 2.4 of [RFC6374], the 340 response messages are preferred to be sent back in-band on the same 341 link or the same end-to-end SR-MPLS path (same set of links and 342 nodes) in the reverse direction to the querier. 344 For SR-MPLS links, the response message (format as shown in Figure 2) 345 is sent back on the same incoming link where the query message is 346 received. In this case, the "Control Code" in the query message MUST 347 be set to "in-band response requested" [RFC6374]. 349 For end-to-end SR-MPLS paths, the responder transmits the response 350 message (example as shown in Figure 3) on a specific return SR-MPLS 351 path [I-D.ietf-pce-sr-bidir-path]. The querier can request in the 352 query message to the responder to send the response message back on a 353 given return path using the SR-MPLS Segment List sub-TLV in the 354 Return Path TLV defined in this document. 356 In two-way delay measurement mode, as per Reference Topology in 357 Figure 1, all four timestamps T1, T2, T3, and T4 are collected by the 358 query and response messages. All four timestamps are used to measure 359 two-way delay as ((T4 - T1) - (T3 - T2)). 361 4.2.3. Loopback Measurement Mode 363 The Loopback measurement mode defined in Section 2.8 of [RFC6374] is 364 used to measure round-trip delay for a bidirectional circular SR-MPLS 365 path [I-D.ietf-pce-sr-bidir-path]. In this mode, the received query 366 messages MUST NOT be punted out of the fast path in forwarding (i.e. 367 to slow path or control- plane) at the responder. In other words, 368 the responder does not process the payload and generate response 369 messages. The loopback function simply returns the received query 370 message to the querier without responder modifications [RFC6374]. 372 The loopback mode is done by generating "queries" with the Response 373 flag set to 1 and adding the Loopback Request object (Type 3) 374 [RFC6374]. The label stack in query messages in this case carry both 375 the forward and reverse paths in the MPLS header. The GAL is still 376 carried at the bottom of the label stack (with S=1) (example as shown 377 in Figure 3). 379 In loopback delay measurement mode, as per Reference Topology in 380 Figure 1, the timestamps T1 and T4 are collected by the query 381 messages. Both these timestamps are used to measure round-trip delay 382 as (T4 - T1). In this mode, the round-trip delay includes the 383 processing delay on the responder. The responder processing delay 384 component includes only the time required to loop the test packet 385 from the incoming interface to the outgoing interface in forwarding 386 plane. 388 5. Delay Measurement 390 5.1. Delay Measurement Message Format 392 As defined in [RFC6374], MPLS DM query and response messages use 393 Associated Channel Header (ACH) (value 0x000C for delay measurement) 394 [RFC6374], which identifies the message type, and the message payload 395 following the ACH. For both SR-MPLS links and end-to-end SR-MPLS 396 Policies, the same MPLS DM ACH value MUST be used. 398 The DM message payload as defined in Section 3.2 of [RFC6374] is used 399 for delay measurement, for both SR-MPLS links and end-to-end SR-MPLS 400 Policies. 402 5.2. Timestamps 404 The Section 3.4 of [RFC6374] defines timestamp format that can be 405 used for delay measurement. The IEEE 1588 Precision Time Protocol 406 (PTP) timestamp format [IEEE1588] is used by default as described in 407 Appendix A of [RFC6374]. 409 6. Loss Measurement 411 The LM protocol can perform two distinct kinds of loss measurement as 412 described in Section 2.9.8 of [RFC6374]. 414 * In inferred mode, LM will measure the loss of specially generated 415 test messages in order to infer the approximate data plane loss 416 level. Inferred mode LM provides only approximate loss 417 accounting. 419 * In direct mode, LM will directly measure data plane packet loss. 420 Direct mode LM provides perfect loss accounting, but may require 421 hardware support. 423 6.1. Loss Measurement Message Format 425 As defined in [RFC6374], MPLS LM query and response messages use 426 Associated Channel Header (ACH) (value 0x000A for direct loss 427 measurement or value 0x000B for inferred loss measurement), which 428 identifies the message type, and the message payload following the 429 ACH. For both SR-MPLS links and end-to-end SR-MPLS Policies, the 430 same MPLS LM ACH value MUST be used. 432 The LM message payload as defined in Section 3.1 of [RFC6374] is used 433 for loss measurement, for both SR-MPLS links and end-to-end SR-MPLS 434 Policies. 436 6.2. Combined Loss/Delay Measurement Message Format 438 As defined in [RFC6374], Combined DM+LM query and response messages 439 use Associated Channel Header (ACH) (value 0x000D for direct loss and 440 delay measurement or value 0x000E for inferred loss and delay 441 measurement), which identifies the message type, and the message 442 payload following the ACH. For both SR-MPLS links and end-to-end SR- 443 MPLS Policies, the same MPLS DM+LM ACH value MUST be used. 445 The message payload as defined in Section 3.3 of [RFC6374] is used 446 for combined delay and loss measurement, for both SR-MPLS links and 447 end-to-end SR-MPLS Policies. 449 6.3. Counters 451 The Path Segment Identifier (PSID) 452 [I-D.ietf-spring-mpls-path-segment] carried in the received data 453 packet for the traffic flow under measurement can be used for 454 accounting received traffic on the egress node of the SR-MPLS Policy. 455 In direct mode, the PSID in the received query message as shown in 456 Figure 4 can be used to associate the receive traffic counter on the 457 responder to detect the transmit packet loss for the end-to-end SR- 458 MPLS Policy. 460 In inferred mode, the PSID in the received query messages as shown in 461 Figure 4 can be used to count the received query messages on the 462 responder to detect the transmit packet loss for an end-to-end SR- 463 MPLS Policy. 465 0 1 2 3 466 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 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | PSID | TC |S| TTL | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | GAL (value 13) | TC |S| TTL | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 |0 0 0 1|Version| Reserved | Channel Type | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 Figure 4: Example With Path Segment Identifier for SR-MPLS Policy 477 Different values of PSID can be used to measure packet loss per SR- 478 MPLS Policy, per Candidate Path or per Segment List of the SR-MPLS 479 Policy [I-D.ietf-spring-segment-routing-policy]. 481 7. TLV Extensions 483 7.1. Return Path TLV Extension 485 In two-way measurement mode, the responder transmits the response 486 message on a specific return path. The querier can request in the 487 query message to the responder to send a response message back on a 488 given return path (e.g. co-routed SR-MPLS path for two-way 489 measurement). This way the responder avoids creating and maintaining 490 extra dynamic SR states for the return paths for two-way measurement. 492 The querier may not be reachable from the responder. The querier in 493 this case MUST send its reachability path information to the 494 responder using the Return Path TLV. 496 [RFC6374] defines query and response messages those can include or 497 more optional TLVs. New TLV Type (TBA1) is defined in this document 498 for Return Path TLV to carry return path information in query 499 messages. The format of the Return Path TLV is shown in Figure 5: 501 0 1 2 3 502 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 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Type = TBA1 | Length | Reserved | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Return Path Sub-TLV | 507 . . 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 Figure 5: Return Path TLV 512 The Return Path TLV is a Mandatory TLV Type. The querier MUST only 513 insert one Return Path TLV in the query message. The responder that 514 supports this TLV, MUST only process the first Return Path TLV and 515 ignore the other Return Path TLVs if present. The responder that 516 supports this TLV, also MUST send response message back on the return 517 path specified in the Return Path TLV. The responder also MUST NOT 518 add Return Path TLV in the response message. The Reserved field MUST 519 be set to 0 and MUST be ignored on the receive side. 521 7.1.1. Return Path Sub-TLV Extension 523 The Return Path TLV contains a Sub-TLV to carry the return path. The 524 format of the SR-MPLS Segment List Sub-TLV is shown in Figure 6. The 525 SR-MPLS Segment List Sub-TLV contains SR-MPLS Label Stack. The Label 526 entries in the Segment List MUST be in network order. The SR-MPLS 527 Segment List Sub-TLV in the Return Path TLV is of the following Type: 529 * Type (value 1): SR-MPLS Segment List of the Return Path 531 0 1 2 3 532 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 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | Type=1 | Length | Reserved | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Label(1) | 537 . . 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 . . 540 . . 541 . . 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Label(n) (bottom of stack) | 544 . . 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 Figure 6: SR-MPLS Segment List Sub-TLV in Return Path TLV 549 An SR-MPLS Segment List Sub-TLV may carry only Binding SID 550 [I-D.ietf-pce-binding-label-sid] of the Return SR-MPLS Policy. 552 The Return Path TLV MUST carry only one Return Path Sub-TLV. The 553 responder that supports this Sub-TLV, MUST only process the first 554 Return Path Sub-TLV and ignore the other Return Path Sub-TLVs if 555 present. The responder that supports this Sub-TLV, also MUST send 556 response message back on the return path specified in the Return Path 557 Sub-TLV. The Reserved field MUST be set to 0 and MUST be ignored on 558 the receive side. 560 Note that in addition to the P2P SR-MPLS paths, the SR-MPLS Segment 561 List Sub-TLV is also applicable to the P2MP SR-MPLS paths. For 562 example, for P2MP SR-MPLS paths, it may only carry the Node Segment 563 Identifier of the querier in order for the response to follow an SR- 564 MPLS path back to the querier. 566 7.2. Block Number TLV Extension 568 The direct mode loss measurement using Alternate-Marking Method 569 defined in [RFC8321] requires collecting Block Number of the counters 570 for the data traffic flow under measurement. To be able to correlate 571 the transmit and receive traffic counters of the matching Block 572 Number, the Block Number of the traffic counters is carried in the LM 573 query and response messages. 575 [RFC6374] defines query and response messages those can include one 576 or more optional TLVs. New TLV Type (value TBA2) is defined in this 577 document to carry the Block Number (8-bit) of the traffic counters in 578 the LM query and response messages. The format of the Block Number 579 TLV is shown in Figure 7: 581 0 1 2 3 582 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 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Type = TBA2 | Length | Reserved |R| Block Number | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 Figure 7: Block Number TLV 589 The Block Number TLV is a Mandatory TLV Type. The querier MUST only 590 insert one Block Number TLV in the query message to identify the 591 Block Number for the traffic counters in the forward direction. The 592 responder that supports this TLV, MUST only inert one Block Number 593 TLV in the response message to identify the Block Number for the 594 traffic counters in the reverse direction. The responder also MUST 595 return the first Block Number TLV from the query message and ignore 596 the other Block Number TLVs if present. The R Flag MUST be clear in 597 the query message and set in the response message. The Reserved 598 field MUST be set to 0 and MUST be ignored on the receive side. 600 8. Performance Measurement for P2MP SR-MPLS Policies 602 The Point-to-Multipoint (P2MP) SR-MPLS path that originates from a 603 root node terminates on multiple destinations called leaf nodes (e.g. 604 P2MP SR-MPLS Policy [I-D.ietf-pim-sr-p2mp-policy]). 606 The procedures for delay and loss measurement described in this 607 document for end-to-end P2P SR-MPLS Policies are also equally 608 applicable to the P2MP SR-MPLS Policies. The procedure for one-way 609 measurement is defined as following: 611 * The querier root node transmits query messages using the Tree-SID 612 defined in [I-D.ietf-pim-sr-p2mp-policy] for the P2MP SR-MPLS 613 Policy as shown in Figure 8. The query messages may contain the 614 replication SID as defined in 615 [I-D.ietf-spring-sr-replication-segment]. 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. That means, the querier may send a 727 proper source address in the "Source Address" TLV according to the 728 specified Return Path to help the responder to make that decision. 730 13. IANA Considerations 732 IANA is requested to allocate values for the following Mandatory TLV 733 Types for [RFC6374] from the "MPLS Loss/Delay Measurement TLV Object" 734 registry contained within the "Generic Associated Channel (G-ACh) 735 Parameters" registry set: 737 +=======+==================+===============+ 738 | Value | Description | Reference | 739 +=======+==================+===============+ 740 | TBA1 | Return Path TLV | This document | 741 +-------+------------------+---------------+ 742 | TBA2 | Block Number TLV | This document | 743 +-------+------------------+---------------+ 745 Table 1: MPLS Loss/Delay Measurement TLV 746 Types 748 The Block Number TLV is carried in the query and response messages 749 and Return Path TLV is carried in the query messages. 751 IANA is requested to create a sub-registry for "Return Path Sub-TLV 752 Type". All code points in the range 1 through 175 in this registry 753 shall be allocated according to the "IETF Review" procedure as 754 specified in [RFC8126]. Code points in the range 176 through 239 in 755 this registry shall be allocated according to the "First Come First 756 Served" procedure as specified in [RFC8126]. Remaining code points 757 are allocated according to Table 2: 759 +===========+=========================+===============+ 760 | Value | Description | Reference | 761 +===========+=========================+===============+ 762 | 1 - 175 | IETF Review | This document | 763 +-----------+-------------------------+---------------+ 764 | 176 - 239 | First Come First Served | This document | 765 +-----------+-------------------------+---------------+ 766 | 240 - 251 | Experimental Use | This document | 767 +-----------+-------------------------+---------------+ 768 | 252 - 254 | Private Use | This document | 769 +-----------+-------------------------+---------------+ 771 Table 2: Return Path Sub-TLV Type Registry 773 This document defines the following values in the Return Path Sub-TLV 774 Type sub-registry: 776 +=======+=========================================+===============+ 777 | Value | Description | Reference | 778 +=======+=========================================+===============+ 779 | 0 | Reserved | This document | 780 +-------+-----------------------------------------+---------------+ 781 | 1 | SR-MPLS Segment List of the Return Path | This document | 782 +-------+-----------------------------------------+---------------+ 783 | 255 | Reserved | This document | 784 +-------+-----------------------------------------+---------------+ 786 Table 3: Return Path Sub-TLV Types 788 14. References 790 14.1. Normative References 792 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 793 Requirement Levels", BCP 14, RFC 2119, 794 DOI 10.17487/RFC2119, March 1997, 795 . 797 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 798 Measurement for MPLS Networks", RFC 6374, 799 DOI 10.17487/RFC6374, September 2011, 800 . 802 [RFC7876] Bryant, S., Sivabalan, S., and S. Soni, "UDP Return Path 803 for Packet Loss and Delay Measurement for MPLS Networks", 804 RFC 7876, DOI 10.17487/RFC7876, July 2016, 805 . 807 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 808 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 809 May 2017, . 811 14.2. Informative References 813 [IEEE1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock 814 Synchronization Protocol for Networked Measurement and 815 Control Systems", March 2008. 817 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 818 Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, 819 March 2009, . 821 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 822 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 823 RFC 6790, DOI 10.17487/RFC6790, November 2012, 824 . 826 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 827 Previdi, "OSPF Traffic Engineering (TE) Metric 828 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 829 . 831 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 832 Writing an IANA Considerations Section in RFCs", BCP 26, 833 RFC 8126, DOI 10.17487/RFC8126, June 2017, 834 . 836 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 837 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 838 "Alternate-Marking Method for Passive and Hybrid 839 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 840 January 2018, . 842 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 843 Decraene, B., Litkowski, S., and R. Shakir, "Segment 844 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 845 July 2018, . 847 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 848 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 849 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 850 2019, . 852 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and 853 C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of 854 IGP Traffic Engineering Performance Metric Extensions", 855 RFC 8571, DOI 10.17487/RFC8571, March 2019, 856 . 858 [RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, 859 M., and E. Aries, "Advertising Layer 2 Bundle Member Link 860 Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668, 861 December 2019, . 863 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 864 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 865 . 867 [I-D.ietf-spring-segment-routing-policy] 868 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 869 P. Mattes, "Segment Routing Policy Architecture", Work in 870 Progress, Internet-Draft, draft-ietf-spring-segment- 871 routing-policy-18, 17 February 2022, 872 . 875 [I-D.ietf-pim-sr-p2mp-policy] 876 (editor), D. V., Filsfils, C., Parekh, R., Bidgoli, H., 877 and Z. Zhang, "Segment Routing Point-to-Multipoint 878 Policy", Work in Progress, Internet-Draft, draft-ietf-pim- 879 sr-p2mp-policy-03, 23 August 2021, 880 . 883 [I-D.ietf-spring-sr-replication-segment] 884 (editor), D. V., Filsfils, C., Parekh, R., Bidgoli, H., 885 and Z. Zhang, "SR Replication Segment for Multi-point 886 Service Delivery", Work in Progress, Internet-Draft, 887 draft-ietf-spring-sr-replication-segment-06, 25 October 888 2021, . 891 [I-D.ietf-pce-binding-label-sid] 892 Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S., 893 and C. L. (editor), "Carrying Binding Label/Segment 894 Identifier (SID) in PCE-based Networks.", Work in 895 Progress, Internet-Draft, draft-ietf-pce-binding-label- 896 sid-13, 10 February 2022, 897 . 900 [I-D.ietf-spring-mpls-path-segment] 901 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 902 "Path Segment in MPLS Based Segment Routing Network", Work 903 in Progress, Internet-Draft, draft-ietf-spring-mpls-path- 904 segment-07, 20 December 2021, 905 . 908 [I-D.ietf-lsr-ospf-l2bundles] 909 Talaulikar, K. and P. Psenak, "Advertising L2 Bundle 910 Member Link Attributes in OSPF", Work in Progress, 911 Internet-Draft, draft-ietf-lsr-ospf-l2bundles-02, 22 912 October 2021, . 915 [I-D.ietf-pce-sr-bidir-path] 916 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 917 "Path Computation Element Communication Protocol (PCEP) 918 Extensions for Associated Bidirectional Segment Routing 919 (SR) Paths", Work in Progress, Internet-Draft, draft-ietf- 920 pce-sr-bidir-path-08, 9 September 2021, 921 . 924 [IEEE802.1AX] 925 IEEE Std. 802.1AX, "IEEE Standard for Local and 926 metropolitan area networks - Link Aggregation", November 927 2008. 929 Acknowledgments 931 The authors would like to thank Thierry Couture for the discussions 932 on the use-cases for the performance measurement in segment routing 933 networks. Authors would like to thank Patrick Khordoc for 934 implementing the mechanisms defined in this document. The authors 935 would like to thank Greg Mirsky for providing many useful comments 936 and suggestions. The authors would also like to thank Stewart 937 Bryant, Sam Aldrin, Tarek Saad, and Rajiv Asati for their review 938 comments. Thanks to Huaimo Chen, Yimin Shen, and Xufeng Liu for 939 MPLS-RT expert review. 941 Contributors 942 Sagar Soni 943 Cisco Systems, Inc. 944 Email: sagsoni@cisco.com 946 Zafar Ali 947 Cisco Systems, Inc. 948 Email: zali@cisco.com 950 Pier Luigi Ventre 951 CNIT 952 Italy 953 Email: pierluigi.ventre@cnit.it 955 Authors' Addresses 957 Rakesh Gandhi (editor) 958 Cisco Systems, Inc. 959 Canada 960 Email: rgandhi@cisco.com 962 Clarence Filsfils 963 Cisco Systems, Inc. 964 Email: cfilsfil@cisco.com 966 Daniel Voyer 967 Bell Canada 968 Email: daniel.voyer@bell.ca 970 Stefano Salsano 971 Universita di Roma "Tor Vergata" 972 Italy 973 Email: stefano.salsano@uniroma2.it 975 Mach(Guoyi) Chen 976 Huawei 977 Email: mach.chen@huawei.com