idnits 2.17.00 (12 Aug 2021) /tmp/idnits32676/draft-li-spring-srh-tlv-processing-programming-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 date (29 November 2021) is 166 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) -- Looks like a reference, but probably isn't: '0' on line 274 -- Looks like a reference, but probably isn't: '1' on line 278 == Unused Reference: 'RFC8200' is defined on line 358, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group C. Li 3 Internet-Draft Y. Xia 4 Intended status: Standards Track D. Dhody 5 Expires: 2 June 2022 Z. Li 6 Huawei Technologies 7 29 November 2021 9 SRH TLV Processing Programming 10 draft-li-spring-srh-tlv-processing-programming-02 12 Abstract 14 This document proposes a mechanism to program the processing rules of 15 Segment Routig Header (SRH) optional TLVs explicitly on the ingress 16 node. In this mechanism, there is no need to configure local 17 configuration at the node to support SRH TLV processing. A network 18 operator can program to process specific TLVs on specific segment 19 endpoint nodes for specific packets on the ingress node, which is 20 more efficient for SRH TLV processing. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 2 June 2022. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Revised BSD License text as 50 described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Revised BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 3. SRH TLV Processing Programming . . . . . . . . . . . . . . . 4 59 3.1. TLV Processing Indicator Flavor . . . . . . . . . . . . . 4 60 3.2. TLV Processing Indicator TLV . . . . . . . . . . . . . . 4 61 4. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 6 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 65 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 68 9.2. Informative References . . . . . . . . . . . . . . . . . 9 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 Segment routing (SR) [RFC8402] is a source routing paradigm that 74 explicitly indicates the forwarding path for packets at the ingress 75 node by inserting an ordered list of instructions, called segments. 77 When segment routing is deployed on the IPv6 data plane, it is called 78 SRv6 [RFC8754]. For support of SR, a new routing header called 79 Segment Routing Header (SRH), containing a list of segments, optional 80 TLVs and other information, has been defined in [RFC8754]. 82 Currently, when TLVs are carried in an SRH, they are ignored by the 83 nodes by default, unless there are some local policies on nodes to 84 enable the SRH TLV processing [RFC8754]. 86 When a node is configured to process a TLV, it needs to examine all 87 the SRH TLVs for processing a single TLV (TLVs except HMAC in SRH MAY 88 appear in any order), which is inefficient. 90 Furthermore, in order to deploy a new service, network operators need 91 to configure multiple nodes along the path to support SRH TLVs 92 processing, which is complicated. Also, it is not easy to 93 dynamically adjustment the local policy for meeting dynamic service 94 requirements. However, SRv6 does not have the compability to program 95 the rules of SRH TLVs processing on the ingress node currently. 97 In summary, network operator are not able to program the SRH TLV 98 processing rules on the ingress node to process specific TLVs on 99 specific segment endpoint nodes for some packets dynamically. 101 This document proposes a mechanism to program the SRH TLVs processing 102 rules explicitly and dynamically on the ingress node. In this 103 mechanism, there is no need to configure nodal local policy to 104 support SRH TLV processing. It can be used for the following use 105 cases: 107 * Service Function Chaining (SFC): In SFC, SRH TLVs like Firewall 108 related TLVs [I-D.guichard-spring-srv6-simplified-firewall] may 109 only be processed on some specific nodes instead of all the nodes 110 along the path. 112 * Smart In-situ OAM (IOAM): In IOAM, the IOAM metadata will be 113 collected by all the nodes along the path. However, in the most 114 cases, only the metadatda on some nodes are important for OAM, 115 while the others are redundant or irrelevant. For example, 116 congestion may occur only on some nodes, not all nodes. In 117 addition, congestion may occur on link A at the last moment and 118 may occur on link B at the next moment. To implement smarter and 119 more efficient IOAM, the scope of IOAM metadata collection needs 120 to be dynamically adjusted (without modifying the segment list) 121 based on the result of IOAM measurement to reduce unnecessary IOAM 122 information collection. 124 2. Terminology 126 This document makes use of the terms defined in [RFC8754], and the 127 reader is assumed to be familiar with that terminology. This 128 document introduces the following terms: 130 TPI: TLV Processing Indicator 132 2.1. Requirements Language 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 136 "OPTIONAL" in this document are to be interpreted as described in BCP 137 14 [RFC2119] [RFC8174] when, and only when, they appear in all 138 capitals, as shown here. 140 3. SRH TLV Processing Programming 142 This document defines a new flavor in SRv6 to indicate the SRv6 143 endpoint node to process SRH TLVs. Also, this document defines an 144 SRH TLV processing rule TLV in SRH to describe how to process the TLV 145 on SRv6 endpoint nodes. 147 3.1. TLV Processing Indicator Flavor 149 Currently, SRv6 endpoint nodes will ignore the SRH TLV if there is no 150 local policy to enable processing. 152 When receives an SRv6 packet, in order to explicitly indicate to 153 process SRH TLVs, a TLV Processing Indicator (TPI) Flavor is defined 154 in this document. By default, the node should ignore the SRH TLV. 155 With TPI flavor, SRH TLV processing can be triggered by TPI flavor 156 SID without local configuration. 158 When a TPI flavor SID is processed at an SRv6 node, the node MUST 159 process the SRH TLVs. Otherwise, the SRH TLVs SHOULD be ignored by 160 default or processed based on the local policies as per [RFC8754]. 162 3.2. TLV Processing Indicator TLV 164 When an SRv6 endpoint node receives an SRv6 packet with SRH TLVs, it 165 will process all the TLVs within the SRH, but actually only some TLVs 166 should be processed at this node while most of the TLVs SHOULD be 167 skipped. 169 For example, SRH "S-class" and "D-class" TLVs 170 [I-D.guichard-spring-srv6-simplified-firewall] are processed at 171 Firewall node only and they SHOULD NOT be processed at other nodes 172 along the path. 174 In order to enhance the performance of SRH TLV processing, this 175 section defines TLV processing Indicator (TPI) TLV to describe how to 176 process the SRH TLVs. If the TPI TLV appears in SRH, it MUST be the 177 first TLV for better processing efficiency. Only one TPI TLV is 178 allowed in SRH. If multiple TPI TLVs are included, only the first 179 TLV will be processed and the rest will be ignored. If Its format is 180 shown below. 182 [Editor's notes] This part may be moved to 6man draft in the future 183 since this is an IPv6 dataplane extension. 185 0 1 2 3 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Type | Length |Bitmap Length | TPI Left | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | TLV Processing Indicator 0 (Variable Length)... 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | TLV Processing Indicator 1 (Variable Length)... 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 . ... . 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 Figure 1. SRH TLV Processing Indicator TLV(Variable Length) 199 0 1 200 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Segment Left | Bitmap ... 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Figure 2. TLV Processing Indicator(TPI) Entry 207 * Type: type of TPI TLV, TBA. The TLV MUST be ignored if the node 208 does not have the capability to process the TPI TLV. 210 * Length: Length of the TPI TLV. 212 * Bitmap Length: The length of Bitmap in a TLV Processing Indicator 213 (TPI) entry, in byte. For instance, if there are 6 TLVs (exclude 214 TPI TLV) within the SRH, the length of Bitmap is 1 bytes. If 215 there are 12 TLVs within the SRH (exclude TPI TLV), the length of 216 Bitmap is 2 Bytes. 218 * TPI Left: Index of the active TPI entry in the TPI TLV. 220 * TLV Processing Indicator: A TLV Processing Indicator indicates how 221 to process the SRH TLVs at a specific node associated with the SID 222 in SRH[TPI.SL]. An TPI TLV can include multiple TPI entries to 223 specify the processing rules on multiple nodes. The length of a 224 TPI entry is variable depends on the length of the bitmap. 226 - Segment Left: Segment Left (SL) is the key of a TPI entry, 227 which indicates the node associated with SID in SRH[TPI.SL] 228 needs to process the SRH TLVs according to the TPI entry. When 229 a node processes the TPI TLV, it examines the TPI entry located 230 at TPI-List[TPI Left]. If the value of SRH.SL is equivalent 231 with TPI-List[TPI Left].SL, the node MUST process the SRH TLVs 232 based on the TPI entry, and decrement TPI Left by 1 if TPI Left 233 is greater than 0. If the value of SRH.SL is not equivalent, 234 the processing of the SRH TLVs is skipped. 236 - Bitmap: The bitmap indicates which SRH TLVs are needed to be 237 processed on the node associated with SRH[TPI.SL]. Setting the 238 nth bit means the (n+2)th SRH TLV is required to be processed, 239 since the first TLV in SRH MUST be the TPI TLV and the index of 240 the bitmap begins with 0. For instance, If the second TLV (the 241 First TLV after the TPI TLV) in the SRH is needed to be 242 processed on the node, the first bit (bit 0) in the bitmap is 243 set. If the second TLV and the sixth TLV are needed to be 244 processed, the bit 0 and bit 4 are set in the bitmap. 246 Multiple TPI Entries are encoded after the first 32 bits in TPI TLV 247 following the descending order of SL in TPI entries. 249 [Editor's notes: The TPI TLV MUST be the first TLV in SRH, therefore, 250 the HMAC TLV should be the second one, this may require to update 251 [RFC8754]]. 253 4. Illustration 255 In order to easy understanding, this section describes a simple 256 example. The topology is shown in Figure 3. 258 For instance, an SRv6 packet is forwarded from node 1 to node 6. 259 Therefore, is encoded in the SRH. 260 According to the sevice requirements, the SID3 and SID6 are TPI 261 flavor SID, which indicate the nodes to process SRH TLVs. 4 TLVs are 262 encoded in the SRH, TLV 1 and TLV2 will be processed at node 3, while 263 the TLV3 and TLV 4 will be processed at node 6. Other nodes are not 264 required to process any SRH TLVs of this packet. 266 In the SRH TLV fields, a TPI TLV and the other 4 TLVs are encoded, 267 and the TPI TLV is the first TLV. The value of bitmap length field 268 is 1 since there are only 4 TLVs (TPI TLV is excluded) in the SRH. 270 Two TPI entries are encoded after the first 32 bits in TPI TLV. The 271 length of each TPI entry is 2 bytes, 1 byte for SL and 1 byte for the 272 bitmap. 274 The first TPI entry (TPI-List[0]) describes the SRH TLV processing 275 rules on node 6, and its SL is 0. The bit 2 and bit 3 are set in its 276 bitmap to indicate to process the TLV3 and TLV 4. 278 The last TPI entry (TPI List[1]) describes the SRH TLV processing 279 rules on node 3, and its SL is 3. The bit 0 and bit 1 are set in its 280 bitmap to indicate to process the TLV1 and TLV 2. 282 TLV1, TLV2 TLV3, TLV4 283 1-------2--------3--------4--------5--------6 284 * * 286 Figure 3. Illustration of ESTP 288 * means TPI flavor SID is processed on that node. 290 The TPI Left is initiated as 1 at node 1, and the encoding of TPI TLV 291 in the case is shown below. 293 0 1 2 3 294 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 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Type | Length=8 |Bitmap Length=1| TPI Left=1 | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | SL=0 | |1|1| | SL=3 | |1|1| 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 <- First TPI Entry -><- Last TPI Entry -> 303 Figure 4. Instantiation of TPI TLV at node 1 305 When the packet is received at node 2, the SRH TLVs are skipped by 306 default. 308 When the packet is received at node 3, the SRH TLVs are processed 309 because the SID3 is a TPI floavor SID allocated by node 3. When the 310 node 3 processes SRH TLVs, the first TLV to be processed is the TPI 311 TLV. Node 3 compares the TPI-List[TPI Left].SL and SRH.SL, if they 312 are equivalent, the node 3 processes the TLV 1 and TLV 2 according to 313 the bitmap and updates the TPI Left to be 0. 315 When the packet is received at node 4, the SRH TLVs are skipped by 316 default. 318 When the packet is received at node 5, the SRH TLVs are skipped by 319 default. 321 When the packet is received at node 6, the SRH TLVs are processed 322 because the SID6 is a TPI floavor SID allocated by node 6. When the 323 node 6 processes SRH TLVs, the first TLV to be processed is the TPI 324 TLV. Node 6 compares the TPI-List[TPI Left].SL and SRH.SL, if they 325 are equivalent, the node 6 processes the TLV 3 and TLV 4 according to 326 the bitmap. The TPI Left will not be updated because it is 0 327 already. 329 5. IANA Considerations 331 TBD 333 6. Security Considerations 335 TBD 337 7. Contributors 339 TBD 341 8. Acknowledgements 343 TBD 345 9. References 347 9.1. Normative References 349 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 350 Requirement Levels", BCP 14, RFC 2119, 351 DOI 10.17487/RFC2119, March 1997, 352 . 354 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 355 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 356 May 2017, . 358 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 359 (IPv6) Specification", STD 86, RFC 8200, 360 DOI 10.17487/RFC8200, July 2017, 361 . 363 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 364 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 365 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 366 . 368 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 369 Decraene, B., Litkowski, S., and R. Shakir, "Segment 370 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 371 July 2018, . 373 9.2. Informative References 375 [I-D.guichard-spring-srv6-simplified-firewall] 376 Guichard, J. N., Filsfils, C., Bernier, D., Li, Z., Clad, 377 F., Camarillo, P., and A. AbdelSalam, "Simplifying 378 Firewall Rules with Network Programming and SRH Metadata", 379 Work in Progress, Internet-Draft, draft-guichard-spring- 380 srv6-simplified-firewall-02, 8 April 2020, 381 . 384 Authors' Addresses 386 Cheng Li 387 Huawei Technologies 388 Huawei Campus, No. 156 Beiqing Rd. 389 Beijing 390 100095 391 China 393 Email: c.l@huawei.com 395 Yang Xia 396 Huawei Technologies 397 Huawei Campus, No. 156 Beiqing Rd. 398 Beijing 399 100095 400 China 402 Email: yolanda.xia@huawei.com 404 Dhruv Dhody 405 Huawei Technologies 406 Divyashree Techno Park, Whitefield 407 Bangalore 560066 408 India 410 Email: dhruv.ietf@gmail.com 411 Zhenbin Li 412 Huawei Technologies 413 Huawei Campus, No. 156 Beiqing Rd. 414 Beijing 415 100095 416 China 418 Email: lizhenbin@huawei.com