idnits 2.17.1 draft-ietf-idr-sr-policy-ifit-02.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 (July 9, 2021) is 993 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-04 == 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-12 == Outdated reference: A later version (-11) exists of draft-ietf-ippm-ioam-direct-export-03 == Outdated reference: A later version (-10) exists of draft-ietf-ippm-ioam-flags-04 == Outdated reference: A later version (-12) exists of draft-ietf-ippm-ioam-ipv6-options-05 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-11 ** Downref: Normative reference to an Informational RFC: RFC 7799 ** Obsolete normative reference: RFC 8321 (Obsoleted by RFC 9341) ** Downref: Normative reference to an Informational RFC: RFC 8799 == Outdated reference: A later version (-06) exists of draft-chen-pce-pcep-ifit-02 Summary: 3 errors (**), 0 flaws (~~), 10 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: January 10, 2022 UnionPay 6 T. Zhou 7 G. Fioccola 8 Y. Wang 9 Huawei 10 July 9, 2021 12 BGP SR Policy Extensions to Enable IFIT 13 draft-ietf-idr-sr-policy-ifit-02 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 January 10, 2022. 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 . . . . . . . . . . . . . . . . 5 72 5. IFIT Attributes Sub-TLV . . . . . . . . . . . . . . . . . . . 6 73 5.1. IOAM Pre-allocated Trace Option Sub-TLV . . . . . . . . . 8 74 5.2. IOAM Incremental Trace Option Sub-TLV . . . . . . . . . . 9 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 . . . . . . . . 11 78 6. SR Policy Operations with IFIT Attributes . . . . . . . . . . 12 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 84 10.2. Informative References . . . . . . . . . . . . . . . . . 16 85 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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 IFIT is a solution focusing on network domains according to [RFC8799] 123 that introduces the concept of specific domain solutions. A network 124 domain consists of a set of network devices or entities within a 125 single administration. As mentioned in [RFC8799], for a number of 126 reasons, such as policies, options supported, style of network 127 management and security requirements, it is suggested to limit 128 applications including the emerging IFIT techniques to a controlled 129 domain. Hence, the IFIT methods MUST be typically deployed in such 130 controlled domains. 132 2. Motivation 134 IFIT Methods are being introduced in multiple protocols and below is 135 a proper picture of the relevant documents for Segment Routing. 136 Indeed the IFIT methods are becoming mature for Segment Routing over 137 the MPLS data plane (SR-MPLS) and Segment Routing over IPv6 data 138 plane (SRv6), that is the main focus of this draft: 140 IOAM: the reference documents for the data plane are 141 [I-D.ietf-ippm-ioam-ipv6-options] for SRv6 and 142 [I-D.gandhi-mpls-ioam-sr] for SR-MPLS. 144 Alternate Marking: the reference documents for the data plane are 145 [I-D.ietf-6man-ipv6-alt-mark] for SRv6 and 146 [I-D.ietf-mpls-rfc6374-sfl], [I-D.gandhi-mpls-rfc6374-sr] for SR- 147 MPLS. 149 The definition of these data plane IFIT methods for SR-MPLS and SRv6 150 imply requirements for various routing protocols, such as BGP, and 151 this document aims to define BGP extensions to distribute SR policies 152 carrying IFIT information. This allows to signal the IFIT 153 capabilities so IFIT methods are automatically configured and ready 154 to run when the SR Policy candidate paths are distributed through 155 BGP. 157 It is to be noted that, for PCEP (Path Computation Element 158 Communication Protocol), [I-D.chen-pce-pcep-ifit] proposes the 159 extensions to PCEP to distribute paths carrying IFIT information and 160 therefore to enable IFIT methods for SR policy too. 162 3. IFIT methods for SR Policy 164 In-situ Operations, Administration, and Maintenance (IOAM) 165 [I-D.ietf-ippm-ioam-data] records operational and telemetry 166 information in the packet while the packet traverses a path between 167 two points in the network. In terms of the classification given in 168 RFC 7799 [RFC7799] IOAM could be categorized as Hybrid Type 1. IOAM 169 mechanisms can be leveraged where active OAM do not apply or do not 170 offer the desired results. When SR policy enables the IOAM, the IOAM 171 header will be inserted into every packet of the traffic that is 172 steered into the SR paths. 174 The Alternate Marking [RFC8321]technique is an hybrid performance 175 measurement method, per RFC 7799 [RFC7799] classification of 176 measurement methods. Because this method is based on marking 177 consecutive batches of packets. It can be used to measure packet 178 loss, latency, and jitter on live traffic. 180 This document aims to define the control plane. While the relevant 181 documents for the data plane application of IOAM and Alternate 182 Marking are respectively [I-D.ietf-ippm-ioam-ipv6-options] and 183 [I-D.ietf-6man-ipv6-alt-mark] for Segment Routing over IPv6 data 184 plane (SRv6), [I-D.ietf-mpls-rfc6374-sfl], 185 [I-D.gandhi-mpls-rfc6374-sr] and [I-D.gandhi-mpls-ioam-sr] for 186 Segment Routing over the MPLS data plane (SR-MPLS). 188 4. IFIT Attributes in SR Policy 190 As defined in [I-D.ietf-idr-segment-routing-te-policy], a new SAFI is 191 defined (the SR Policy SAFI with codepoint 73) as well as a new NLRI. 192 The NLRI contains the SR Policy candidate path and, according to 193 [I-D.ietf-idr-segment-routing-te-policy], the content of the SR 194 Policy Candidate Path is encoded in the Tunnel Encapsulation 195 Attribute defined in [I-D.ietf-idr-tunnel-encaps] using a new Tunnel- 196 Type called SR Policy Type with codepoint 15. The SR Policy encoding 197 structure is as follows: 199 SR Policy SAFI NLRI: 200 Attributes: 201 Tunnel Encaps Attribute (23) 202 Tunnel Type: SR Policy 203 Binding SID 204 SRv6 Binding SID 205 Preference 206 Priority 207 Policy Name 208 Policy Candidate Path Name 209 Explicit NULL Label Policy (ENLP) 210 Segment List 211 Weight 212 Segment 213 Segment 214 ... 215 ... 217 A candidate path includes multiple SR paths, each of which is 218 specified by a segment list. IFIT can be applied to the candidate 219 path, so that all the SR paths can be monitored in the same way. The 220 new SR Policy encoding structure is expressed as below: 222 SR Policy SAFI NLRI: 223 Attributes: 224 Tunnel Encaps Attribute (23) 225 Tunnel Type: SR Policy 226 Binding SID 227 SRv6 Binding SID 228 Preference 229 Priority 230 Policy Name 231 Policy Candidate Path Name 232 Explicit NULL Label Policy (ENLP) 233 IFIT Attributes 234 Segment List 235 Weight 236 Segment 237 Segment 238 ... 239 ... 241 IFIT attributes can be attached at the candidate path level as sub- 242 TLVs. There may be different IFIT tools. The following sections 243 will describe the requirement and usage of different IFIT tools, and 244 define the corresponding sub-TLV encoding in BGP. 246 Once the IFIT attributes are signalled, if a packet arrives at the 247 headend and, based on the types of steering described in 248 [I-D.ietf-spring-segment-routing-policy], it may get steered into an 249 SR Policy where IFIT methods are applied. Therefore it will be 250 managed consequently with the corresponding IOAM or Alternate Marking 251 information according to the enabled IFIT methods. 253 Note that the IFIT attributes here described can also be generalized 254 and included as sub-TLVs for other SAFIs and NLRIs. 256 5. IFIT Attributes Sub-TLV 258 The format of the IFIT Attributes Sub-TLV is defined as follows: 260 0 1 2 3 261 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 262 +---------------+---------------+ 263 | Type | Length | 264 +-------------------------------+---------------+---------------+ 265 | | 266 // sub-TLVs // 267 | | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Fig. 1 IFIT Attributes Sub-TLV 272 Where: 274 Type: to be assigned by IANA. 276 Length: the total length of the value field not including Type and 277 Length fields. 279 sub-TLVs currently defined: 281 * IOAM Pre-allocated Trace Option Sub-TLV, 283 * IOAM Incremental Trace Option Sub-TLV, 285 * IOAM Directly Export Option Sub-TLV, 287 * IOAM Edge-to-Edge Option Sub-TLV, 289 * Enhanced Alternate Marking (EAM) sub-TLV. 291 The presence of the IFIT Attributes Sub-TLV implies support of IFIT 292 methods (IOAM and/or Alternate Marking). It is worth mentioning that 293 IOAM and Alternate Marking can be activated one at a time or can 294 coexist; so it is possible to have only IOAM or only Alternate 295 Marking enabled as Sub-TLVs. The sub-TLVs currently defined for IOAM 296 and Alternate Marking are detailed in the next sections. 298 In case of empty IFIT Attributes Sub-TLV, i.e. no further IFIT sub- 299 TLV and Length=0, IFIT methods will not be activated. If two 300 conflicting IOAM sub-TLVs are present (e.g. Pre-allocated Trace 301 Option and Incremental Trace Option) it means that they are not 302 usable and none of the two methods will be activated. The same 303 applies if there is more than one instance of the sub-TLV of the same 304 type. Anyway the validation of the individual fields of the IFIT 305 Attributes sub-TLVs are handled by the SRPM (SR Policy Module). 307 The process of stopping IFIT methods can be done by setting empty 308 IFIT Attributes Sub-TLV, while, for modifying IFIT methods 309 parameters, the IFIT Attributes Sub-TLVs can be updated accordingly. 310 Additionally the backward compatibility is guaranteed, since an 311 implementation that does not understand IFIT Attributes Sub-TLV can 312 simply ignore it. 314 5.1. IOAM Pre-allocated Trace Option Sub-TLV 316 The IOAM tracing data is expected to be collected at every node that 317 a packet traverses to ensure visibility into the entire path a packet 318 takes within an IOAM domain. The preallocated tracing option will 319 create pre-allocated space for each node to populate its information. 321 The format of IOAM pre-allocated trace option sub-TLV is defined as 322 follows: 324 0 1 2 3 325 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 326 +---------------+---------------+-------------------------------+ 327 | Type=1 | Length=6 | Namespace ID | 328 +---------------+---------------+--------------+--------+-------+ 329 | IOAM Trace Type | Flags | Rsvd | 330 +----------------------------------------------+--------+-------+ 332 Fig. 2 IOAM Pre-allocated Trace Option Sub-TLV 334 Where: 336 Type: 1 (to be assigned by IANA). 338 Length: 6, it is the total length of the value field (not including 339 Type and Length fields). 341 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 342 definition is the same as described in section 4.4 of 343 [I-D.ietf-ippm-ioam-data]. 345 IOAM Trace Type: A 24-bit identifier which specifies which data types 346 are used in the node data list. The definition is the same as 347 described in section 4.4 of [I-D.ietf-ippm-ioam-data]. 349 Flags: A 4-bit field. The definition is the same as described in 350 [I-D.ietf-ippm-ioam-flags] and section 4.4 of 351 [I-D.ietf-ippm-ioam-data]. 353 Rsvd: A 4-bit field reserved for further usage. It MUST be zero and 354 ignored on receipt. 356 5.2. IOAM Incremental Trace Option Sub-TLV 358 The incremental tracing option contains a variable node data fields 359 where each node allocates and pushes its node data immediately 360 following the option header. 362 The format of IOAM incremental trace option sub-TLV is defined as 363 follows: 365 0 1 2 3 366 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 367 +---------------+---------------+-------------------------------+ 368 | Type=2 | Length=6 | Namespace ID | 369 +---------------+---------------+--------------+--------+-------+ 370 | IOAM Trace Type | Flags | Rsvd | 371 +----------------------------------------------+--------+-------+ 373 Fig. 3 IOAM Incremental Trace Option Sub-TLV 375 Where: 377 Type: 2 (to be assigned by IANA). 379 Length: 6, it is the total length of the value field (not including 380 Type and Length fields). 382 All the other fields definition is the same as the pre-allocated 383 trace option sub-TLV in section 4.1. 385 5.3. IOAM Directly Export Option Sub-TLV 387 IOAM directly export option is used as a trigger for IOAM data to be 388 directly exported to a collector without being pushed into in-flight 389 data packets. 391 The format of IOAM directly export option sub-TLV is defined as 392 follows: 394 0 1 2 3 395 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 396 +---------------+---------------+ 397 | Type=3 | Length=12 | 398 +-----------------------------------------------+---------------+ 399 | Namespace ID | Flags | 400 +-------------------------------+---------------+---------------+ 401 | IOAM Trace Type | Rsvd | 402 +-----------------------------------------------+---------------+ 403 | Flow ID | 404 +---------------------------------------------------------------+ 406 Fig. 4 IOAM Directly Export Option Sub-TLV 408 Where: 410 Type: 3 (to be assigned by IANA). 412 Length: 12, it is the total length of the value field (not including 413 Type and Length fields). 415 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 416 definition is the same as described in section 4.4 of 417 [I-D.ietf-ippm-ioam-data]. 419 Flags: A 16-bit field. The definition is the same as described in 420 section 3.2 of [I-D.ietf-ippm-ioam-direct-export]. 422 IOAM Trace Type: A 24-bit identifier which specifies which data types 423 are used in the node data list. The definition is the same as 424 described in section 4.4 of [I-D.ietf-ippm-ioam-data]. 426 Rsvd: A 4-bit field reserved for further usage. It MUST be zero and 427 ignored on receipt. 429 Flow ID: A 32-bit flow identifier. The definition is the same as 430 described in section 3.2 of [I-D.ietf-ippm-ioam-direct-export]. 432 5.4. IOAM Edge-to-Edge Option Sub-TLV 434 The IOAM edge to edge option is to carry data that is added by the 435 IOAM encapsulating node and interpreted by IOAM decapsulating node. 437 The format of IOAM edge-to-edge option sub-TLV is defined as follows: 439 0 1 2 3 440 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 441 +---------------+---------------+ 442 | Type=4 | Length=4 | 443 +-----------------------------------------------+---------------+ 444 | Namespace ID | IOAM E2E Type | 445 +-------------------------------+-------------------------------+ 447 Fig. 5 IOAM Edge-to-Edge Option Sub-TLV 449 Where: 451 Type: 4 (to be assigned by IANA). 453 Length: 4, it is the total length of the value field (not including 454 Type and Length fields). 456 Namespace ID: A 16-bit identifier of an IOAM-Namespace. The 457 definition is the same as described in section 4.6 of 458 [I-D.ietf-ippm-ioam-data]. 460 IOAM E2E Type: A 16-bit identifier which specifies which data types 461 are used in the E2E option data. The definition is the same as 462 described in section 4.6 of [I-D.ietf-ippm-ioam-data]. 464 5.5. Enhanced Alternate Marking (EAM) sub-TLV 466 The format of Enhanced Alternate Marking (EAM) sub-TLV is defined as 467 follows: 469 0 1 2 3 470 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 471 +---------------+---------------+ 472 | Type=5 | Length=4 | 473 +-------------------------------+-------+-------+-------+-------+ 474 | FlowMonID | Period |H|E| R | 475 +---------------------------------------+---------------+-------+ 477 Fig. 6 Enhanced Alternate Marking Sub-TLV 479 Where: 481 Type: 5 (to be assigned by IANA). 483 Length: 4, it is the total length of the value field (not including 484 Type and Length fields). 486 FlowMonID: A 20-bit identifier to uniquely identify a monitored flow 487 within the measurement domain. The definition is the same as 488 described in section 5.3 of [I-D.ietf-6man-ipv6-alt-mark]. 490 Period: Time interval between two alternate marking period. The unit 491 is second. 493 H: A flag indicating that the measurement is Hop-By-Hop. 495 E: A flag indicating that the measurement is end to end. 497 R: A 2-bit field reserved for further usage. It MUST be zero and 498 ignored on receipt. 500 6. SR Policy Operations with IFIT Attributes 502 The details of SR Policy installation and use are specified in 503 [I-D.ietf-spring-segment-routing-policy]. This document complements 504 SR Policy Operations described in 505 [I-D.ietf-idr-segment-routing-te-policy] by adding the IFIT 506 Attributes. 508 The operations described in [I-D.ietf-idr-segment-routing-te-policy] 509 are always valid. The only difference is the addition of IFIT 510 Attributes Sub-TLVs for the SR Policy NLRI, that can affect its 511 acceptance by a BGP speaker, but the implementation MAY provide an 512 option for ignoring the unrecognized or unsupported IFIT sub-TLVs. 513 SR Policy NLRIs that have been determined acceptable, usable and 514 valid can be evaluated for propagation, including the IFIT 515 information. 517 The error handling actions are also described in 518 [I-D.ietf-idr-segment-routing-te-policy],indeed A BGP Speaker MUST 519 perform the syntactic validation of the SR Policy NLRI to determine 520 if it is malformed, including the TLVs/sub-TLVs. In case of any 521 error detected, either at the attribute or its TLV/sub-TLV level, the 522 "treat-as-withdraw" strategy MUST be applied. 524 The validation of the IFIT Attributes sub-TLVs introduced in this 525 document MUST be performed to determine if they are malformed or 526 invalid. The validation of the individual fields of the IFIT 527 Attributes sub-TLVs are handled by the SRPM (SR Policy Module). 529 7. IANA Considerations 531 This document defines a new sub-TLV in the registry "BGP Tunnel 532 Encapsulation Attribute sub-TLVs" to be assigned by IANA: 534 Codepoint Description Reference 535 ------------------------------------------------------------- 536 TBD1 IFIT Attributes Sub-TLV This document 538 This document requests creation of a new registry called "IFIT 539 Attributes Sub-TLVs". The allocation policy of this registry is 540 "Specification Required" according to RFC 8126 [RFC8126]. 542 The following initial Sub-TLV codepoints are assigned by this 543 document: 545 Value Description Reference 546 ------------------------------------------------------------- 547 1 IOAM Pre-allocated Trace Option Sub-TLV This document 549 2 IOAM Incremental Trace Option Sub-TLV This document 551 3 IOAM Directly Export Option Sub-TLV This document 553 4 IOAM Edge-to-Edge Option Sub-TLV This document 555 5 Enhanced Alternate Marking Sub-TLV This document 557 8. Security Considerations 559 The security mechanisms of the base BGP security model apply to the 560 extensions described in this document as well. See the Security 561 Considerations section of [I-D.ietf-idr-segment-routing-te-policy]. 563 SR operates within a trusted SR domain RFC 8402 [RFC8402] and its 564 security considerations also apply to BGP sessions when carrying SR 565 Policy information. The isolation of BGP SR Policy SAFI peering 566 sessions may be used to ensure that the SR Policy information is not 567 advertised outside the SR domain. Additionally, only trusted nodes 568 (that include both routers and controller applications) within the SR 569 domain must be configured to receive such information. 571 Implementation of IFIT methods (IOAM and Alternate Marking) are 572 mindful of security and privacy concerns, as explained in 573 [I-D.ietf-ippm-ioam-data] and RFC 8321 [RFC8321]. Anyway incorrect 574 IFIT parameters in the BGP extension SHOULD NOT have an adverse 575 effect on the SR Policy as well as on the network, since it affects 576 only the operation of the telemetry methodology. 578 IFIT data MUST be propagated in a limited domain in order to avoid 579 malicious attacks and solutions to ensure this requirement are 580 respectively discussed in [I-D.ietf-ippm-ioam-data] and 581 [I-D.ietf-6man-ipv6-alt-mark]. 583 IFIT methods (IOAM and Alternate Marking) are applied within a 584 controlled domain where the network nodes are locally administered. 585 A limited administrative domain provides the network administrator 586 with the means to select, monitor and control the access to the 587 network, making it a trusted domain also for the BGP extensions 588 defined in this document. 590 9. Acknowledgements 592 The authors of this document would like to thank Ketan Talaulikar, 593 Joel Halpern, Jie Dong for their comments and review of this 594 document. 596 10. References 598 10.1. Normative References 600 [I-D.ietf-6man-ipv6-alt-mark] 601 Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. 602 Pang, "IPv6 Application of the Alternate Marking Method", 603 draft-ietf-6man-ipv6-alt-mark-04 (work in progress), March 604 2021. 606 [I-D.ietf-idr-segment-routing-te-policy] 607 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 608 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 609 Routing Policies in BGP", draft-ietf-idr-segment-routing- 610 te-policy-11 (work in progress), November 2020. 612 [I-D.ietf-idr-tunnel-encaps] 613 Patel, K., Velde, G. V. D., Sangli, S. R., and J. Scudder, 614 "The BGP Tunnel Encapsulation Attribute", draft-ietf-idr- 615 tunnel-encaps-22 (work in progress), January 2021. 617 [I-D.ietf-ippm-ioam-data] 618 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 619 for In-situ OAM", draft-ietf-ippm-ioam-data-12 (work in 620 progress), February 2021. 622 [I-D.ietf-ippm-ioam-direct-export] 623 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 624 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 625 OAM Direct Exporting", draft-ietf-ippm-ioam-direct- 626 export-03 (work in progress), February 2021. 628 [I-D.ietf-ippm-ioam-flags] 629 Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R., 630 Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., and J. 631 Lemon, "In-situ OAM Flags", draft-ietf-ippm-ioam-flags-04 632 (work in progress), February 2021. 634 [I-D.ietf-ippm-ioam-ipv6-options] 635 Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., 636 Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., 637 Lapukhov, P., Spiegel, M., Krishnan, S., Asati, R., and M. 638 Smith, "In-situ OAM IPv6 Options", draft-ietf-ippm-ioam- 639 ipv6-options-05 (work in progress), February 2021. 641 [I-D.ietf-spring-segment-routing-policy] 642 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 643 P. Mattes, "Segment Routing Policy Architecture", draft- 644 ietf-spring-segment-routing-policy-11 (work in progress), 645 April 2021. 647 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 648 Requirement Levels", BCP 14, RFC 2119, 649 DOI 10.17487/RFC2119, March 1997, 650 . 652 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 653 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 654 May 2016, . 656 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 657 Writing an IANA Considerations Section in RFCs", BCP 26, 658 RFC 8126, DOI 10.17487/RFC8126, June 2017, 659 . 661 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 662 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 663 May 2017, . 665 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 666 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 667 "Alternate-Marking Method for Passive and Hybrid 668 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 669 January 2018, . 671 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 672 Decraene, B., Litkowski, S., and R. Shakir, "Segment 673 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 674 July 2018, . 676 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 677 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 678 . 680 10.2. Informative References 682 [I-D.chen-pce-pcep-ifit] 683 Chen, H., Yuan, H., Zhou, T., Li, W., Fioccola, G., and Y. 684 Wang, "Path Computation Element Communication Protocol 685 (PCEP) Extensions to Enable IFIT", draft-chen-pce-pcep- 686 ifit-02 (work in progress), February 2021. 688 [I-D.gandhi-mpls-ioam-sr] 689 Gandhi, R., Ali, Z., Filsfils, C., Brockners, F., Wen, B., 690 and V. Kozak, "MPLS Data Plane Encapsulation for In-situ 691 OAM Data", draft-gandhi-mpls-ioam-sr-06 (work in 692 progress), February 2021. 694 [I-D.gandhi-mpls-rfc6374-sr] 695 Gandhi, R., Filsfils, C., Voyer, D., Salsano, S., and M. 696 Chen, "Performance Measurement Using RFC 6374 for Segment 697 Routing Networks with MPLS Data Plane", draft-gandhi-mpls- 698 rfc6374-sr-05 (work in progress), June 2020. 700 [I-D.ietf-mpls-rfc6374-sfl] 701 Bryant, S., Swallow, G., Chen, M., Fioccola, G., and G. 702 Mirsky, "RFC6374 Synonymous Flow Labels", draft-ietf-mpls- 703 rfc6374-sfl-10 (work in progress), March 2021. 705 Appendix A. 707 Authors' Addresses 709 Fengwei Qin 710 China Mobile 711 No. 32 Xuanwumenxi Ave., Xicheng District 712 Beijing 713 China 715 Email: qinfengwei@chinamobile.com 716 Hang Yuan 717 UnionPay 718 1899 Gu-Tang Rd., Pudong 719 Shanghai 720 China 722 Email: yuanhang@unionpay.com 724 Tianran Zhou 725 Huawei 726 156 Beiqing Rd., Haidian District 727 Beijing 728 China 730 Email: zhoutianran@huawei.com 732 Giuseppe Fioccola 733 Huawei 734 Riesstrasse, 25 735 Munich 736 Germany 738 Email: giuseppe.fioccola@huawei.com 740 Yali Wang 741 Huawei 742 156 Beiqing Rd., Haidian District 743 Beijing 744 China 746 Email: wangyali11@huawei.com