idnits 2.17.1 draft-li-spring-srh-tlv-processing-programming-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 date (May 28, 2021) is 1064 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 275 -- Looks like a reference, but probably isn't: '1' on line 279 == Unused Reference: 'RFC8200' is defined on line 359, 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: November 29, 2021 Z. Li 6 Huawei Technologies 7 May 28, 2021 9 SRH TLV Processing Programming 10 draft-li-spring-srh-tlv-processing-programming-01 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 November 29, 2021. 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 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 3. SRH TLV Processing Programming . . . . . . . . . . . . . . . 3 60 3.1. TLV Processing Indicator Flavor . . . . . . . . . . . . . 4 61 3.2. TLV Processing Indicator TLV . . . . . . . . . . . . . . 4 62 4. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 6 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 66 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 69 9.2. Informative References . . . . . . . . . . . . . . . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 Segment routing (SR) [RFC8402] is a source routing paradigm that 75 explicitly indicates the forwarding path for packets at the ingress 76 node by inserting an ordered list of instructions, called segments. 78 When segment routing is deployed on the IPv6 data plane, it is called 79 SRv6 [RFC8754]. For support of SR, a new routing header called 80 Segment Routing Header (SRH), containing a list of segments, optional 81 TLVs and other information, has been defined in [RFC8754]. 83 Currently, when TLVs are carried in an SRH, they are ignored by the 84 nodes by default, unless there are some local policies on nodes to 85 enable the SRH TLV processing [RFC8754]. 87 When a node is configured to process a TLV, it needs to examine all 88 the SRH TLVs for processing a single TLV (TLVs except HMAC in SRH MAY 89 appear in any order), which is inefficient. 91 Furthermore, in order to deploy a new service, network operators need 92 to configure multiple nodes along the path to support SRH TLVs 93 processing, which is complicated. Also, it is not easy to 94 dynamically adjustment the local policy for meeting dynamic service 95 requirements. However, SRv6 does not have the compability to program 96 the rules of SRH TLVs processing on the ingress node currently. 98 In summary, network operator are not able to program the SRH TLV 99 processing rules on the ingress node to process specific TLVs on 100 specific segment endpoint nodes for some packets dynamically. 102 This document proposes a mechanism to program the SRH TLVs processing 103 rules explicitly and dynamically on the ingress node. In this 104 mechanism, there is no need to configure nodal local policy to 105 support SRH TLV processing. It can be used for the following use 106 cases: 108 o Service Function Chaining (SFC): In SFC, SRH TLVs like Firewall 109 related TLVs [I-D.guichard-spring-srv6-simplified-firewall] may 110 only be processed on some specific nodes instead of all the nodes 111 along the path. 113 o Smart In-situ OAM (IOAM): In IOAM, the IOAM metadata will be 114 collected by all the nodes along the path. However, in the most 115 cases, only the metadatda on some nodes are important for OAM, 116 while the others are redundant or irrelevant. For example, 117 congestion may occur only on some nodes, not all nodes. In 118 addition, congestion may occur on link A at the last moment and 119 may occur on link B at the next moment. To implement smarter and 120 more efficient IOAM, the scope of IOAM metadata collection needs 121 to be dynamically adjusted (without modifying the segment list) 122 based on the result of IOAM measurement to reduce unnecessary IOAM 123 information collection. 125 2. Terminology 127 This document makes use of the terms defined in [RFC8754], and the 128 reader is assumed to be familiar with that terminology. This 129 document introduces the following terms: 131 TPI: TLV Processing Indicator 133 2.1. Requirements Language 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 137 "OPTIONAL" in this document are to be interpreted as described in BCP 138 14 [RFC2119] [RFC8174] when, and only when, they appear in all 139 capitals, as shown here. 141 3. SRH TLV Processing Programming 143 This document defines a new flavor in SRv6 to indicate the SRv6 144 endpoint node to process SRH TLVs. Also, this document defines an 145 SRH TLV processing rule TLV in SRH to describe how to process the TLV 146 on SRv6 endpoint nodes. 148 3.1. TLV Processing Indicator Flavor 150 Currently, SRv6 endpoint nodes will ignore the SRH TLV if there is no 151 local policy to enable processing. 153 When receives an SRv6 packet, in order to explicitly indicate to 154 process SRH TLVs, a TLV Processing Indicator (TPI) Flavor is defined 155 in this document. By default, the node should ignore the SRH TLV. 156 With TPI flavor, SRH TLV processing can be triggered by TPI flavor 157 SID without local configuration. 159 When a TPI flavor SID is processed at an SRv6 node, the node MUST 160 process the SRH TLVs. Otherwise, the SRH TLVs SHOULD be ignored by 161 default or processed based on the local policies as per [RFC8754]. 163 3.2. TLV Processing Indicator TLV 165 When an SRv6 endpoint node receives an SRv6 packet with SRH TLVs, it 166 will process all the TLVs within the SRH, but actually only some TLVs 167 should be processed at this node while most of the TLVs SHOULD be 168 skipped. 170 For example, SRH "S-class" and "D-class" TLVs 171 [I-D.guichard-spring-srv6-simplified-firewall] are processed at 172 Firewall node only and they SHOULD NOT be processed at other nodes 173 along the path. 175 In order to enhance the performance of SRH TLV processing, this 176 section defines TLV processing Indicator (TPI) TLV to describe how to 177 process the SRH TLVs. If the TPI TLV appears in SRH, it MUST be the 178 first TLV for better processing efficiency. Only one TPI TLV is 179 allowed in SRH. If multiple TPI TLVs are included, only the first 180 TLV will be processed and the rest will be ignored. If Its format is 181 shown below. 183 [Editor's notes] This part may be moved to 6man draft in the future 184 since this is an IPv6 dataplane extension. 186 0 1 2 3 187 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 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Type | Length |Bitmap Length | TPI Left | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | TLV Processing Indicator 0 (Variable Length)... 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | TLV Processing Indicator 1 (Variable Length)... 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 . ... . 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 Figure 1. SRH TLV Processing Indicator TLV(Variable Length) 200 0 1 201 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Segment Left | Bitmap ... 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 Figure 2. TLV Processing Indicator(TPI) Entry 208 o Type: type of TPI TLV, TBA. The TLV MUST be ignored if the node 209 does not have the capability to process the TPI TLV. 211 o Length: Length of the TPI TLV. 213 o Bitmap Length: The length of Bitmap in a TLV Processing Indicator 214 (TPI) entry, in byte. For instance, if there are 6 TLVs (exclude 215 TPI TLV) within the SRH, the length of Bitmap is 1 bytes. If 216 there are 12 TLVs within the SRH (exclude TPI TLV), the length of 217 Bitmap is 2 Bytes. 219 o TPI Left: Index of the active TPI entry in the TPI TLV. 221 o TLV Processing Indicator: A TLV Processing Indicator indicates how 222 to process the SRH TLVs at a specific node associated with the SID 223 in SRH[TPI.SL]. An TPI TLV can include multiple TPI entries to 224 specify the processing rules on multiple nodes. The length of a 225 TPI entry is variable depends on the length of the bitmap. 227 * Segment Left: Segment Left (SL) is the key of a TPI entry, 228 which indicates the node associated with SID in SRH[TPI.SL] 229 needs to process the SRH TLVs according to the TPI entry. When 230 a node processes the TPI TLV, it examines the TPI entry located 231 at TPI-List[TPI Left]. If the value of SRH.SL is equivalent 232 with TPI-List[TPI Left].SL, the node MUST process the SRH TLVs 233 based on the TPI entry, and decrement TPI Left by 1 if TPI Left 234 is greater than 0. If the value of SRH.SL is not equivalent, 235 the processing of the SRH TLVs is skipped. 237 * Bitmap: The bitmap indicates which SRH TLVs are needed to be 238 processed on the node associated with SRH[TPI.SL]. Setting the 239 nth bit means the (n+2)th SRH TLV is required to be processed, 240 since the first TLV in SRH MUST be the TPI TLV and the index of 241 the bitmap begins with 0. For instance, If the second TLV (the 242 First TLV after the TPI TLV) in the SRH is needed to be 243 processed on the node, the first bit (bit 0) in the bitmap is 244 set. If the second TLV and the sixth TLV are needed to be 245 processed, the bit 0 and bit 4 are set in the bitmap. 247 Multiple TPI Entries are encoded after the first 32 bits in TPI TLV 248 following the descending order of SL in TPI entries. 250 [Editor's notes: The TPI TLV MUST be the first TLV in SRH, therefore, 251 the HMAC TLV should be the second one, this may require to update 252 [RFC8754]]. 254 4. Illustration 256 In order to easy understanding, this section describes a simple 257 example. The topology is shown in Figure 3. 259 For instance, an SRv6 packet is forwarded from node 1 to node 6. 260 Therefore, is encoded in the SRH. 261 According to the sevice requirements, the SID3 and SID6 are TPI 262 flavor SID, which indicate the nodes to process SRH TLVs. 4 TLVs are 263 encoded in the SRH, TLV 1 and TLV2 will be processed at node 3, while 264 the TLV3 and TLV 4 will be processed at node 6. Other nodes are not 265 required to process any SRH TLVs of this packet. 267 In the SRH TLV fields, a TPI TLV and the other 4 TLVs are encoded, 268 and the TPI TLV is the first TLV. The value of bitmap length field 269 is 1 since there are only 4 TLVs (TPI TLV is excluded) in the SRH. 271 Two TPI entries are encoded after the first 32 bits in TPI TLV. The 272 length of each TPI entry is 2 bytes, 1 byte for SL and 1 byte for the 273 bitmap. 275 The first TPI entry (TPI-List[0]) describes the SRH TLV processing 276 rules on node 6, and its SL is 0. The bit 2 and bit 3 are set in its 277 bitmap to indicate to process the TLV3 and TLV 4. 279 The last TPI entry (TPI List[1]) describes the SRH TLV processing 280 rules on node 3, and its SL is 3. The bit 0 and bit 1 are set in its 281 bitmap to indicate to process the TLV1 and TLV 2. 283 TLV1, TLV2 TLV3, TLV4 284 1-------2--------3--------4--------5--------6 285 * * 287 Figure 3. Illustration of ESTP 289 * means TPI flavor SID is processed on that node. 291 The TPI Left is initiated as 1 at node 1, and the encoding of TPI TLV 292 in the case is shown below. 294 0 1 2 3 295 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 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Type | Length=8 |Bitmap Length=1| TPI Left=1 | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | SL=0 | |1|1| | SL=3 | |1|1| 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 <- First TPI Entry -><- Last TPI Entry -> 304 Figure 4. Instantiation of TPI TLV at node 1 306 When the packet is received at node 2, the SRH TLVs are skipped by 307 default. 309 When the packet is received at node 3, the SRH TLVs are processed 310 because the SID3 is a TPI floavor SID allocated by node 3. When the 311 node 3 processes SRH TLVs, the first TLV to be processed is the TPI 312 TLV. Node 3 compares the TPI-List[TPI Left].SL and SRH.SL, if they 313 are equivalent, the node 3 processes the TLV 1 and TLV 2 according to 314 the bitmap and updates the TPI Left to be 0. 316 When the packet is received at node 4, the SRH TLVs are skipped by 317 default. 319 When the packet is received at node 5, the SRH TLVs are skipped by 320 default. 322 When the packet is received at node 6, the SRH TLVs are processed 323 because the SID6 is a TPI floavor SID allocated by node 6. When the 324 node 6 processes SRH TLVs, the first TLV to be processed is the TPI 325 TLV. Node 6 compares the TPI-List[TPI Left].SL and SRH.SL, if they 326 are equivalent, the node 6 processes the TLV 3 and TLV 4 according to 327 the bitmap. The TPI Left will not be updated because it is 0 328 already. 330 5. IANA Considerations 332 TBD 334 6. Security Considerations 336 TBD 338 7. Contributors 340 TBD 342 8. Acknowledgements 344 TBD 346 9. References 348 9.1. Normative References 350 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 351 Requirement Levels", BCP 14, RFC 2119, 352 DOI 10.17487/RFC2119, March 1997, 353 . 355 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 356 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 357 May 2017, . 359 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 360 (IPv6) Specification", STD 86, RFC 8200, 361 DOI 10.17487/RFC8200, July 2017, 362 . 364 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 365 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 366 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 367 . 369 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 370 Decraene, B., Litkowski, S., and R. Shakir, "Segment 371 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 372 July 2018, . 374 9.2. Informative References 376 [I-D.guichard-spring-srv6-simplified-firewall] 377 Guichard, J. N., Filsfils, C., Bernier, D., Li, Z., Clad, 378 F., Camarillo, P., and A. AbdelSalam, "Simplifying 379 Firewall Rules with Network Programming and SRH Metadata", 380 draft-guichard-spring-srv6-simplified-firewall-02 (work in 381 progress), April 2020. 383 Authors' Addresses 385 Cheng Li 386 Huawei Technologies 387 Huawei Campus, No. 156 Beiqing Rd. 388 Beijing 100095 389 China 391 Email: c.l@huawei.com 393 Yang Xia 394 Huawei Technologies 395 Huawei Campus, No. 156 Beiqing Rd. 396 Beijing 100095 397 China 399 Email: yolanda.xia@huawei.com 401 Dhruv Dhody 402 Huawei Technologies 403 Divyashree Techno Park, Whitefield 404 Bangalore 560066 405 India 407 Email: dhruv.ietf@gmail.com 408 Zhenbin Li 409 Huawei Technologies 410 Huawei Campus, No. 156 Beiqing Rd. 411 Beijing 100095 412 China 414 Email: lizhenbin@huawei.com