idnits 2.17.1 draft-li-spring-anycast-sid-service-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 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 1441 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 376, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 391, 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-01 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 A::/64 is allocated and shared by node 1 to node 4. 179 4. Control Plane 181 The reachability of Anycast SIDs are advertised by control plane. As 182 described in [I-D.draft-ietf-lsr-isis-srv6-extensions], a new flag in 183 "Bit Values for Prefix Attribute Flags Sub-TLV" registry [RFC7794] is 184 defined to advertise the anycast property. SRv6 Locator TLV is 185 introduced to advertise Locators and End SIDs associated with each 186 locator. This TLV shares the sub-TLV space defined for TLVs 135, 236 187 and 237. 189 This document adopts the Anycast Flag (A-flag). In addition, this 190 document defines a new flag in SRv6 End SID sub-TLV. The format is 191 as follows: 193 0 1 2 3 194 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 195 +---------------+---------------+ 196 | Type | Length | 197 +---------------+---------------+---------------+ 198 | Flags | Endpoint Behavior | 199 +---------------+-------------------------------+---------------+ 200 | Anycast SID (128 bits) . . . | 201 +---------------------------------------------------------------+ 202 | Anycast SID (cont . . .) | 203 +---------------------------------------------------------------+ 204 | Anycast SID (cont . . .) | 205 +---------------------------------------------------------------+ 206 | Anycast SID (cont . . .) | 207 +---------------+-----------------------------------------------+ 208 |Sub-sub-tlv-len| sub-sub-TLVs(variable). . . | 209 +---------------+-----------------------------------------------+ 211 Type: 5 (defined in [I-D.draft-ietf-lsr-isis-srv6-extensions]). 213 Length: Variable. 215 Flags: 8 bits. 217 0 1 2 3 4 5 6 7 218 +---------------+ 219 |A|U|U|U|U|U|U|U| 220 +---------------+ 222 U: Unused and for future use. Must be 0 on transmission and ignored 223 on receipt. 225 A: Anycast flag, set when the SRv6 End SID sub-TLV carries the 226 Anycast SIDs. 228 Endpoint Behavior: 16 bits, code point that identifies the service 229 functions. 231 Anycast SID: 128 bits. 233 Sub-sub-TLV-length: defined in 234 [I-D.draft-ietf-lsr-isis-srv6-extensions]. 236 Sub-sub-TLVs: defined in [I-D.draft-ietf-lsr-isis-srv6-extensions]. 238 The Anycast SID MUST be a subnet of the associated Locator. Anycast 239 SIDs which are NOT a subnet of the associated locator MUST be 240 ignored. 242 Multiple Anycast SIDs MAY be associated with the same locator when a 243 execution endpoint holds multiple service functions. In cases where 244 the number of SRv6 End SID sub-TLVs exceeds the capacity of a single 245 TLV, multiple Locator TLVs for the same locator MAY be advertised. 246 Other details are defined in 247 [I-D.draft-ietf-lsr-isis-srv6-extensions]. 249 5. Data Plane 251 This document requires no data plane extensions to SRv6 and the 252 Anycast SID has no differences with other SIDs. Anycast SIDs stay 253 together with other SIDs in the SRH and the SID list can not only 254 steer the packet along a TE path but also specifies the service 255 functions that should process the packet. 257 The Anycast SIDs are advertised by control plane and instantiated in 258 the local FIB.When a SRv6-capable node receives an IPv6 packet, it 259 performs a long-prefix-match lookup on the packets destination 260 address. This lookup may return a FIB entry that represents a 261 locally instantiated SID. If this matched SID is Anycast SID, the 262 node should process the packet with the service function identified 263 by the Anycast SID. 265 6. Illustration 267 6.1. Usecase1 migration of service function 269 As illustrated in Figure 3, a SRv6-based service function chain needs 270 to go through SF1, SF2 and SF3. At the beginning, SF1, SF2 and SF3 271 are provided on node 1, node 2 and node 4. Then, SF2 is migrated to 272 node 3 and the flow should change the path. In addition to SRv6 SIDs 273 A1::B1, A2::B2, A3::B2 and A4::B3 on the four nodes, they also have 274 Anycast SIDs instantiated locally and advertised by the control 275 plane. 277 If original SRv6 is used, the SRH is (A1::B1, A2::B2, A4::B3) before 278 the migration and (A1::B1, A2::B2, A4::B3) after the migration. The 279 ingress node should change the encapsulation strategies under control 280 of the controller and re-encapsulate the packets. 282 If Anycast SID is used, the SRH is (A::B1, A::B2, A::B3) before and 283 after migration. No changes to the SRH is needed. Node 2 withdraws 284 the route of A::B2 and Node 3 advertises A::B2. Then the packets are 285 forwarded based on the route of A::B2/128. 287 +---+ +---+ +---+ 288 |SF1| |SF2|***** |SF3| 289 +-+-+ +-+-+ * +-+-+ 290 | A::B2 | * | 291 | +--+---+ * | 292 | +-------+node 2+--*----+ | 293 +-------+ | | +------+ * | | +------+ 294 |ingress| +-+-+--+ A2::B2 * +--+-+-+ |egress| 295 | node +-----+node 1| * |node 4+------+ node | 296 | | +---+--+ A3::B2 * +--+---+ | | 297 +-------+ A::B1 | +------+ * | A::B3 +------+ 298 A1::B1+-------+node 3+--*----+ A4::B3 299 +---^--+ * 300 * * 301 ******* 303 Figure 3: Illustration topology for usecase1 305 6.2. Usecase2 failover of service function 307 As illustrated in Figure 4, a SRv6-based service function chain needs 308 to go through SF1, SF2 and SF3. At the beginning, SF1, SF2 and SF3 309 are provided on node 1, node 2 and node 4. Suddenly, node 2 is down 310 and SF2 should be provided by node 3. The flow should change the 311 path. In addition to SRv6 SIDs A1::B1, A2::B2, A3::B2 and A4::B3 on 312 the four nodes, they also have Anycast SIDs instantiated locally and 313 advertised by the control plane. 315 If original SRv6 is used, the SRH is (A1::B1, A2::B2, A4::B3) before 316 failover and (A1::B1, A2::B2, A4::B3) after failover. The ingress 317 node should change the encapsulation strategies under control of the 318 controller and re-encapsulate the packets. 320 If Anycast SID is used, the SRH is (A::B1, A::B2, A::B3) before and 321 after failover. No changes to the SRH is needed. Node 2 withdraws 322 the route of A::B2 and Node 3 advertises A::B2. The FIB on node 1 is 323 updated that the packet destinated to A::B2/128 should be forwarded 324 to node 3. Then the packets are forwarded based on the route of 325 A::B2/128. 327 +---+ +---+ +---+ 328 |SF1| |SF2|***** |SF3| 329 +-+-+ +-+-+ * +-+-+ 330 | A::B2 | * | 331 | +--+---+ * | 332 | +-------+node 2+--*----+ | 333 +-------+ | | +------+ * | | +------+ 334 |ingress| +-+-+--+ A2::B2 * +--+-+-+ |egress| 335 | node +-----+node 1| * |node 4+------+ node | 336 | | +---+--+ A3::B2 * +--+---+ | | 337 +-------+ A::B1 | +------+ * | A::B3 +------+ 338 A1::B1+-------+node 3+--*----+ A4::B3 339 +--+---+ * 340 A::B2 | * 341 +-+-+ * 342 |SF2|<**** 343 +---+ 345 Figure 4: Illustration topology for usecase2 347 7. Security Considerations 349 TBD. 351 8. IANA Considerations 353 IANA is requested to allocated one bit in SRv6 End SID sub-TLV Flags 354 to indicate that the sub-TLV carries Anycast SIDs. 356 9. Acknowledgements 358 TBD. 360 10. References 362 10.1. Normative References 364 [I-D.draft-ietf-lsr-isis-srv6-extensions] 365 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 366 Z. Hu, "IS-IS Extension to Support Segment Routing over 367 IPv6 Dataplane", draft-ietf-lsr-isis-SRv6-extension-07 368 (work in prograss) , March 2020. 370 [I-D.draft-ietf-spring-srv6-network-programming] 371 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 372 Matsushima, S., and Z. Li, "SRv6 Network Programming", 373 draft-ietf-spring-srv6-network-programming-15 (work in 374 prograss) , March 2020. 376 [I-D.draft-li-spring-compressed-srv6-np] 377 Li, Z., Li, C., Xie, C., LEE, K., Tian, H., Zhao, F., 378 Guichard, J., Li, C., and S. Peng, "Compressed SRv6 379 Network Programming", draft-li-spring-compressed- 380 SRv6-np-02 (work in prograss) , February 2020. 382 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 383 Requirement Levels", BCP 14, RFC 2119, 384 DOI 10.17487/RFC2119, March 1997, 385 . 387 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 388 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 389 May 2017, . 391 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 392 (IPv6) Spectification", RFC 8200 , July 2017. 394 [RFC8402] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 395 Litkowski, S., and R. Shakir, "Segment Routing 396 Architecture", RFC 8402 , July 2018. 398 [RFC8754] Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 399 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 400 (SRH)", RFC 8754 , March 2020. 402 10.2. Informative References 404 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 405 (IPv6) Addressing Architecture", RFC 3513 , April 2003. 407 [RFC7665] Halpern, J. and C. Pignataro, "Service Function Chaining 408 (SFC) Architecture", RFC 7665 , October 2015. 410 [RFC7794] Ginsberg, L., Decraene, B., Previdi, S., Xu, X., and U. 411 Chunduri, "IS-IS Prefix Attributes for Extended IPv4 and 412 IPv6 Reachability", RFC 7794 , March 2016. 414 Authors' Addresses 416 Taixin Li 417 Huawei Technologies 418 No. 156 Beiqing Rd 419 Beijing 100095 420 China 422 Email: litaixin@huawei.com 423 Zhe Chen 424 Huawei Technologies 425 No. 156 Beiqing Rd 426 Beijing 100095 427 China 429 Email: chenzhe17@huawei.com