idnits 2.17.1 draft-li-spring-anycast-sid-service-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 (March 23, 2021) is 1127 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) == Unused Reference: 'RFC8174' is defined on line 378, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 382, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3513 (Obsoleted by RFC 4291) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Spring Working Group T. Li 3 Internet-Draft X. Zhou 4 Intended status: Standards Track CNIC, CAS 5 Expires: September 24, 2021 Z. Chen 6 Y. Jia 7 Huawei Technologies 8 March 23, 2021 10 Anycast SID for Flexible and Robust Service in SRv6 11 draft-li-spring-anycast-sid-service-02 13 Abstract 15 Segment Routing enables an operator or an application to specify a 16 packet processing program. When Segment Routing is applied to IPv6 17 data plane, the list of IPv6 SIDs in SRH can specify a series of 18 execution endpoints that hold service functions that process the 19 packet. However, steering traffic dynamically to the different 20 execution endpoints requires a specific "re-encapsulating". This 21 procedure may be complex and take time. 23 This document proposes A-SID (Anycast-SID) based on SRv6 to achieve 24 flexible and robust service provision. It uses anycast SID to 25 identify service functions and locates the service functions based on 26 anycast routing. The proposed solution can stay compatibility with 27 the existing SRv6. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 24, 2021. 46 Copyright Notice 48 Copyright (c) 2021 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Anycast SID (A-SID) . . . . . . . . . . . . . . . . . . . . . 3 65 3. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 5. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 6 68 5.1. Usecase1 migration of service function . . . . . . . . . 7 69 5.2. Usecase2 failover of service function . . . . . . . . . . 7 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 74 8.2. Informative References . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 Segment Routing [RFC8402] enables an operator or an application to 80 specify a packet processing program. SRv6 applies Segment Routing to 81 IPv6 data plane. A new routing header for IPv6, which is called 82 Segment Routing Header (SRH) [RFC8754] is defined to carry 128-bit 83 SIDs. The list of IPv6 SIDs in SRH can specify not only a TE path, 84 but also a series of execution endpoints that hold service functions 85 that process the packet. In this way, a service function chain 86 [RFC7665] is formed based on SRv6. 88 However, more and more functions, such as firewall and DPI, are 89 deployed in cloud technology and Network Function Virtualization, 90 which means that a single function may be deployed on multiple 91 execution locations and the function may be migrated to different 92 locations frequently. Steering traffic dynamically to the different 93 execution endpoints requires a specific "re-encapsulating" frequently 94 at the ingress router. This procedure may be complex and take time. 96 This document proposes A-SID (Anycast-SID) based on SRv6 to achieve 97 flexible and robust service provision. In addition to the SIDs that 98 are used for TE path on the node, specific A-SIDs are used for 99 service function chain. The execution endpoints share a SID Locator 100 and the kind of functions is identified by Function and Argument. 101 The A-SIDs are advertised by the control plane and the packets are 102 forwarded to the execution endpoints based on anycast routing. The 103 proposed solution can stay compatibility with the existing SRv6. 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119, and BCP 14 108 [RFC2119] 110 The definitions of the SRv6 terms, such as SRv6, SID, SRH, locator 111 and function can be found in [RFC8754], [RFC8402], and [RFC8986]. 112 The definition of Service Function Chain can be found in [RFC7665]. 113 The definition of anycast can be found in [RFC3513]. 115 This document introduces the following new terms: 117 A-SID: Anycast-based Segment Identifier. 119 2. Anycast SID (A-SID) 121 The SRv6 SID contains 16 bytes and can be separated into three parts: 122 locator, function, and argument. As for the argument, we consider it 123 as the accessory of function. So this document omits argument for a 124 clear description and the SRv6 SID can be mainly separated into two 125 parts: locator and function. 127 All of the SRv6 endpoints have their own SIDs instantiated in the FIB 128 table locally and advertised by the control plane as defined in 129 [RFC8986]. In addition to the existing SRv6 SIDs, the execution 130 endpoints that hold service functions also have Anycast SIDs. The 131 Locator of Anycast SID is shared by all the execution endpoints in 132 the SR domain. In other words, one specific Locator is allocated to 133 the execution endpoints to identify the Anycast SIDs. The Function 134 of Anycast SID identifies the kind of service functions that the 135 endpoint node can provide. That is, if two execution endpoints 136 provide the same kind of service functions, they will have the same 137 Anycast SID. 139 The routing process of A-SID may follow the standard anycast routing. 140 As another option, the routing of A-SID may be based on the 141 processing capacity or computing power of endpoint node. The 142 processing capacity or computing power of endpoint can be advertised 143 along with the A-SID in the control plane. In this way, two 144 execution endpoints that provide the same kind of service functions 145 with the same A-SID can be chosen based on bigger processing capacity 146 or computing power. The detailed design and extensions to control 147 plane will be stated in the next version. 149 0 16 bytes 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Locator | Function | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 |<---Shared locator-->| 154 |<---------------Anycast SID--------------->| 156 Figure 1: Anycast SID 158 For example, the shared Locator is A::/64, Service Functions (SFs)1 - 159 3 are identified by B1 - B3. Node 1 provides SF1, node 2 and node 3 160 provide SF2, and node 4 provides SF3. The Anycast SIDs are shown in 161 Figure 2. 163 +-+-+ +-+-+ +-+-+ 164 |SF1| |SF2| |SF3| 165 +-+-+ +-+-+ +-+-+ 166 | | A::B2 | 167 | +-+-+-+-+ | 168 | +-+-+-+-+node 2 +-+-+-+-+ | 169 +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ 170 |ingress| +-+-+-+-+ +-+-+-+-+ |egress | 171 | node +-+-+-+node 1 | |node 4 +-+-+-+ node | 172 | | +-+-+-+-+ +-+-+-+-+ | | 173 +-+-+-+-+ A::B1 | +-+-+-+-+ | A::B3 +-+-+-+-+ 174 +-+-+-+-+node 3 +-+-+-+-+ 175 +-+-+-+-+ 176 | A::B2 177 +-+-+ 178 |SF2| 179 +-+-+ 181 Figure 2: the Anycast SIDs 183 A::/64 is allocated and shared by node 1 to node 4. 185 3. Control Plane 187 The reachability of Anycast SIDs are advertised by control plane. As 188 described in [I-D.draft-ietf-lsr-isis-srv6-extensions], a new flag in 189 "Bit Values for Prefix Attribute Flags Sub-TLV" registry [RFC7794] is 190 defined to advertise the anycast property. SRv6 Locator TLV is 191 introduced to advertise Locators and End SIDs associated with each 192 locator. This TLV shares the sub-TLV space defined for TLVs 135, 236 193 and 237. 195 This document adopts the Anycast Flag (A-flag). In addition, this 196 document defines a new flag in SRv6 End SID sub-TLV. The format is 197 as follows: 199 0 1 2 3 200 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 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Type | Length | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Flags | Endpoint Behavior | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Anycast SID (128 bits) . . . | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Anycast SID (cont . . .) | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Anycast SID (cont . . .) | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Anycast SID (cont . . .) | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 |Sub-sub-tlv-len| sub-sub-TLVs(variable). . . | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 Figure 3: Anycast SID Format 219 Type: 5 (defined in [I-D.draft-ietf-lsr-isis-srv6-extensions]). 221 Length: Variable. 223 Flags: 8 bits. 225 0 1 2 3 4 5 6 7 226 +-+-+-+-+-+-+-+-+ 227 |A|U|U|U|U|U|U|U| 228 +-+-+-+-+-+-+-+-+ 230 Figure 4: Anycast Flag 232 U: Unused and for future use. Must be 0 on transmission and ignored 233 on receipt. 235 A: Anycast flag, set when the SRv6 End SID sub-TLV carries the 236 Anycast SIDs. 238 Endpoint Behavior: 16 bits, code point that identifies the service 239 functions. 241 Anycast SID: 128 bits. 243 Sub-sub-TLV-length: defined in 244 [I-D.draft-ietf-lsr-isis-srv6-extensions]. 246 Sub-sub-TLVs: defined in [I-D.draft-ietf-lsr-isis-srv6-extensions]. 248 The Anycast SID MUST be a subnet of the associated Locator. Anycast 249 SIDs which are NOT a subnet of the associated locator MUST be 250 ignored. 252 Multiple Anycast SIDs MAY be associated with the same locator when a 253 execution endpoint holds multiple service functions. In cases where 254 the number of SRv6 End SID sub-TLVs exceeds the capacity of a single 255 TLV, multiple Locator TLVs for the same locator MAY be advertised. 256 Other details are defined in 257 [I-D.draft-ietf-lsr-isis-srv6-extensions]. 259 4. Data Plane 261 This document requires no data plane format extensions to SRv6 and 262 the Anycast SID has no differences with other SIDs. Anycast SIDs 263 stay together with other SIDs in the SRH and the SID list can not 264 only steer the packet along a TE path but also specifies the service 265 functions that should process the packet. 267 The Anycast SIDs are advertised by control plane and instantiated in 268 the local FIB.When a SRv6-capable node receives an IPv6 packet, it 269 performs a long-prefix-match lookup on the packets destination 270 address. This lookup may return a FIB entry that represents a 271 locally instantiated SID. If this matched SID is Anycast SID, the 272 node should process the packet with the service function identified 273 by the Anycast SID. 275 5. Illustration 276 5.1. Usecase1 migration of service function 278 As illustrated in Figure 5, a SRv6-based service function chain needs 279 to go through SF1, SF2 and SF3. At the beginning, SF1, SF2 and SF3 280 are provided on node 1, node 2 and node 4. Then, SF2 is migrated to 281 node 3 and the flow should change the path. In addition to SRv6 SIDs 282 A1::B1, A2::B2, A3::B2 and A4::B3 on the four nodes, they also have 283 Anycast SIDs instantiated locally and advertised by the control 284 plane. 286 If original SRv6 is used, the SRH is (A1::B1, A2::B2, A4::B3) before 287 the migration and (A1::B1, A2::B2, A4::B3) after the migration. The 288 ingress node should change the encapsulation strategies under control 289 of the controller and re-encapsulate the packets. 291 If Anycast SID is used, the SRH is (A::B1, A::B2, A::B3) before and 292 after migration. No changes to the SRH is needed. Node 2 withdraws 293 the route of A::B2 and Node 3 advertises A::B2. Then the packets are 294 forwarded based on the route of A::B2/128. 296 +-+-+ +-+-+ +-+-+ 297 |SF1| |SF2|**** |SF3| 298 +-+-+ +-+-+ * +-+-+ 299 | A::B2 | * | 300 | +-+-+-+-+ * | 301 | +-+-+-+-+node 2 +-*-+-+-+ | 302 +-+-+-+-+ | | +-+-+-+-+ * | | +-+-+-+-+ 303 |ingress| +-+-+-+-+ A2::B2 * +-+-+-+-+ |egress | 304 | node +-+-+-+node 1 | * |node 4 +-+-+-+ node | 305 | | +-+-+-+-+ A3::B2 * +-+-+-+-+ | | 306 +-------+ A::B1 | +-+-+-+-+ * | A::B3 +-+-+-+-+ 307 A1::B1+-+-+-+-+node 3 +-*-+-+-+ A4::B3 308 +-+-^-+-+ * 309 * * 310 ******* 312 Figure 5: Illustration topology for usecase1 314 5.2. Usecase2 failover of service function 316 As illustrated in Figure 6, a SRv6-based service function chain needs 317 to go through SF1, SF2 and SF3. At the beginning, SF1, SF2 and SF3 318 are provided on node 1, node 2 and node 4. Suddenly, node 2 is down 319 and SF2 should be provided by node 3. The flow should change the 320 path. In addition to SRv6 SIDs A1::B1, A2::B2, A3::B2 and A4::B3 on 321 the four nodes, they also have Anycast SIDs instantiated locally and 322 advertised by the control plane. 324 If original SRv6 is used, the SRH is (A1::B1, A2::B2, A4::B3) before 325 failover and (A1::B1, A2::B2, A4::B3) after failover. The ingress 326 node should change the encapsulation strategies under control of the 327 controller and re-encapsulate the packets. 329 If Anycast SID is used, the SRH is (A::B1, A::B2, A::B3) before and 330 after failover. No changes to the SRH is needed. Node 2 withdraws 331 the route of A::B2 and Node 3 advertises A::B2. The FIB on node 1 is 332 updated that the packet destinated to A::B2/128 should be forwarded 333 to node 3. Then the packets are forwarded based on the route of 334 A::B2/128. 336 +-+-+ +-+-+ +-+-+ 337 |SF1| |SF2|**** |SF3| 338 +-+-+ +-+-+ * +-+-+ 339 | A::B2 | * | 340 | +-+-+-+-+ * | 341 | +-+-+-+-+node 2 +-*-+-+-+ | 342 +-+-+-+-+ | | +-+-+-+-+ * | | +-+-+-+-+ 343 |ingress| +-+-+-+-+ A2::B2 * +-+-+-+-+ |egress | 344 | node +-+-+-+node 1 | * |node 4 +-+-+-+ node | 345 | | +-+-+-+-+ A3::B2 * +-+-+-+-+ | | 346 +-------+ A::B1 | +-+-+-+-+ * | A::B3 +-+-+-+-+ 347 A1::B1+-+-+-+-+node 3 +-*-+-+-+ A4::B3 348 +-+-+-+-+ * 349 A::B2 | * 350 +-+-+ * 351 |SF2|<*** 352 +-+-+ 354 Figure 6: Illustration topology for usecase2 356 6. Security Considerations 358 TBD 360 7. IANA Considerations 362 IANA is requested to allocated one bit in SRv6 End SID sub-TLV Flags 363 to indicate that the sub-TLV carries Anycast SIDs. 365 8. References 367 8.1. Normative References 369 [I-D.draft-ietf-lsr-isis-srv6-extensions] 370 Peter, P. and C. Clarence, "IS-IS Extension to Support 371 Segment Routing over IPv6 Dataplane", 2021. 373 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 374 Requirement Levels", BCP 14, RFC 2119, 375 DOI 10.17487/RFC2119, March 1997, 376 . 378 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 379 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 380 May 2017, . 382 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 383 (IPv6) Specification", STD 86, RFC 8200, 384 DOI 10.17487/RFC8200, July 2017, 385 . 387 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 388 Decraene, B., Litkowski, S., and R. Shakir, "Segment 389 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 390 July 2018, . 392 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 393 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 394 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 395 . 397 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 398 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 399 (SRv6) Network Programming", RFC 8986, 400 DOI 10.17487/RFC8986, February 2021, 401 . 403 8.2. Informative References 405 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 406 (IPv6) Addressing Architecture", RFC 3513, 407 DOI 10.17487/RFC3513, April 2003, 408 . 410 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 411 Chaining (SFC) Architecture", RFC 7665, 412 DOI 10.17487/RFC7665, October 2015, 413 . 415 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 416 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 417 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 418 March 2016, . 420 Authors' Addresses 422 Taixin Li 423 CNIC, CAS 424 No. 4 Zhongguancun South 4th Street 425 Beijing 100190 426 China 428 Email: txli@cnic.cn 430 Xu Zhou 431 CNIC, CAS 432 No. 4 Zhongguancun South 4th Street 433 Beijing 100190 434 China 436 Email: zhouxu@cnic.cn 438 Zhe Chen 439 Huawei Technologies 440 No. 156 Beiqing Rd 441 Beijing 100095 442 China 444 Email: chenzhe17@huawei.com 446 Yihao Jia 447 Huawei Technologies 448 No. 156 Beiqing Rd 449 Beijing 100095 450 China 452 Email: jiayihao@huawei.com