idnits 2.17.1 draft-clad-spring-srv6-srh-compression-illus-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 10 instances of too long lines in the document, the longest one being 11 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 117: '... bits of the SID MUST be zero. A loca...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (15 October 2021) is 921 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 379 Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING F. Clad, Ed. 3 Internet-Draft D. Dukes, Ed. 4 Intended status: Informational Cisco Systems, Inc. 5 Expires: 18 April 2022 15 October 2021 7 Illustrations for Compressed SRv6 Segment List Encoding in SRH 8 draft-clad-spring-srv6-srh-compression-illus-00 10 Abstract 12 This document provides illustrations for compressed SRv6 Segment List 13 Encoding in the Segment Routing Header (SRH). 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on 18 April 2022. 32 Copyright Notice 34 Copyright (c) 2021 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 39 license-info) in effect on the date of publication of this document. 40 Please review these documents carefully, as they describe your rights 41 and restrictions with respect to this document. Code Components 42 extracted from this document must include Simplified BSD License text 43 as described in Section 4.e of the Trust Legal Provisions and are 44 provided without warranty as described in the Simplified BSD License. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2.1. From RFC 8402 . . . . . . . . . . . . . . . . . . . . . . 2 51 2.2. From RFC 8754 . . . . . . . . . . . . . . . . . . . . . . 3 52 2.3. From RFC 8986 . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Intra-SR-Domain Deployment Model . . . . . . . . . . . . . . 3 54 3.1. Securing the SR Domain . . . . . . . . . . . . . . . . . 3 55 4. General Addressing . . . . . . . . . . . . . . . . . . . . . 4 56 5. NEXT-C-SID Flavor . . . . . . . . . . . . . . . . . . . . . . 4 57 5.1. Addressing and SRv6 SID allocation . . . . . . . . . . . 5 58 5.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 5.3. Case 1: Intra-domain Traffic Engineering . . . . . . . . 5 60 5.4. Case 2: ICMPv6 error generation at a transit node . . . . 8 61 5.5. Case 3: Ping a SID . . . . . . . . . . . . . . . . . . . 9 62 6. REPLACE-C-SID Flavor . . . . . . . . . . . . . . . . . . . . 9 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 66 8.2. Informative References . . . . . . . . . . . . . . . . . 10 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 69 1. Introduction 71 This document provides illustrations for 72 [I-D.filsfilscheng-spring-srv6-srh-compression] compressed SRv6 73 Segment List Encoding in the Segment Routing Header (SRH). 75 2. Terminology 77 This document leverages the terminology introduced in [RFC8402], 78 [RFC8754], and [RFC8986]. The definition of the most important terms 79 is reproduced in this section for convenience. 81 2.1. From RFC 8402 83 Segment Routing domain (SR domain): the set of nodes participating in 84 the source-based routing model. These nodes may be connected to the 85 same physical infrastructure (e.g., a Service Provider's network). 86 They may as well be remotely connected to each other (e.g., an 87 enterprise VPN or an overlay). If multiple protocol instances are 88 deployed, the SR domain most commonly includes all of the protocol 89 instances in a network. However, some deployments may wish to 90 subdivide the network into multiple SR domains, each of which 91 includes one or more protocol instances. It is expected that all 92 nodes in an SR domain are managed by the same administrative entity. 94 2.2. From RFC 8754 96 SR Source Node (section 3.1): A SR source node is any node that 97 originates an IPv6 packet with a segment (i.e., SRv6 SID) in the 98 destination address of the IPv6 header. 100 Transit Node (section 3.2): A transit node is any node forwarding an 101 IPv6 packet where the destination address of that packet is not 102 locally configured as a segment or a local interface. A transit node 103 is not required to be capable of processing a segment or SRH. 105 SR Segment Endpoint Node (section 3.3): An SR segment endpoint node 106 is any node receiving an IPv6 packet where the destination address of 107 that packet is locally configured as a segment or local interface. 109 2.3. From RFC 8986 111 SID Format: This document defines an SRv6 SID as consisting of 112 LOC:FUNCT:ARG, where a locator (LOC) is encoded in the L most 113 significant bits of the SID, followed by F bits of function (FUNCT) 114 and A bits of arguments (ARG). L, the locator length, is flexible, 115 and an operator is free to use the locator length of their choice. F 116 and A may be any value as long as L+F+A <= 128. When L+F+A is less 117 than 128, then the remaining bits of the SID MUST be zero. A locator 118 may be represented as B:N where B is the SRv6 SID block (IPv6 prefix 119 allocated for SRv6 SIDs by the operator) and N is the identifier of 120 the parent node instantiating the SID. 122 3. Intra-SR-Domain Deployment Model 124 The content of this section is a partial reproduction of section 5 125 for [RFC8754]. The reader can easily understand that the dual 126 measures provided can prevent SR packets from leaving the SR domain. 128 The use of the SIDs exclusively within the SR domain and solely for 129 packets of the SR domain is an important deployment model. 131 This enables the SR domain to act as a single routing system. 133 3.1. Securing the SR Domain 135 Nodes outside the SR domain are not trusted: they cannot directly use 136 the SIDs of the domain. This is enforced by two levels of access 137 control lists: 139 * Any packet entering the SR domain and destined to a SID within the 140 SR domain is dropped. This may be realized with the following 141 logic. Other methods with equivalent outcome are considered 142 compliant: 144 - Allocate all the SIDs from a block S/s 146 - Configure each external interface of each edge node of the 147 domain with an inbound infrastructure access list (IACL) that 148 drops any incoming packet with a destination address in S/s 150 - Failure to implement this method of ingress filtering exposes 151 the SR domain to source-routing attacks, as described and 152 referenced in [RFC5095] 154 * The distributed protection in #1 is complemented with per-node 155 protection, dropping packets to SIDs from source addresses outside 156 the SR domain. This may be realized with the following logic. 157 Other methods with equivalent outcome are considered compliant: 159 - Assign all interface addresses from prefix A/a 161 - At node k, all SIDs local to k are assigned from prefix Sk/sk 163 - Configure each internal interface of each SR node k in the SR 164 domain with an inbound IACL that drops any incoming packet with 165 a destination address in Sk/sk if the source address is not in 166 A/a. 168 4. General Addressing 170 The illustrations in this document use the IPv6 documentation prefix 171 2001:db8::/32. 173 Loopback interface addresses are allocated from the prefix 174 2001:db8:a::/48. 176 SRv6 SIDs are allocated from the prefix 2001:db8:b::/48. 178 An operator deploying this solution could instead select any sub- 179 prefix out of the prefix allocated by their Regional Internet 180 Registry (RIR) to this operator or from the Unique Local Unicast 181 (ULA) prefix. ULA provides the uniqueness and privacy 182 characteristics defined in Section 1 of [RFC4193]. 184 5. NEXT-C-SID Flavor 185 + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 186 N11 N13 N15 N17 | 187 | 188 N10 N19| 189 | 190 N12 N14 N16 N18 | 191 + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 192 SR domain 194 Figure 1: Reference topology 196 N10 to N19 represent the potential SR source and SR segment endpoint 197 nodes in the SR domain. 199 The SR domain may include any number of transit nodes (not shown) 200 between the nodes that are represented in this figure. 202 5.1. Addressing and SRv6 SID allocation 204 Nodes N10 to N19 have a loopback interface configured with the 205 address 2001:db8:a:NN00::, where NN is the node identifier. 207 Nodes N10 to N19 instantiate the SID 2001:db8:b:NN00::, where NN is 208 the node identifier, with Locator-Block length (LBL) = 48, Locator- 209 Node length (LNL)= 16, Function length (FL) = 0, Argument length (AL) 210 = 64, and bound to the End behavior with the NEXT-C-SID and USD 211 flavors. 213 The "Endpoint" (or "End") behavior is the most basic operation that 214 can be performed by an SR segment endpoint node (i.e., a node that 215 identifies the destination address of a received packet as matching a 216 locally instantiated SID). It updates the destination address of the 217 packet with the next SID in the segment list. The pseudocode of the 218 End behavior with the NEXT-C-SID and USD flavors is specified in 219 section 4.1.1 of [I-D.filsfilscheng-spring-srv6-srh-compression]. 221 5.2. Routing 223 Nodes N10 to N19 advertise the prefixes 2001:db8:a:NN00::/64 and 224 2001:db8:b:NN00::/64, where NN is the node identifier, in the IGP. 226 5.3. Case 1: Intra-domain Traffic Engineering 228 Let us assume that a centralized controller programs N11 to classify 229 the traffic from 2001:db8:a:1000:: to 2001:db8:a:1900:: into an SR 230 Policy encoded through an IPv6 encapsulation with: 232 * IPv6 233 - Source address 2001:db8:a:1100:: 235 - Destination address 2001:db8:b:1200:1300:1400:1500:1600 237 - Next Header = 43 (Routing header) 239 * SRH 241 - Segment List < 2001:db8:b:1200:1300:1400:1500:1600, 242 2001:db8:b:1700:1800:: > 244 - Segments Left = 1 246 - Next Header = 41 (IPv6) 248 For illustration purposes, we use SID allocation that allows for a 249 straightforward human reading of a compressed segment list. Indeed, 250 < 2001:db8:b:1200:1300:1400:1500:1600, 2001:db8:b:1700:1800:: > 251 means: within the domain 2001:db8:b::, go first through node N12 then 252 N13, N14, N15, and N16, then retrieve the next segment list entry 253 from the SRH and go through node N17 before decapsulating the packet 254 at node N18. 256 This is compliant with the RFC 8986 because the SID meets the 257 Locator:Function:Argument format definition (section 3.1 of RFC 258 8986). For example, the packet sent by node N11 has a destination 259 address 2001:db8:b:1200:1300:1400:1500:1600 where 2001:db8:b:1200/64 260 is the Locator and 0x1300140015001600 is the Argument. 262 A packet in transit towards a given SID (e.g. 263 2001:db8:b:1200:1300:1400:1500:1600), is forwarded by transit nodes 264 via a longest-match lookup on the destination address of the packet. 265 This results in a match of the SID locator (in this case, 266 2001:db8:b:1200::/64), the transit node then forwards the packet 267 accordingly. The SID function and argument bits are opaque to 268 transit nodes. The function is only identified at the SR segment 269 endpoint node (represented by the SID locator in the destination 270 address) which further processes the argument. 272 Also note the source N11 performs IPv6 header encapsulation with SRH, 273 and the selected SID list containing function/arguments to be 274 processed at some endpoints, because we are in a source routed domain 275 within a secured SR domain. 277 The remainder of this section details the packet journey. 279 The packet Px transmitted by a node Nn is identified as "@Nn Px". 281 @N10 P1:(IPv6 2001:db8:a:1000::, 2001:db8:a:1900::) 283 N11 (as programmed by the centralized controller) encapsulates the 284 packet P1 and submits the updated packet (P2) to the IPv6 module for 285 transmission. It performs an IP lookup on the destination address, 286 matching an entry for the prefix 2001:db8:b:1200::/64 advertised by 287 N21. N11 forwards the packet on its shortest path towards to node 288 N12. 290 @N11 P2:(IPv6 2001:db8:a:1100::, 2001:db8:b:1200:1300:1400:1500:1600) 291 (SRH 2001:db8:b:1700:1800::, 2001:db8:b:1200:1300:1400:1500:1600; SL=1) 292 (IPv6 2001:db8:a:1000::, 2001:db8:a:1900::) 294 The transit nodes between N11 and N12 forward P1 as per their route 295 2001:db8:b:1200::/64 to N12. Similarly, the transit nodes between 296 each subsequent pair of consecutive SR segment endpoint nodes 297 forwards the packet as per their IPv6 routes for the destination 298 address. Those transit nodes are plain IPv6 routers with the plain 299 IPv6 dataplane, they do not need to have any knowledge of SRv6. 301 The hop limit of packet P1 is decremented at every transit node and 302 every SR segment endpoint node. 304 When the packet reaches the first SR segment endpoint node N12 (i.e., 305 the first TE waypoint), this performs a longest-prefix-match lookup 306 on the IPv6 destination address. This lookup returns a FIB entry 307 that represents a locally instantiated SRv6 SID bound to the End 308 behavior with the NEXT-C-SID flavor. N12 processes the packet 309 accordingly, resulting in a new destination address. It then submits 310 the updated packet to the IPv6 module for transmission. This 311 triggers an IP lookup on the destination address, matching an entry 312 for the prefix 2001:db8:b:1300::/64 advertised by N13. The packet is 313 forwarded on the shortest path towards N13. 315 @N12 P2:(IPv6 2001:db8:a:1100::, 2001:db8:b:1300:1400:1500:1600:0000) 316 (SRH 2001:db8:b:1700:1800::, 2001:db8:b:1200:1300:1400:1500:1600; SL=1) 317 (IPv6 2001:db8:a:1000::, 2001:db8:a:1900::) 319 The subsequent SR segment endpoint nodes N13 to N17 process the 320 packet similarly. 322 @N13 P2:(IPv6 2001:db8:a:1100::, 2001:db8:b:1400:1500:1600:0000:0000) 323 (SRH 2001:db8:b:1700:1800::, 2001:db8:b:1200:1300:1400:1500:1600; SL=1) 324 (IPv6 2001:db8:a:1000::, 2001:db8:a:1900::) 326 @N14 P2:(IPv6 2001:db8:a:1100::, 2001:db8:b:1500:1600:0000:0000:0000) 327 (SRH 2001:db8:b:1700:1800::, 2001:db8:b:1200:1300:1400:1500:1600; SL=1) 328 (IPv6 2001:db8:a:1000::, 2001:db8:a:1900::) 330 @N15 P2:(IPv6 2001:db8:a:1100::, 2001:db8:b:1600:0000:0000:0000:0000) 331 (SRH 2001:db8:b:1700:1800::, 2001:db8:b:1200:1300:1400:1500:1600; SL=1) 332 (IPv6 2001:db8:a:1000::, 2001:db8:a:1900::) 334 When the packet is processed by the SR segment endpoint node N16, the 335 SID argument value is 0. As per the pseudocode of the End behavior 336 with the NEXT-C-SID and USD flavors, N16 retrieves the next SID by 337 decrementing the value of segments left in the SRH and copying the 338 next entry from the SRH segment list into the destination address. 340 @N16 P2:(IPv6 2001:db8:a:1100::, 2001:db8:b:1700:1800::) 341 (SRH 2001:db8:b:1700:1800::, 2001:db8:b:1200:1300:1400:1500:1600; SL=0) 342 (IPv6 2001:db8:a:1000::, 2001:db8:a:1900::) 344 @N17 P2:(IPv6 2001:db8:a:1100::, 2001:db8:b:1800:0000::) 345 (SRH 2001:db8:b:1700:1800::, 2001:db8:b:1200:1300:1400:1500:1600; SL=0) 346 (IPv6 2001:db8:a:1000::, 2001:db8:a:1900::) 348 When the packet reaches the final SR segment endpoint node N18, both 349 the SID argument value and the segments left value in the SRH are 0. 350 As per the pseudocode of the End behavior with the NEXT-C-SID and USD 351 flavors, N18 decapsulates the packet and sends the inner packet P1 352 towards its destination 2001:db8:a:1900::. 354 @N18 P1:(IPv6 2001:db8:a:1000::, 2001:db8:a:1900::) 356 5.4. Case 2: ICMPv6 error generation at a transit node 358 Let us assume in the previous example that the hop limit expires on a 359 transit node N141, located on the path between the SR segment 360 endpoint nodes N14 and N15. 362 The packet sent by node N14 is as follows (reproduced from the 363 previous section). 365 @N14 P2:(IPv6 2001:db8:a:1100::, 2001:db8:b:1500:1600:0000:0000:0000) 366 (SRH 2001:db8:b:1700:1800::, 2001:db8:b:1200:1300:1400:1500:1600; SL=1) 367 (IPv6 2001:db8:a:1000::, 2001:db8:a:1900::) 369 Node N141 generates an ICMPv6 time exceeded error message as follows. 371 @N141 P3: (IPv6 , 2001:db8:a:1100::) 372 (ICMPv6 time exceeded error 373 (IPv6 2001:db8:a:1100::, 2001:db8:b:1500:1600:0000:0000:0000) 374 (SRH 2001:db8:b:1700:1800::, 2001:db8:b:1200:1300:1400:1500:1600; SL=1) 375 (IPv6 2001:db8:a:1000::, 2001:db8:a:1900::)) 377 Node N11 receives the ICMP error packet transmitted by N141. 378 Section 5.4 of RFC8754 indicates that a destination address of the 379 invoking packet is determined by looking at segment list[0]. 381 5.5. Case 3: Ping a SID 383 The operator wants to ping the End with NEXT-C-SID flavor SID 384 2001:db8:b:1200:: of N12 from the SR source node N10. 386 The ICMP echo request is sent by N10 as follows. 388 @N10 P1:(IPv6 2001:db8:a:1000::, 2001:db8:b:1200::) 389 (ICMPv6 echo request) 391 This results in an ICMP echo reply from N12 to N10. 393 @N12 P2:(IPv6 2001:db8:b:1200::, 2001:db8:a:1000::) 394 (ICMPv6 echo reply) 396 6. REPLACE-C-SID Flavor 398 TBD 400 7. Acknowledgements 402 TBD 404 8. References 406 8.1. Normative References 408 [I-D.filsfilscheng-spring-srv6-srh-compression] 409 Cheng, W., Filsfils, C., Li, Z., Decraene, B., Cai, D., 410 Voyer, D., Clad, F., Zadok, S., Guichard, J. N., Aihua, 411 L., Raszuk, R., and C. Li, "Compressed SRv6 Segment List 412 Encoding in SRH", Work in Progress, Internet-Draft, draft- 413 filsfilscheng-spring-srv6-srh-compression-02, 28 July 414 2021, . 417 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 418 Decraene, B., Litkowski, S., and R. Shakir, "Segment 419 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 420 July 2018, . 422 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 423 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 424 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 425 . 427 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 428 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 429 (SRv6) Network Programming", RFC 8986, 430 DOI 10.17487/RFC8986, February 2021, 431 . 433 8.2. Informative References 435 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 436 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 437 . 439 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 440 of Type 0 Routing Headers in IPv6", RFC 5095, 441 DOI 10.17487/RFC5095, December 2007, 442 . 444 Authors' Addresses 446 Francois Clad (editor) 447 Cisco Systems, Inc. 448 France 450 Email: fclad@cisco.com 452 Darren Dukes (editor) 453 Cisco Systems, Inc. 454 Canada 456 Email: ddukes@cisco.com