idnits 2.17.1 draft-li-spring-anycast-sid-service-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 : ---------------------------------------------------------------------------- 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 (May 15, 2020) is 1443 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: 'I-D.draft-li-spring-compressed-srv6-np' is defined on line 378, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 393, but no explicit reference was found in the text -- No information found for draft-ietf-lsr-isis-SRv6-extension - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.draft-ietf-lsr-isis-srv6-extensions' == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-15 -- No information found for draft-li-spring-compressed-SRv6-np - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.draft-li-spring-compressed-srv6-np' -- Obsolete informational reference (is this intentional?): RFC 3513 (Obsoleted by RFC 4291) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Li 3 Internet-Draft Z. Chen 4 Intended status: Standards Track Huawei Technologies 5 Expires: November 16, 2020 May 15, 2020 7 Anycast SID for Flexible and Robust Service in SRv6 8 draft-li-spring-anycast-sid-service-00 10 Abstract 12 Segment Routing enables an operator or an application to specify a 13 packet processing program. When Segment Routing is applied to IPv6 14 data plane, the list of IPv6 SIDs in SRH can specify a series of 15 execution endpoints that hold service functions that process the 16 packet. However, steering traffic dynamically to the different 17 execution endpoints requires a specific "re-encapsulating". This 18 procedure may be complex and take time. 20 This document proposes A-SID (Anycast-SID) based on SRv6 to achieve 21 flexible and robust service provision. It uses anycast SID to 22 identify service functions and locates the service functions based on 23 anycast routing. The proposed solution can stay compatibility with 24 the existing SRv6. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED","MAY", and 30 "OPTIONAL" in this document are to be interpreted as described in BCP 31 14 [RFC2119] [RFC8174] when, and only when, they appear in all 32 capitals, as shown here. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on November 16, 2020. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Anycast SID (A-SID) . . . . . . . . . . . . . . . . . . . . . 3 70 4. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 4 71 5. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 6. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 6 73 6.1. Usecase1 migration of service function . . . . . . . . . 6 74 6.2. Usecase2 failover of service function . . . . . . . . . . 7 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 77 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 80 10.2. Informative References . . . . . . . . . . . . . . . . . 9 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 83 1. Introduction 85 Segment Routing [RFC8402] enables an operator or an application to 86 specify a packet processing program. SRv6 applies Segment Routing to 87 IPv6 data plane. A new routing header for IPv6, which is called 88 Segment Routing Header (SRH) [RFC8754] is defined to carry 128-bit 89 SIDs. The list of IPv6 SIDs in SRH can specify not only a TE path, 90 but also a series of execution endpoints that hold service functions 91 that process the packet. In this way, a service function chain 92 [RFC7665] is formed based on SRv6. 94 However, more and more functions, such as firewall and DPI, are 95 deployed in cloud technology and Network Function Virtualization, 96 which means that a single function may be deployed on multiple 97 execution locations and the function may be migrated to different 98 locations frequently. Steering traffic dynamically to the different 99 execution endpoints requires a specific "re-encapsulating" frequently 100 at the ingress router. This procedure may be complex and take time. 102 This document proposes A-SID (Anycast-SID) based on SRv6 to achieve 103 flexible and robust service provision. In addition to the SIDs that 104 are used for TE path on the node, specific A-SIDs are used for 105 service function chain. The execution endpoints share a SID Locator 106 and the kind of functions is identified by Function and Argument. 107 The A-SIDs are advertised by the control plane and the packets are 108 forwarded to the execution endpoints based on anycast routing. The 109 proposed solution can stay compatibility with the existing SRv6. 111 2. Terminology 113 The definitions of the SRv6 terms, such as SRv6, SID, SRH, locator 114 and function can be found in [RFC8754], [RFC8402], and 115 [I-D.draft-ietf-spring-srv6-network-programming]. The definition of 116 Service Function Chain can be found in [RFC7665]. The definition of 117 anycast can be found in [RFC3513]. 119 This document introduces the following new terms: 121 A-SID: Anycast-based Segment Identifier. 123 3. Anycast SID (A-SID) 125 The SRv6 SID contains 16 bytes and can be separated into three parts: 126 locator, function, and argument. As for the argument, we consider it 127 as the accessory of function. So this document omits argument for a 128 clear description and the SRv6 SID can be mainly separated into two 129 parts: locator and function. 131 All of the SRv6 endpoints have their own SIDs instantiated in the FIB 132 table locally and advertised by the control plane as defined in 133 [I-D.draft-ietf-spring-srv6-network-programming]. In addition to the 134 existing SRv6 SIDs, the execution endpoints that hold service 135 functions also have Anycast SIDs. The Locator of Anycast SID is 136 shared by all the execution endpoints in the SR domain. In other 137 words, one specific Locator is allocated to the execution endpoints 138 to identify the Anycast SIDs. The Function of Anycast SID identifies 139 the kind of service functions that the endpoint node can provide. 140 That is, if two execution endpoints provide the same kind of service 141 functions, they will have the same Anycast SID. 143 0 16 bytes 144 +----------------------+--------------------+ 145 | Locator | Function | 146 +-------------------------------------------+ 147 |<---Shared locator--->| | 148 |<---------------Anycast SID--------------->| 150 Figure 1: Anycast SID 152 For example, the shared Locator is A::/64, Service Functions (SFs)1 - 153 3 are identified by B1 - B3. Node 1 provides SF1, node 2 and node 3 154 provide SF2, and node 4 provides SF3. The Anycast SIDs are shown in 155 Figure 2. 157 +---+ +---+ +---+ 158 |SF1| |SF2| |SF3| 159 +-+-+ +-+-+ +-+-+ 160 | | A::B2 | 161 | +--+---+ | 162 | +-------+node 2+-------+ | 163 +-------+ | | +------+ | | +------+ 164 |ingress| +-+-+--+ +--+-+-+ |egress| 165 | node +-----+node 1| |node 4+------+ node | 166 | | +---+--+ +--+---+ | | 167 +-------+ A::B1 | +------+ | A::B3 +------+ 168 +-------+node 3+-------+ 169 +--+---+ 170 | A::B2 171 +-+-+ 172 |SF2| 173 +---+ 175 Figure 2: the Anycast SIDs 177 For example, the common prefix is A::/48, the SNID is a 16 bits 178 value, and the SFID is a 8 bits value. Then the SSID, which is 179 carried in the SRH, is 24 bits. 181 4. Control Plane 183 The reachability of Anycast SIDs are advertised by control plane. As 184 described in [I-D.draft-ietf-lsr-isis-srv6-extensions], a new flag in 185 "Bit Values for Prefix Attribute Flags Sub-TLV" registry [RFC7794] is 186 defined to advertise the anycast property. SRv6 Locator TLV is 187 introduced to advertise Locators and End SIDs associated with each 188 locator. This TLV shares the sub-TLV space defined for TLVs 135, 236 189 and 237. 191 This document adopts the Anycast Flag (A-flag). In addition, this 192 document defines a new flag in SRv6 End SID sub-TLV. The format is 193 as follows: 195 0 1 2 3 196 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 197 +---------------+---------------+ 198 | Type | Length | 199 +---------------+---------------+---------------+ 200 | Flags | Endpoint Behavior | 201 +---------------+-------------------------------+---------------+ 202 | Anycast SID (128 bits) . . . | 203 +---------------------------------------------------------------+ 204 | Anycast SID (cont . . .) | 205 +---------------------------------------------------------------+ 206 | Anycast SID (cont . . .) | 207 +---------------------------------------------------------------+ 208 | Anycast SID (cont . . .) | 209 +---------------+-----------------------------------------------+ 210 |Sub-sub-tlv-len| sub-sub-TLVs(variable). . . | 211 +---------------+-----------------------------------------------+ 213 Type: 5 (defined in [I-D.draft-ietf-lsr-isis-srv6-extensions]). 215 Length: Variable. 217 Flags: 8 bits. 219 0 1 2 3 4 5 6 7 220 +---------------+ 221 |A|U|U|U|U|U|U|U| 222 +---------------+ 224 U: Unused and for future use. Must be 0 on transmission and ignored 225 on receipt. 227 A: Anycast flag, set when the SRv6 End SID sub-TLV carries the 228 Anycast SIDs. 230 Endpoint Behavior: 16 bits, code point that identifies the service 231 functions. 233 Anycast SID: 128 bits. 235 Sub-sub-TLV-length: defined in 236 [I-D.draft-ietf-lsr-isis-srv6-extensions]. 238 Sub-sub-TLVs: defined in [I-D.draft-ietf-lsr-isis-srv6-extensions]. 240 The Anycast SID MUST be a subnet of the associated Locator. Anycast 241 SIDs which are NOT a subnet of the associated locator MUST be 242 ignored. 244 Multiple Anycast SIDs MAY be associated with the same locator when a 245 execution endpoint holds multiple service functions. In cases where 246 the number of SRv6 End SID sub-TLVs exceeds the capacity of a single 247 TLV, multiple Locator TLVs for the same locator MAY be advertised. 248 Other details are defined in 249 [I-D.draft-ietf-lsr-isis-srv6-extensions]. 251 5. Data Plane 253 This document requires no data plane extensions to SRv6 and the 254 Anycast SID has no differences with other SIDs. Anycast SIDs stay 255 together with other SIDs in the SRH and the SID list can not only 256 steer the packet along a TE path but also specifies the service 257 functions that should process the packet. 259 The Anycast SIDs are advertised by control plane and instantiated in 260 the local FIB.When a SRv6-capable node receives an IPv6 packet, it 261 performs a long-prefix-match lookup on the packets destination 262 address. This lookup may return a FIB entry that represents a 263 locally instantiated SID. If this matched SID is Anycast SID, the 264 node should process the packet with the service function identified 265 by the Anycast SID. 267 6. Illustration 269 6.1. Usecase1 migration of service function 271 As illustrated in Figure 3, a SRv6-based service function chain needs 272 to go through SF1, SF2 and SF3. At the beginning, SF1, SF2 and SF3 273 are provided on node 1, node 2 and node 4. Then, SF2 is migrated to 274 node 3 and the flow should change the path. In addition to SRv6 SIDs 275 A1::B1, A2::B2, A3::B2 and A4::B3 on the four nodes, they also have 276 Anycast SIDs instantiated locally and advertised by the control 277 plane. 279 If original SRv6 is used, the SRH is (A1::B1, A2::B2, A4::B3) before 280 the migration and (A1::B1, A2::B2, A4::B3) after the migration. The 281 ingress node should change the encapsulation strategies under control 282 of the controller and re-encapsulate the packets. 284 If Anycast SID is used, the SRH is (A::B1, A::B2, A::B3) before and 285 after migration. No changes to the SRH is needed. Node 2 withdraws 286 the route of A::B2 and Node 3 advertises A::B2. Then the packets are 287 forwarded based on the route of A::B2/128. 289 +---+ +---+ +---+ 290 |SF1| |SF2|***** |SF3| 291 +-+-+ +-+-+ * +-+-+ 292 | A::B2 | * | 293 | +--+---+ * | 294 | +-------+node 2+--*----+ | 295 +-------+ | | +------+ * | | +------+ 296 |ingress| +-+-+--+ A2::B2 * +--+-+-+ |egress| 297 | node +-----+node 1| * |node 4+------+ node | 298 | | +---+--+ A3::B2 * +--+---+ | | 299 +-------+ A::B1 | +------+ * | A::B3 +------+ 300 A1::B1+-------+node 3+--*----+ A4::B3 301 +---^--+ * 302 * * 303 ******* 305 Figure 3: Illustration topology for usecase1 307 6.2. Usecase2 failover of service function 309 As illustrated in Figure 4, a SRv6-based service function chain needs 310 to go through SF1, SF2 and SF3. At the beginning, SF1, SF2 and SF3 311 are provided on node 1, node 2 and node 4. Suddenly, node 2 is down 312 and SF2 should be provided by node 3. The flow should change the 313 path. In addition to SRv6 SIDs A1::B1, A2::B2, A3::B2 and A4::B3 on 314 the four nodes, they also have Anycast SIDs instantiated locally and 315 advertised by the control plane. 317 If original SRv6 is used, the SRH is (A1::B1, A2::B2, A4::B3) before 318 failover and (A1::B1, A2::B2, A4::B3) after failover. The ingress 319 node should change the encapsulation strategies under control of the 320 controller and re-encapsulate the packets. 322 If Anycast SID is used, the SRH is (A::B1, A::B2, A::B3) before and 323 after failover. No changes to the SRH is needed. Node 2 withdraws 324 the route of A::B2 and Node 3 advertises A::B2. The FIB on node 1 is 325 updated that the packet destinated to A::B2/128 should be forwarded 326 to node 3. Then the packets are forwarded based on the route of 327 A::B2/128. 329 +---+ +---+ +---+ 330 |SF1| |SF2|***** |SF3| 331 +-+-+ +-+-+ * +-+-+ 332 | A::B2 | * | 333 | +--+---+ * | 334 | +-------+node 2+--*----+ | 335 +-------+ | | +------+ * | | +------+ 336 |ingress| +-+-+--+ A2::B2 * +--+-+-+ |egress| 337 | node +-----+node 1| * |node 4+------+ node | 338 | | +---+--+ A3::B2 * +--+---+ | | 339 +-------+ A::B1 | +------+ * | A::B3 +------+ 340 A1::B1+-------+node 3+--*----+ A4::B3 341 +--+---+ * 342 A::B2 | * 343 +-+-+ * 344 |SF2|<**** 345 +---+ 347 Figure 4: Illustration topology for usecase2 349 7. Security Considerations 351 TBD. 353 8. IANA Considerations 355 IANA is requested to allocated one bit in SRv6 End SID sub-TLV Flags 356 to indicate that the sub-TLV carries Anycast SIDs. 358 9. Acknowledgements 360 TBD. 362 10. References 364 10.1. Normative References 366 [I-D.draft-ietf-lsr-isis-srv6-extensions] 367 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 368 Z. Hu, "IS-IS Extension to Support Segment Routing over 369 IPv6 Dataplane", draft-ietf-lsr-isis-SRv6-extension-07 370 (work in prograss) , March 2020. 372 [I-D.draft-ietf-spring-srv6-network-programming] 373 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 374 Matsushima, S., and Z. Li, "SRv6 Network Programming", 375 draft-ietf-spring-srv6-network-programming-15 (work in 376 prograss) , March 2020. 378 [I-D.draft-li-spring-compressed-srv6-np] 379 Li, Z., Li, C., Xie, C., LEE, K., Tian, H., Zhao, F., 380 Guichard, J., Li, C., and S. Peng, "Compressed SRv6 381 Network Programming", draft-li-spring-compressed- 382 SRv6-np-02 (work in prograss) , February 2020. 384 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 385 Requirement Levels", BCP 14, RFC 2119, 386 DOI 10.17487/RFC2119, March 1997, 387 . 389 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 390 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 391 May 2017, . 393 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 394 (IPv6) Spectification", RFC 8200 , July 2017. 396 [RFC8402] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 397 Litkowski, S., and R. Shakir, "Segment Routing 398 Architecture", RFC 8402 , July 2018. 400 [RFC8754] Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 401 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 402 (SRH)", RFC 8754 , March 2020. 404 10.2. Informative References 406 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 407 (IPv6) Addressing Architecture", RFC 3513 , April 2003. 409 [RFC7665] Halpern, J. and C. Pignataro, "Service Function Chaining 410 (SFC) Architecture", RFC 7665 , October 2015. 412 [RFC7794] Ginsberg, L., Decraene, B., Previdi, S., Xu, X., and U. 413 Chunduri, "IS-IS Prefix Attributes for Extended IPv4 and 414 IPv6 Reachability", RFC 7794 , March 2016. 416 Authors' Addresses 418 Taixin Li 419 Huawei Technologies 420 No. 156 Beiqing Rd 421 Beijing 100095 422 China 424 Email: litaixin@huawei.com 425 Zhe Chen 426 Huawei Technologies 427 No. 156 Beiqing Rd 428 Beijing 100095 429 China 431 Email: chenzhe17@huawei.com