idnits 2.17.1 draft-ietf-idr-sr-policy-ifit-01.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 9, 2021) is 1164 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 (-22) exists of draft-ietf-idr-tunnel-encaps-21 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-11 == 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-05 == Outdated reference: A later version (-10) exists of draft-ietf-mpls-rfc6374-sfl-08 Summary: 2 errors (**), 0 flaws (~~), 13 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: August 13, 2021 UnionPay 6 T. Zhou 7 G. Fioccola 8 Y. Wang 9 Huawei 10 February 9, 2021 12 BGP SR Policy Extensions to Enable IFIT 13 draft-ietf-idr-sr-policy-ifit-01 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 BCP 14 [RFC2119] 32 [RFC8174] when, and only when, they appear in all capitals, as shown 33 here. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on August 13, 2021. 51 Copyright Notice 53 Copyright (c) 2021 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. IFIT methods for SR Policy . . . . . . . . . . . . . . . . . 4 71 4. IFIT Attributes in SR Policy . . . . . . . . . . . . . . . . 4 72 5. IFIT Attributes Sub-TLV . . . . . . . . . . . . . . . . . . . 6 73 5.1. IOAM Pre-allocated Trace Option Sub-TLV . . . . . . . . . 7 74 5.2. IOAM Incremental Trace Option Sub-TLV . . . . . . . . . . 8 75 5.3. IOAM Directly Export Option Sub-TLV . . . . . . . . . . . 9 76 5.4. IOAM Edge-to-Edge Option Sub-TLV . . . . . . . . . . . . 10 77 5.5. Enhanced Alternate Marking (EAM) sub-TLV . . . . . . . . 10 78 6. SR Policy Operations with IFIT Attributes . . . . . . . . . . 11 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 84 10.2. Informative References . . . . . . . . . . . . . . . . . 14 85 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 88 1. Introduction 90 Segment Routing (SR) policy [I-D.ietf-spring-segment-routing-policy] 91 is a set of candidate SR paths consisting of one or more segment 92 lists and necessary path attributes. It enables instantiation of an 93 ordered list of segments with a specific intent for traffic steering. 95 In-situ Flow Information Telemetry (IFIT) denotes a family of flow- 96 oriented on-path telemetry techniques (e.g. IOAM, Alternate 97 Marking), which can provide high-precision flow insight and real-time 98 network issue notification (e.g., jitter, latency, packet loss).In 99 particular, IFIT refers to network OAM (Operations, Administration, 100 and Maintenance) data plane on-path telemetry techniques, including 101 In-situ OAM (IOAM) [I-D.ietf-ippm-ioam-data] and Alternate Marking 102 [RFC8321]. It can provide flow information on the entire forwarding 103 path on a per-packet basis in real time. 105 An automatic network requires the Service Level Agreement (SLA) 106 monitoring on the deployed service. So that the system can quickly 107 detect the SLA violation or the performance degradation, hence to 108 change the service deployment. For this reason, the SR policy native 109 IFIT can facilitate the closed loop control and enable the automation 110 of SR service. 112 This document defines extensions to Border Gateway Protocol (BGP) to 113 distribute SR policies carrying IFIT information. So that IFIT 114 behavior can be enabled automatically when the SR policy is applied. 116 This BGP extension allows to signal the IFIT capabilities together 117 with the SR-policy. In this way IFIT methods are automatically 118 activated and running. The flexibility and dynamicity of the IFIT 119 applications are given by the use of additional functions on the 120 controller and on the network nodes, but this is out of scope here. 122 2. Motivation 124 IFIT Methods are being introduced in multiple protocols and below is 125 a proper picture of the relevant documents for Segment Routing. 126 Indeed the IFIT methods are becoming mature for Segment Routing over 127 the MPLS data plane (SR-MPLS) and Segment Routing over IPv6 data 128 plane (SRv6), that is the main focus of this draft: 130 IOAM: the reference documents for the data plane are 131 [I-D.ietf-ippm-ioam-ipv6-options] for SRv6 and 132 [I-D.gandhi-mpls-ioam-sr] for SR-MPLS. 134 Alternate Marking: the reference documents for the data plane are 135 [I-D.ietf-6man-ipv6-alt-mark] for SRv6 and 136 [I-D.ietf-mpls-rfc6374-sfl], [I-D.gandhi-mpls-rfc6374-sr] for SR- 137 MPLS. 139 The definition of these data plane IFIT methods for SR-MPLS and SRv6 140 imply requirements for various routing protocols, such as BGP, and 141 this document aims to define BGP extensions to distribute SR policies 142 carrying IFIT information. This allows to signal the IFIT 143 capabilities so IFIT methods are automatically configured and ready 144 to run when the SR Policy candidate paths are distributed through 145 BGP. 147 It is to be noted that, for PCEP (Path Computation Element 148 Communication Protocol), [I-D.chen-pce-pcep-ifit] proposes the 149 extensions to PCEP to distribute paths carrying IFIT information and 150 therefore to enable IFIT methods for SR policy too. 152 3. IFIT methods for SR Policy 154 In-situ Operations, Administration, and Maintenance (IOAM) 155 [I-D.ietf-ippm-ioam-data] records operational and telemetry 156 information in the packet while the packet traverses a path between 157 two points in the network. In terms of the classification given in 158 RFC 7799 [RFC7799] IOAM could be categorized as Hybrid Type 1. IOAM 159 mechanisms can be leveraged where active OAM do not apply or do not 160 offer the desired results. When SR policy enables the IOAM, the IOAM 161 header will be inserted into every packet of the traffic that is 162 steered into the SR paths. 164 The Alternate Marking [RFC8321]technique is an hybrid performance 165 measurement method, per RFC 7799 [RFC7799] classification of 166 measurement methods. Because this method is based on marking 167 consecutive batches of packets. It can be used to measure packet 168 loss, latency, and jitter on live traffic. 170 This document aims to define the control plane. While the relevant 171 documents for the data plane application of IOAM and Alternate 172 Marking are respectively [I-D.ietf-ippm-ioam-ipv6-options] and 173 [I-D.ietf-6man-ipv6-alt-mark] for Segment Routing over IPv6 data 174 plane (SRv6), [I-D.ietf-mpls-rfc6374-sfl], 175 [I-D.gandhi-mpls-rfc6374-sr] and [I-D.gandhi-mpls-ioam-sr] for 176 Segment Routing over the MPLS data plane (SR-MPLS). 178 4. IFIT Attributes in SR Policy 180 As defined in [I-D.ietf-idr-segment-routing-te-policy], a new SAFI is 181 defined (the SR Policy SAFI with codepoint 73) as well as a new NLRI. 182 The NLRI contains the SR Policy candidate path and, according to 183 [I-D.ietf-idr-segment-routing-te-policy], the content of the SR 184 Policy Candidate Path is encoded in the Tunnel Encapsulation 185 Attribute defined in [I-D.ietf-idr-tunnel-encaps] using a new Tunnel- 186 Type called SR Policy Type with codepoint 15. The SR Policy encoding 187 structure is as follows: 189 SR Policy SAFI NLRI: 190 Attributes: 191 Tunnel Encaps Attribute (23) 192 Tunnel Type: SR Policy 193 Binding SID 194 SRv6 Binding SID 195 Preference 196 Priority 197 Policy Name 198 Policy Candidate Path Name 199 Explicit NULL Label Policy (ENLP) 200 Segment List 201 Weight 202 Segment 203 Segment 204 ... 205 ... 207 A candidate path includes multiple SR paths, each of which is 208 specified by a segment list. IFIT can be applied to the candidate 209 path, so that all the SR paths can be monitored in the same way. The 210 new SR Policy encoding structure is expressed as below: 212 SR Policy SAFI NLRI: 213 Attributes: 214 Tunnel Encaps Attribute (23) 215 Tunnel Type: SR Policy 216 Binding SID 217 SRv6 Binding SID 218 Preference 219 Priority 220 Policy Name 221 Policy Candidate Path Name 222 Explicit NULL Label Policy (ENLP) 223 IFIT Attributes 224 Segment List 225 Weight 226 Segment 227 Segment 228 ... 229 ... 231 IFIT attributes can be attached at the candidate path level as sub- 232 TLVs. There may be different IFIT tools. The following sections 233 will describe the requirement and usage of different IFIT tools, and 234 define the corresponding sub-TLV encoding in BGP. 236 Once the IFIT attributes are signalled, if a packet arrives at the 237 headend and, based on the types of steering described in 238 [I-D.ietf-spring-segment-routing-policy], it may get steered into an 239 SR Policy where IFIT methods are applied. Therefore it will be 240 managed consequently with the corresponding IOAM or Alternate Marking 241 information according to the enabled IFIT methods. 243 Note that the IFIT attributes here described can also be generalized 244 and included as sub-TLVs for other SAFIs and NLRIs. 246 5. IFIT Attributes Sub-TLV 248 The format of the IFIT Attributes Sub-TLV is defined as follows: 250 0 1 2 3 251 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 252 +---------------+---------------+ 253 | Type | Length | 254 +-------------------------------+---------------+---------------+ 255 | | 256 // sub-TLVs // 257 | | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 Fig. 1 IFIT Attributes Sub-TLV 262 Where: 264 Type: to be assigned by IANA. 266 Length: the total length of the value field not including Type and 267 Length fields. 269 sub-TLVs currently defined: 271 * IOAM Pre-allocated Trace Option Sub-TLV, 273 * IOAM Incremental Trace Option Sub-TLV, 275 * IOAM Directly Export Option Sub-TLV, 277 * IOAM Edge-to-Edge Option Sub-TLV, 279 * Enhanced Alternate Marking (EAM) sub-TLV. 281 The presence of the IFIT Attributes Sub-TLV implies support of IFIT 282 methods (IOAM and/or Alternate Marking). It is worth mentioning that 283 IOAM and Alternate Marking can be activated one at a time or can 284 coexist; so it is possible to have only IOAM or only Alternate 285 Marking enabled as Sub-TLVs. The sub-TLVs currently defined for IOAM 286 and Alternate Marking are detailed in the next sections. 288 In case of empty IFIT Attributes Sub-TLV, i.e. no further IFIT sub- 289 TLV and Length=0, IFIT methods will not be activated. If two 290 conflicting IOAM sub-TLVs are present (e.g. Pre-allocated Trace 291 Option and Incremental Trace Option) it means that they are not 292 usable and none of the two methods will be activated. The same 293 applies if there is more than one instance of the sub-TLV of the same 294 type. Anyway the validation of the individual fields of the IFIT 295 Attributes sub-TLVs are handled by the SRPM (SR Policy Module). 297 The process of stopping IFIT methods can be done by setting empty 298 IFIT Attributes Sub-TLV, while, for modifying IFIT methods 299 parameters, the IFIT Attributes Sub-TLVs can be updated accordingly. 300 Additionally the backward compatibility is guaranteed, since an 301 implementation that does not understand IFIT Attributes Sub-TLV can 302 simply ignore it. 304 5.1. IOAM Pre-allocated Trace Option Sub-TLV 306 The IOAM tracing data is expected to be collected at every node that 307 a packet traverses to ensure visibility into the entire path a packet 308 takes within an IOAM domain. The preallocated tracing option will 309 create pre-allocated space for each node to populate its information. 311 The format of IOAM pre-allocated trace option sub-TLV is defined as 312 follows: 314 0 1 2 3 315 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 316 +---------------+---------------+-------------------------------+ 317 | Type=1 | Length=6 | Namespace ID | 318 +---------------+---------------+--------------+--------+-------+ 319 | IOAM Trace Type | Flags | Rsvd | 320 +----------------------------------------------+--------+-------+ 322 Fig. 2 IOAM Pre-allocated Trace Option Sub-TLV 324 Where: 326 Type: 1 (to be assigned by IANA). 328 Length: 6, it is the total length of the value field (not including 329 Type and Length fields). 331 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 332 definition is the same as described in section 4.4 of 333 [I-D.ietf-ippm-ioam-data]. 335 IOAM Trace Type: A 24-bit identifier which specifies which data types 336 are used in the node data list. The definition is the same as 337 described in section 4.4 of [I-D.ietf-ippm-ioam-data]. 339 Flags: A 4-bit field. The definition is the same as described in 340 [I-D.ietf-ippm-ioam-flags] and section 4.4 of 341 [I-D.ietf-ippm-ioam-data]. 343 Rsvd: A 4-bit field reserved for further usage. It MUST be zero and 344 ignored on receipt. 346 5.2. IOAM Incremental Trace Option Sub-TLV 348 The incremental tracing option contains a variable node data fields 349 where each node allocates and pushes its node data immediately 350 following the option header. 352 The format of IOAM incremental trace option sub-TLV is defined as 353 follows: 355 0 1 2 3 356 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 357 +---------------+---------------+-------------------------------+ 358 | Type=2 | Length=6 | Namespace ID | 359 +---------------+---------------+--------------+--------+-------+ 360 | IOAM Trace Type | Flags | Rsvd | 361 +----------------------------------------------+--------+-------+ 363 Fig. 3 IOAM Incremental Trace Option Sub-TLV 365 Where: 367 Type: 2 (to be assigned by IANA). 369 Length: 6, it is the total length of the value field (not including 370 Type and Length fields). 372 All the other fields definition is the same as the pre-allocated 373 trace option sub-TLV in section 4.1. 375 5.3. IOAM Directly Export Option Sub-TLV 377 IOAM directly export option is used as a trigger for IOAM data to be 378 directly exported to a collector without being pushed into in-flight 379 data packets. 381 The format of IOAM directly export option sub-TLV is defined as 382 follows: 384 0 1 2 3 385 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 386 +---------------+---------------+ 387 | Type=3 | Length=12 | 388 +-----------------------------------------------+---------------+ 389 | Namespace ID | Flags | 390 +-------------------------------+---------------+---------------+ 391 | IOAM Trace Type | Rsvd | 392 +-----------------------------------------------+---------------+ 393 | Flow ID | 394 +---------------------------------------------------------------+ 396 Fig. 4 IOAM Directly Export Option Sub-TLV 398 Where: 400 Type: 3 (to be assigned by IANA). 402 Length: 12, it is the total length of the value field (not including 403 Type and Length fields). 405 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 406 definition is the same as described in section 4.4 of 407 [I-D.ietf-ippm-ioam-data]. 409 Flags: A 16-bit field. The definition is the same as described in 410 section 3.2 of [I-D.ietf-ippm-ioam-direct-export]. 412 IOAM Trace Type: A 24-bit identifier which specifies which data types 413 are used in the node data list. The definition is the same as 414 described in section 4.4 of [I-D.ietf-ippm-ioam-data]. 416 Rsvd: A 4-bit field reserved for further usage. It MUST be zero and 417 ignored on receipt. 419 Flow ID: A 32-bit flow identifier. The definition is the same as 420 described in section 3.2 of [I-D.ietf-ippm-ioam-direct-export]. 422 5.4. IOAM Edge-to-Edge Option Sub-TLV 424 The IOAM edge to edge option is to carry data that is added by the 425 IOAM encapsulating node and interpreted by IOAM decapsulating node. 427 The format of IOAM edge-to-edge option sub-TLV is defined as follows: 429 0 1 2 3 430 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 431 +---------------+---------------+ 432 | Type=4 | Length=4 | 433 +-----------------------------------------------+---------------+ 434 | Namespace ID | IOAM E2E Type | 435 +-------------------------------+-------------------------------+ 437 Fig. 5 IOAM Edge-to-Edge Option Sub-TLV 439 Where: 441 Type: 4 (to be assigned by IANA). 443 Length: 4, it is the total length of the value field (not including 444 Type and Length fields). 446 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 447 definition is the same as described in section 4.6 of 448 [I-D.ietf-ippm-ioam-data]. 450 IOAM E2E Type: A 16-bit identifier which specifies which data types 451 are used in the E2E option data. The definition is the same as 452 described in section 4.6 of [I-D.ietf-ippm-ioam-data]. 454 5.5. Enhanced Alternate Marking (EAM) sub-TLV 456 The format of Enhanced Alternate Marking (EAM) sub-TLV is defined as 457 follows: 459 0 1 2 3 460 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 461 +---------------+---------------+ 462 | Type=5 | Length=4 | 463 +-------------------------------+-------+-------+-------+-------+ 464 | FlowMonID | Period |H|E| R | 465 +---------------------------------------+---------------+-------+ 467 Fig. 6 Enhanced Alternate Marking Sub-TLV 469 Where: 471 Type: 5 (to be assigned by IANA). 473 Length: 4, it is the total length of the value field (not including 474 Type and Length fields). 476 FlowMonID: A 20-bit identifier to uniquely identify a monitored flow 477 within the measurement domain. The definition is the same as 478 described in section 5.3 of [I-D.ietf-6man-ipv6-alt-mark]. 480 Period: Time interval between two alternate marking period. The unit 481 is second. 483 H: A flag indicating that the measurement is Hop-By-Hop. 485 E: A flag indicating that the measurement is end to end. 487 R: A 2-bit field reserved for further usage. It MUST be zero and 488 ignored on receipt. 490 6. SR Policy Operations with IFIT Attributes 492 The details of SR Policy installation and use are specified in 493 [I-D.ietf-spring-segment-routing-policy]. This document complements 494 SR Policy Operations described in 495 [I-D.ietf-idr-segment-routing-te-policy] by adding the IFIT 496 Attributes. 498 The operations described in [I-D.ietf-idr-segment-routing-te-policy] 499 are always valid. The only difference is the addition of IFIT 500 Attributes Sub-TLVs for the SR Policy NLRI, that can affect its 501 acceptance by a BGP speaker, but the implementation MAY provide an 502 option for ignoring the unrecognized or unsupported IFIT sub-TLVs. 503 SR Policy NLRIs that have been determined acceptable, usable and 504 valid can be evaluated for propagation, including the IFIT 505 information. 507 The error handling actions are also described in 508 [I-D.ietf-idr-segment-routing-te-policy],indeed A BGP Speaker MUST 509 perform the syntactic validation of the SR Policy NLRI to determine 510 if it is malformed, including the TLVs/sub-TLVs. In case of any 511 error detected, either at the attribute or its TLV/sub-TLV level, the 512 "treat-as-withdraw" strategy MUST be applied. 514 The validation of the IFIT Attributes sub-TLVs introduced in this 515 document MUST be performed to determine if they are malformed or 516 invalid. The validation of the individual fields of the IFIT 517 Attributes sub-TLVs are handled by the SRPM (SR Policy Module). 519 7. IANA Considerations 521 This document defines a new sub-TLV in the registry "BGP Tunnel 522 Encapsulation Attribute sub-TLVs" to be assigned by IANA: 524 Codepoint Description Reference 525 ------------------------------------------------------------- 526 TBD1 IFIT Attributes Sub-TLV This document 528 This document requests creation of a new registry called "IFIT 529 Attributes Sub-TLVs". The allocation policy of this registry is 530 "Specification Required" according to RFC 8126 [RFC8126]. 532 The following initial Sub-TLV codepoints are assigned by this 533 document: 535 Value Description Reference 536 ------------------------------------------------------------- 537 1 IOAM Pre-allocated Trace Option Sub-TLV This document 539 2 IOAM Incremental Trace Option Sub-TLV This document 541 3 IOAM Directly Export Option Sub-TLV This document 543 4 IOAM Edge-to-Edge Option Sub-TLV This document 545 5 Enhanced Alternate Marking Sub-TLV This document 547 8. Security Considerations 549 The security mechanisms of the base BGP security model apply to the 550 extensions described in this document as well. See the Security 551 Considerations section of [I-D.ietf-idr-segment-routing-te-policy]. 553 SR operates within a trusted SR domain RFC 8402 [RFC8402] and its 554 security considerations also apply to BGP sessions when carrying SR 555 Policy information. The isolation of BGP SR Policy SAFI peering 556 sessions may be used to ensure that the SR Policy information is not 557 advertised outside the SR domain. Additionally, only trusted nodes 558 (that include both routers and controller applications) within the SR 559 domain must be configured to receive such information. 561 Implementation of IFIT methods (IOAM and Alternate Marking) are 562 mindful of security and privacy concerns, as explained in 563 [I-D.ietf-ippm-ioam-data] and RFC 8321 [RFC8321]. Anyway incorrect 564 IFIT parameters in the BGP extension SHOULD NOT have an adverse 565 effect on the SR Policy as well as on the network, since it affects 566 only the operation of the telemetry methodology. 568 9. Acknowledgements 570 The authors of this document would like to thank Ketan Talaulikar, 571 Joel Halpern, Jie Dong for their comments and review of this 572 document. 574 10. References 576 10.1. Normative References 578 [I-D.ietf-6man-ipv6-alt-mark] 579 Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. 580 Pang, "IPv6 Application of the Alternate Marking Method", 581 draft-ietf-6man-ipv6-alt-mark-02 (work in progress), 582 October 2020. 584 [I-D.ietf-idr-segment-routing-te-policy] 585 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 586 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 587 Routing Policies in BGP", draft-ietf-idr-segment-routing- 588 te-policy-11 (work in progress), November 2020. 590 [I-D.ietf-idr-tunnel-encaps] 591 Patel, K., Velde, G., Sangli, S., and J. Scudder, "The BGP 592 Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel- 593 encaps-21 (work in progress), January 2021. 595 [I-D.ietf-ippm-ioam-data] 596 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 597 for In-situ OAM", draft-ietf-ippm-ioam-data-11 (work in 598 progress), November 2020. 600 [I-D.ietf-ippm-ioam-direct-export] 601 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 602 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 603 OAM Direct Exporting", draft-ietf-ippm-ioam-direct- 604 export-02 (work in progress), November 2020. 606 [I-D.ietf-ippm-ioam-flags] 607 Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R., 608 Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., and J. 609 Lemon, "In-situ OAM Flags", draft-ietf-ippm-ioam-flags-03 610 (work in progress), October 2020. 612 [I-D.ietf-ippm-ioam-ipv6-options] 613 Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., 614 Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., 615 Lapukhov, P., Spiegel, M., Krishnan, S., Asati, R., and M. 616 Smith, "In-situ OAM IPv6 Options", draft-ietf-ippm-ioam- 617 ipv6-options-04 (work in progress), November 2020. 619 [I-D.ietf-spring-segment-routing-policy] 620 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 621 P. Mattes, "Segment Routing Policy Architecture", draft- 622 ietf-spring-segment-routing-policy-09 (work in progress), 623 November 2020. 625 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 626 Requirement Levels", BCP 14, RFC 2119, 627 DOI 10.17487/RFC2119, March 1997, 628 . 630 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 631 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 632 May 2016, . 634 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 635 Writing an IANA Considerations Section in RFCs", BCP 26, 636 RFC 8126, DOI 10.17487/RFC8126, June 2017, 637 . 639 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 640 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 641 May 2017, . 643 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 644 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 645 "Alternate-Marking Method for Passive and Hybrid 646 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 647 January 2018, . 649 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 650 Decraene, B., Litkowski, S., and R. Shakir, "Segment 651 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 652 July 2018, . 654 10.2. Informative References 656 [I-D.chen-pce-pcep-ifit] 657 Chen, H., Yuan, H., Zhou, T., Li, W., Fioccola, G., and Y. 658 Wang, "Path Computation Element Communication Protocol 659 (PCEP) Extensions to Enable IFIT", draft-chen-pce-pcep- 660 ifit-01 (work in progress), September 2020. 662 [I-D.gandhi-mpls-ioam-sr] 663 Gandhi, R., Ali, Z., Filsfils, C., Brockners, F., Wen, B., 664 and V. Kozak, "MPLS Data Plane Encapsulation for In-situ 665 OAM Data", draft-gandhi-mpls-ioam-sr-05 (work in 666 progress), January 2021. 668 [I-D.gandhi-mpls-rfc6374-sr] 669 Gandhi, R., Filsfils, C., Voyer, D., Salsano, S., and M. 670 Chen, "Performance Measurement Using RFC 6374 for Segment 671 Routing Networks with MPLS Data Plane", draft-gandhi-mpls- 672 rfc6374-sr-05 (work in progress), June 2020. 674 [I-D.ietf-mpls-rfc6374-sfl] 675 Bryant, S., Swallow, G., Chen, M., Fioccola, G., and G. 676 Mirsky, "RFC6374 Synonymous Flow Labels", draft-ietf-mpls- 677 rfc6374-sfl-08 (work in progress), December 2020. 679 Appendix A. 681 Authors' Addresses 683 Fengwei Qin 684 China Mobile 685 No. 32 Xuanwumenxi Ave., Xicheng District 686 Beijing 687 China 689 Email: qinfengwei@chinamobile.com 691 Hang Yuan 692 UnionPay 693 1899 Gu-Tang Rd., Pudong 694 Shanghai 695 China 697 Email: yuanhang@unionpay.com 698 Tianran Zhou 699 Huawei 700 156 Beiqing Rd., Haidian District 701 Beijing 702 China 704 Email: zhoutianran@huawei.com 706 Giuseppe Fioccola 707 Huawei 708 Riesstrasse, 25 709 Munich 710 Germany 712 Email: giuseppe.fioccola@huawei.com 714 Yali Wang 715 Huawei 716 156 Beiqing Rd., Haidian District 717 Beijing 718 China 720 Email: wangyali11@huawei.com