idnits 2.17.1 draft-ietf-idr-sr-policy-ifit-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Implementation of IFIT methods (IOAM and Alternate Marking) are mindful of security and privacy concerns, as explained in [I-D.ietf-ippm-ioam-data] and RFC 8321 [RFC8321]. Anyway incorrect IFIT parameters in the BGP extension SHOULD not have an adverse effect on the SR Policy as well as on the network, since it affects only the operation of the telemetry methodology. -- The document date (November 19, 2020) is 1253 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 (-17) exists of draft-ietf-6man-ipv6-alt-mark-02 == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-11 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-10 == Outdated reference: A later version (-11) exists of draft-ietf-ippm-ioam-direct-export-02 == Outdated reference: A later version (-10) exists of draft-ietf-ippm-ioam-flags-03 == Outdated reference: A later version (-12) exists of draft-ietf-ippm-ioam-ipv6-options-04 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-09 ** Downref: Normative reference to an Informational RFC: RFC 7799 ** Obsolete normative reference: RFC 8321 (Obsoleted by RFC 9341) == Outdated reference: A later version (-06) exists of draft-chen-pce-pcep-ifit-01 == Outdated reference: A later version (-06) exists of draft-gandhi-mpls-ioam-sr-03 == Outdated reference: A later version (-10) exists of draft-ietf-mpls-rfc6374-sfl-07 Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR F. Qin 3 Internet-Draft China Mobile 4 Intended status: Standards Track H. Yuan 5 Expires: May 23, 2021 UnionPay 6 T. Zhou 7 G. Fioccola 8 Y. Wang 9 Huawei 10 November 19, 2020 12 BGP SR Policy Extensions to Enable IFIT 13 draft-ietf-idr-sr-policy-ifit-00 15 Abstract 17 Segment Routing (SR) policy is a set of candidate SR paths consisting 18 of one or more segment lists and necessary path attributes. It 19 enables instantiation of an ordered list of segments with a specific 20 intent for traffic steering. In-situ Flow Information Telemetry 21 (IFIT) refers to network OAM data plane on-path telemetry techniques, 22 in particular the most popular are In-situ OAM (IOAM) and Alternate 23 Marking. This document defines extensions to BGP to distribute SR 24 policies carrying IFIT information. So that IFIT methods can be 25 enabled automatically when the SR policy is applied. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on May 23, 2021. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. IFIT methods for SR Policy . . . . . . . . . . . . . . . . . 4 70 4. IFIT Attributes in SR Policy . . . . . . . . . . . . . . . . 4 71 5. IFIT Attributes Sub-TLV . . . . . . . . . . . . . . . . . . . 5 72 5.1. IOAM Pre-allocated Trace Option Sub-TLV . . . . . . . . . 6 73 5.2. IOAM Incremental Trace Option Sub-TLV . . . . . . . . . . 7 74 5.3. IOAM Directly Export Option Sub-TLV . . . . . . . . . . . 8 75 5.4. IOAM Edge-to-Edge Option Sub-TLV . . . . . . . . . . . . 9 76 5.5. Enhanced Alternate Marking (EAM) sub-TLV . . . . . . . . 9 77 6. SR Policy Operations with IFIT Attributes . . . . . . . . . . 10 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 80 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 83 10.2. Informative References . . . . . . . . . . . . . . . . . 13 84 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 87 1. Introduction 89 Segment Routing (SR) policy [I-D.ietf-spring-segment-routing-policy] 90 is a set of candidate SR paths consisting of one or more segment 91 lists and necessary path attributes. It enables instantiation of an 92 ordered list of segments with a specific intent for traffic steering. 94 In-situ Flow Information Telemetry (IFIT) denotes a family of flow- 95 oriented on-path telemetry techniques (e.g. IOAM, Alternate 96 Marking), which can provide high-precision flow insight and real-time 97 network issue notification (e.g., jitter, latency, packet loss).In 98 particular, IFIT refers to network OAM data plane on-path telemetry 99 techniques, including In-situ OAM (IOAM) [I-D.ietf-ippm-ioam-data] 100 and Alternate Marking [RFC8321]. It can provide flow information on 101 the entire forwarding path on a per-packet basis in real time. 103 An automatic network requires the Service Level Agreement (SLA) 104 monitoring on the deployed service. So that the system can quickly 105 detect the SLA violation or the performance degradation, hence to 106 change the service deployment. For this reason, the SR policy native 107 IFIT can facilitate the closed loop control and enable the automation 108 of SR service. 110 This document defines extensions to Border Gateway Protocol (BGP) to 111 distribute SR policies carrying IFIT information. So that IFIT 112 behavior can be enabled automatically when the SR policy is applied. 114 This BGP extension allows to signal the IFIT capabilities together 115 with the SR-policy. In this way IFIT methods are automatically 116 activated and running. The flexibility and dynamicity of the IFIT 117 applications are given by the use of additional functions on the 118 controller and on the network nodes, but this is out of scope here. 120 2. Motivation 122 IFIT Methods are being introduced in multiple protocols and below is 123 a proper picture of the relevant documents for Segment Routing. 124 Indeed the IFIT methods are becoming mature for Segment Routing over 125 the MPLS data plane (SR-MPLS) and Segment Routing over IPv6 data 126 plane (SRv6), that is the main focus of this draft: 128 IOAM: the reference documents for the data plane are 129 [I-D.ietf-ippm-ioam-ipv6-options] for SRv6 and 130 [I-D.gandhi-mpls-ioam-sr] for SR-MPLS. 132 Alternate Marking: the reference documents for the data plane are 133 [I-D.ietf-6man-ipv6-alt-mark] for SRv6 and 134 [I-D.ietf-mpls-rfc6374-sfl], [I-D.gandhi-mpls-rfc6374-sr] for SR- 135 MPLS. 137 The definition of these data plane IFIT methods for SR-MPLS and SRv6 138 imply requirements for various routing protocols, such as BGP, and 139 this document aims to define BGP extensions to distribute SR policies 140 carrying IFIT information. This allows to signal the IFIT 141 capabilities so IFIT methods are automatically configured and ready 142 to run when the SR Policy candidate paths are distributed through 143 BGP. 145 It is to be noted that, for PCEP, [I-D.chen-pce-pcep-ifit] proposes 146 the extensions to PCEP to distribute paths carrying IFIT information 147 and therefore to enable IFIT methods for SR policy too. 149 3. IFIT methods for SR Policy 151 In-situ Operations, Administration, and Maintenance (IOAM) 152 [I-D.ietf-ippm-ioam-data] records operational and telemetry 153 information in the packet while the packet traverses a path between 154 two points in the network. In terms of the classification given in 155 RFC 7799 [RFC7799] IOAM could be categorized as Hybrid Type 1. IOAM 156 mechanisms can be leveraged where active OAM do not apply or do not 157 offer the desired results. When SR policy enables the IOAM, the IOAM 158 header will be inserted into every packet of the traffic that is 159 steered into the SR paths. 161 The Alternate Marking [RFC8321]technique is an hybrid performance 162 measurement method, per RFC 7799 [RFC7799] classification of 163 measurement methods. Because this method is based on marking 164 consecutive batches of packets. It can be used to measure packet 165 loss, latency, and jitter on live traffic. 167 This document aims to define the control plane. While the relevant 168 documents for the data plane application of IOAM and Alternate 169 Marking are respectively [I-D.ietf-ippm-ioam-ipv6-options] and 170 [I-D.ietf-6man-ipv6-alt-mark] for Segment Routing over IPv6 data 171 plane (SRv6). 173 4. IFIT Attributes in SR Policy 175 As defined in [I-D.ietf-idr-segment-routing-te-policy], the SR Policy 176 encoding structure is as follows: 178 SR Policy SAFI NLRI: 179 Attributes: 180 Tunnel Encaps Attribute (23) 181 Tunnel Type: SR Policy 182 Binding SID 183 Preference 184 Priority 185 Policy Name 186 Explicit NULL Label Policy (ENLP) 187 Segment List 188 Weight 189 Segment 190 Segment 191 ... 192 ... 194 A candidate path includes multiple SR paths, each of which is 195 specified by a segment list. IFIT can be applied to the candidate 196 path, so that all the SR paths can be monitored in the same way. The 197 new SR Policy encoding structure is expressed as below: 199 SR Policy SAFI NLRI: 200 Attributes: 201 Tunnel Encaps Attribute (23) 202 Tunnel Type: SR Policy 203 Binding SID 204 Preference 205 Priority 206 Policy Name 207 Explicit NULL Label Policy (ENLP) 208 IFIT Attributes 209 Segment List 210 Weight 211 Segment 212 Segment 213 ... 214 ... 216 IFIT attributes can be attached at the candidate path level as sub- 217 TLVs. There may be different IFIT tools. The following sections 218 will describe the requirement and usage of different IFIT tools, and 219 define the corresponding sub-TLV encoding in BGP. 221 Note that the IFIT attributes here described can also be generalized 222 and included as sub-TLVs for other SAFIs and NLRIs. 224 5. IFIT Attributes Sub-TLV 226 The format of the IFIT Attributes Sub-TLV is defined as follows: 228 0 1 2 3 229 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 230 +---------------+---------------+ 231 | Type | Length | 232 +-------------------------------+---------------+---------------+ 233 | | 234 // sub-TLVs // 235 | | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 Fig. 1 IFIT Attributes Sub-TLV 240 Where: 242 Type: to be assigned by IANA. 244 Length: the total length of the value field not including Type and 245 Length fields. 247 sub-TLVs currently defined: 249 * IOAM Pre-allocated Trace Option Sub-TLV, 251 * IOAM Incremental Trace Option Sub-TLV, 253 * IOAM Directly Export Option Sub-TLV, 255 * IOAM Edge-to-Edge Option Sub-TLV, 257 * Enhanced Alternate Marking (EAM) sub-TLV. 259 The presence of the IFIT Attributes Sub-TLV implies support of IFIT 260 methods (IOAM and/or Alternate Marking). It is worth mentioning that 261 IOAM and Alternate Marking can be activated one at a time or can 262 coexist; so it is possible to have only IOAM or only Alternate 263 Marking enabled as Sub-TLVs. The sub-TLVs currently defined for IOAM 264 and Alternate Marking are detailed in the next sections. 266 5.1. IOAM Pre-allocated Trace Option Sub-TLV 268 The IOAM tracing data is expected to be collected at every node that 269 a packet traverses to ensure visibility into the entire path a packet 270 takes within an IOAM domain. The preallocated tracing option will 271 create pre-allocated space for each node to populate its information. 273 The format of IOAM pre-allocated trace option sub-TLV is defined as 274 follows: 276 0 1 2 3 277 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 278 +---------------+---------------+-------------------------------+ 279 | Type=1 | Length=6 | Namespace ID | 280 +---------------+---------------+--------------+--------+-------+ 281 | IOAM Trace Type | Flags | Rsvd | 282 +----------------------------------------------+--------+-------+ 284 Fig. 2 IOAM Pre-allocated Trace Option Sub-TLV 286 Where: 288 Type: 1 (to be assigned by IANA). 290 Length: 6, it is the total length of the value field (not including 291 Type and Length fields). 293 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 294 definition is the same as described in section 4.4 of 295 [I-D.ietf-ippm-ioam-data]. 297 IOAM Trace Type: A 24-bit identifier which specifies which data types 298 are used in the node data list. The definition is the same as 299 described in section 4.4 of [I-D.ietf-ippm-ioam-data]. 301 Flags: A 4-bit field. The definition is the same as described in 302 [I-D.ietf-ippm-ioam-flags] and section 4.4 of 303 [I-D.ietf-ippm-ioam-data]. 305 Rsvd: A 4-bit field reserved for further usage. It MUST be zero. 307 5.2. IOAM Incremental Trace Option Sub-TLV 309 The incremental tracing option contains a variable node data fields 310 where each node allocates and pushes its node data immediately 311 following the option header. 313 The format of IOAM incremental trace option sub-TLV is defined as 314 follows: 316 0 1 2 3 317 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 318 +---------------+---------------+-------------------------------+ 319 | Type=2 | Length=6 | Namespace ID | 320 +---------------+---------------+--------------+--------+-------+ 321 | IOAM Trace Type | Flags | Rsvd | 322 +----------------------------------------------+--------+-------+ 324 Fig. 3 IOAM Incremental Trace Option Sub-TLV 326 Where: 328 Type: 2 (to be assigned by IANA). 330 Length: 6, it is the total length of the value field (not including 331 Type and Length fields). 333 All the other fields definistion is the same as the pre-allocated 334 trace option sub-TLV in section 4.1. 336 5.3. IOAM Directly Export Option Sub-TLV 338 IOAM directly export option is used as a trigger for IOAM data to be 339 directly exported to a collector without being pushed into in-flight 340 data packets. 342 The format of IOAM directly export option sub-TLV is defined as 343 follows: 345 0 1 2 3 346 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 347 +---------------+---------------+ 348 | Type=3 | Length=12 | 349 +-----------------------------------------------+---------------+ 350 | Namespace ID | Flags | 351 +-------------------------------+---------------+---------------+ 352 | IOAM Trace Type | Rsvd | 353 +-----------------------------------------------+---------------+ 354 | Flow ID | 355 +---------------------------------------------------------------+ 357 Fig. 4 IOAM Directly Export Option Sub-TLV 359 Where: 361 Type: 3 (to be assigned by IANA). 363 Length: 12, it is the total length of the value field (not including 364 Type and Length fields). 366 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 367 definition is the same as described in section 4.4 of 368 [I-D.ietf-ippm-ioam-data]. 370 IOAM Trace Type: A 24-bit identifier which specifies which data types 371 are used in the node data list. The definition is the same as 372 described in section 4.4 of [I-D.ietf-ippm-ioam-data]. 374 Flags: A 16-bit field. The definition is the same as described in 375 section 3.2 of [I-D.ietf-ippm-ioam-direct-export]. 377 Flow ID: A 32-bit flow identifier. The definition is the same as 378 described in section 3.2 of [I-D.ietf-ippm-ioam-direct-export]. 380 Rsvd: A 4-bit field reserved for further usage. It MUST be zero. 382 5.4. IOAM Edge-to-Edge Option Sub-TLV 384 The IOAM edge to edge option is to carry data that is added by the 385 IOAM encapsulating node and interpreted by IOAM decapsulating node. 387 The format of IOAM edge-to-edge option sub-TLV is defined as follows: 389 0 1 2 3 390 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 391 +---------------+---------------+ 392 | Type=4 | Length=4 | 393 +-----------------------------------------------+---------------+ 394 | Namespace ID | IOAM E2E Type | 395 +-------------------------------+-------------------------------+ 397 Fig. 5 IOAM Edge-to-Edge Option Sub-TLV 399 Where: 401 Type: 4 (to be assigned by IANA). 403 Length: 4, it is the total length of the value field (not including 404 Type and Length fields). 406 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 407 definition is the same as described in section 4.6 of 408 [I-D.ietf-ippm-ioam-data]. 410 IOAM E2E Type: A 16-bit identifier which specifies which data types 411 are used in the E2E option data. The definition is the same as 412 described in section 4.6 of [I-D.ietf-ippm-ioam-data]. 414 5.5. Enhanced Alternate Marking (EAM) sub-TLV 416 The format of Enhanced Alternate Marking (EAM) sub-TLV is defined as 417 follows: 419 0 1 2 3 420 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 421 +---------------+---------------+ 422 | Type=5 | Length=4 | 423 +-------------------------------+-------+-------+-------+-------+ 424 | FlowMonID | Period | Rsvd | 425 +---------------------------------------+---------------+-------+ 427 Fig. 6 Enhanced Alternate Marking Sub-TLV 429 Where: 431 Type: 5 (to be assigned by IANA). 433 Length: 4, it is the total length of the value field (not including 434 Type and Length fields). 436 FlowMonID: A 20-bit identifier to uniquely identify a monitored flow 437 within the measurement domain. The definition is the same as 438 described in section 5.3 of [I-D.ietf-6man-ipv6-alt-mark]. 440 Period: Time interval between two alternate marking period. The unit 441 is second. 443 Rsvd: A 4-bit field reserved for further usage. It MUST be zero. 445 6. SR Policy Operations with IFIT Attributes 447 The details of SR Policy installation and use are specified in 448 [I-D.ietf-spring-segment-routing-policy]. This document complements 449 SR Policy Operations described in 450 [I-D.ietf-idr-segment-routing-te-policy] by adding the IFIT 451 Attributes. 453 The operations described in [I-D.ietf-idr-segment-routing-te-policy] 454 are always valid. The only difference is the addition of IFIT 455 Attributes Sub-TLVs for the SR Policy NLRI, that can affect its 456 acceptance by a BGP speaker, but the implementation MAY provide an 457 option for ignoring the unrecognized or unsupported IFIT sub-TLVs. 458 SR Policy NLRIs that have been determined acceptable, usable and 459 valid can be evaluated for propagation, including the IFIT 460 information. 462 The error handling actions are also described in 463 [I-D.ietf-idr-segment-routing-te-policy]. 465 The validation of the IFIT Attributes sub-TLVs introduced in this 466 document MUST be performed to determine if they are malformed or 467 invalid. The validation of the individual fields of the IFIT 468 Attributes sub-TLVs are handled by the SRPM (SR Policy Module). 470 7. IANA Considerations 472 This document defines a new sub-TLV in the registry "BGP Tunnel 473 Encapsulation Attribute sub-TLVs" to be assigned by IANA: 475 Codepoint Description Reference 476 ------------------------------------------------------------- 477 TBD1 IFIT Attributes Sub-TLV This document 478 This document requests creation of a new registry called "IFIT 479 Attributes Sub-TLVs". The allocation policy of this registry is 480 "Specification Required" according to RFC 8126 [RFC8126]. 482 Following initial Sub-TLV codepoints are assigned by this document: 484 Value Description Reference 485 ------------------------------------------------------------- 486 1 IOAM Pre-allocated Trace Option Sub-TLV This document 488 2 IOAM Incremental Trace Option Sub-TLV This document 490 3 IOAM Directly Export Option Sub-TLV This document 492 4 IOAM Edge-to-Edge Option Sub-TLV This document 494 5 Enhanced Alternate Marking Sub-TLV This document 496 8. Security Considerations 498 The security mechanisms of the base BGP security model apply to the 499 extensions described in this document as well. See the Security 500 Considerations section of [I-D.ietf-idr-segment-routing-te-policy]. 502 SR operates within a trusted SR domain RFC 8402 [RFC8402] and its 503 security considerations also apply to BGP sessions when carrying SR 504 Policy information. The isolation of BGP SR Policy SAFI peering 505 sessions may be used to ensure that the SR Policy information is not 506 advertised outside the SR domain. Additionally, only trusted nodes 507 (that include both routers and controller applications) within the SR 508 domain must be configured to receive such information. 510 Implementation of IFIT methods (IOAM and Alternate Marking) are 511 mindful of security and privacy concerns, as explained in 512 [I-D.ietf-ippm-ioam-data] and RFC 8321 [RFC8321]. Anyway incorrect 513 IFIT parameters in the BGP extension SHOULD not have an adverse 514 effect on the SR Policy as well as on the network, since it affects 515 only the operation of the telemetry methodology. 517 9. Acknowledgements 519 The authors of this document would like to thank Ketan Talaulikar, 520 Joel Halpern, Jie Dong for their comments and review of this 521 document. 523 10. References 525 10.1. Normative References 527 [I-D.ietf-6man-ipv6-alt-mark] 528 Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. 529 Pang, "IPv6 Application of the Alternate Marking Method", 530 draft-ietf-6man-ipv6-alt-mark-02 (work in progress), 531 October 2020. 533 [I-D.ietf-idr-segment-routing-te-policy] 534 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 535 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 536 Routing Policies in BGP", draft-ietf-idr-segment-routing- 537 te-policy-11 (work in progress), November 2020. 539 [I-D.ietf-ippm-ioam-data] 540 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 541 for In-situ OAM", draft-ietf-ippm-ioam-data-10 (work in 542 progress), July 2020. 544 [I-D.ietf-ippm-ioam-direct-export] 545 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 546 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 547 OAM Direct Exporting", draft-ietf-ippm-ioam-direct- 548 export-02 (work in progress), November 2020. 550 [I-D.ietf-ippm-ioam-flags] 551 Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R., 552 Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., and J. 553 Lemon, "In-situ OAM Flags", draft-ietf-ippm-ioam-flags-03 554 (work in progress), October 2020. 556 [I-D.ietf-ippm-ioam-ipv6-options] 557 Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., 558 Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., 559 Lapukhov, P., Spiegel, M., Krishnan, S., Asati, R., and M. 560 Smith, "In-situ OAM IPv6 Options", draft-ietf-ippm-ioam- 561 ipv6-options-04 (work in progress), November 2020. 563 [I-D.ietf-spring-segment-routing-policy] 564 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 565 P. Mattes, "Segment Routing Policy Architecture", draft- 566 ietf-spring-segment-routing-policy-09 (work in progress), 567 November 2020. 569 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 570 Requirement Levels", BCP 14, RFC 2119, 571 DOI 10.17487/RFC2119, March 1997, 572 . 574 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 575 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 576 May 2016, . 578 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 579 Writing an IANA Considerations Section in RFCs", BCP 26, 580 RFC 8126, DOI 10.17487/RFC8126, June 2017, 581 . 583 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 584 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 585 "Alternate-Marking Method for Passive and Hybrid 586 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 587 January 2018, . 589 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 590 Decraene, B., Litkowski, S., and R. Shakir, "Segment 591 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 592 July 2018, . 594 10.2. Informative References 596 [I-D.chen-pce-pcep-ifit] 597 Chen, H., Yuan, H., Zhou, T., Li, W., Fioccola, G., and Y. 598 Wang, "Path Computation Element Communication Protocol 599 (PCEP) Extensions to Enable IFIT", draft-chen-pce-pcep- 600 ifit-01 (work in progress), September 2020. 602 [I-D.gandhi-mpls-ioam-sr] 603 Gandhi, R., Ali, Z., Filsfils, C., Brockners, F., Wen, B., 604 and V. Kozak, "MPLS Data Plane Encapsulation for In-situ 605 OAM Data", draft-gandhi-mpls-ioam-sr-03 (work in 606 progress), September 2020. 608 [I-D.gandhi-mpls-rfc6374-sr] 609 Gandhi, R., Filsfils, C., Voyer, D., Salsano, S., and M. 610 Chen, "Performance Measurement Using RFC 6374 for Segment 611 Routing Networks with MPLS Data Plane", draft-gandhi-mpls- 612 rfc6374-sr-05 (work in progress), June 2020. 614 [I-D.ietf-mpls-rfc6374-sfl] 615 Bryant, S., Swallow, G., Chen, M., Fioccola, G., and G. 616 Mirsky, "RFC6374 Synonymous Flow Labels", draft-ietf-mpls- 617 rfc6374-sfl-07 (work in progress), June 2020. 619 Appendix A. 621 Authors' Addresses 623 Fengwei Qin 624 China Mobile 625 No. 32 Xuanwumenxi Ave., Xicheng District 626 Beijing 627 China 629 Email: qinfengwei@chinamobile.com 631 Hang Yuan 632 UnionPay 633 1899 Gu-Tang Rd., Pudong 634 Shanghai 635 China 637 Email: yuanhang@unionpay.com 639 Tianran Zhou 640 Huawei 641 156 Beiqing Rd., Haidian District 642 Beijing 643 China 645 Email: zhoutianran@huawei.com 647 Giuseppe Fioccola 648 Huawei 649 Riesstrasse, 25 650 Munich 651 Germany 653 Email: giuseppe.fioccola@huawei.com 654 Yali Wang 655 Huawei 656 156 Beiqing Rd., Haidian District 657 Beijing 658 China 660 Email: wangyali11@huawei.com