idnits 2.17.1 draft-peng-spring-srv6-compatibility-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 : ---------------------------------------------------------------------------- ** There are 17 instances of too long lines in the document, the longest one being 22 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 8, 2019) is 1754 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-21 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-06 == Outdated reference: A later version (-13) exists of draft-ietf-pce-pcep-flowspec-03 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group S. Peng 3 Internet-Draft Z. Li 4 Intended status: Informational Huawei Technologies 5 Expires: January 9, 2020 C. Xie 6 C. Li 7 China Telecom 8 July 8, 2019 10 SRv6 Compatibility with Legacy Devices 11 draft-peng-spring-srv6-compatibility-01 13 Abstract 15 When deploying SRv6 on legacy devices, there are some compatibility 16 challenges such as the support of SRH processing. 18 This document identifies some of the major challenges, and provides 19 solutions that are able to mitigate those challenges and smooth the 20 migration towards SRv6 deployment. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 9, 2020. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Compatibility challenges . . . . . . . . . . . . . . . . . . 3 64 2.1. Fast Reroute (FRR) . . . . . . . . . . . . . . . . . . . 3 65 2.2. Traffic Engineering (TE) . . . . . . . . . . . . . . . . 4 66 2.3. Service Function Chaining (SFC) . . . . . . . . . . . . . 4 67 2.4. IOAM . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.1. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1.1. Binding SID (BSID) . . . . . . . . . . . . . . . . . 6 71 3.1.2. PCEP FlowSpec . . . . . . . . . . . . . . . . . . . . 6 72 3.2. SFC . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 3.2.1. Stateless SFC . . . . . . . . . . . . . . . . . . . . 6 74 3.2.2. Stateful SFC . . . . . . . . . . . . . . . . . . . . 7 75 3.3. Light Weight IOAM . . . . . . . . . . . . . . . . . . . . 7 76 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 80 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 83 1. Introduction 85 Segment Routing (SR) is a source routing paradigm, which allows a 86 headend node to steer the packets through an ordered list of 87 instructions, i.e. segments [RFC8402]. A segment can either be 88 topological or service based. SR over IPv6 (SRv6) 89 [I-D.filsfils-spring-srv6-network-programming] is the SR instantiated 90 on the IPv6 data plane with a new type of routing extension header, 91 i.e. SR Header (SRH) [I-D.ietf-6man-segment-routing-header]. An SRv6 92 segment, also called SRv6 SID, is a 128-bit value, represented as 93 LOC:FUNCT:ARGS (ARGS is optional), and encoded as an IPv6 address. 94 An ordered list of SRv6 SIDs forms an SR Policy, which can be used 95 for, for example, Traffic Engineering (TE), Service Function Chaining 96 (SFC), and In-situ Operations, Administration, and Maintenance 97 (IOAM). Meanwhile, it will also bring challenges on the legacy 98 devices to support SRv6 correspondingly. 100 This document provides solutions that can mitigate the identified 101 compatibility challenges and ease the evolution towards SRv6 102 deployment. 104 2. Compatibility challenges 106 By adopting SR Policy, the states in the network can be greatly 107 reduced, which will relieve the devices and evolve into stateless 108 fabric ultimately. However, it will also bring compatibility 109 challenges on the legacy devices correspondingly. In particular, the 110 legacy devices need to upgrade in order to support the processing of 111 SRH. 113 Furthermore, as the segments in the segment list increase the SR 114 Policy incrementally expends, the encapsulation header overhead 115 increases, which will also impose high requirements on the 116 performance of hardware forwarding (i.e. the capability of chipset). 118 This section identifies the imposed challenges in the following 119 SPRING use cases. 121 2.1. Fast Reroute (FRR) 123 FRR is deployed to cope with link or node failures by precomputing 124 backup paths. By relying on SR, Topology Independent Loop-free 125 Alternate Fast Re-route (TI-LFA) 126 [I-D.bashandy-rtgwg-segment-routing-ti-lfa] provides a local repair 127 mechnism with the ability to activate the data plane switch-over onto 128 a loop free backup path irrespective of topologies prior and after 129 the sudden failure. 131 Using SR, there is no need to create state in the network in order to 132 enforce FRR behavior. Correspondingly, the Point of Local Repair, 133 i.e. the protecting router, needs to insert a repair list at the head 134 of the segment list in the SR header, encoding the explicit post- 135 convergence path to the destination. This action will increase the 136 length of the segment list in the SRH as shown in Figure 1. 138 2.2. Traffic Engineering (TE) 140 TE enables operators to control specific traffic flows going through 141 configured explicit paths. There are loose and strict options. With 142 the loose option, only a small number of hops along the paths are 143 explicitly expressed, while the strict option specifies each 144 individual hop in the explicit path, e.g. to encode a low-latency 145 path from node A to node B. 147 With SRv6, the strict source-routed explicit paths will result in a 148 long segment list in the SRH as shown in Figure 1, which places high 149 requirements on the devices. 151 2.3. Service Function Chaining (SFC) 153 The SR segments can also encode instructions, called service 154 segments, for steering packets through services running on physical 155 service appliances or virtual network functions (VNF) running in a 156 virtual enviornment [I-D.xuclad-spring-sr-service-programming]. 157 These service segments can also be integrated in an SR policy along 158 with node and adjacency segments. This feature of SR will further 159 increase the length of the segment list in the SRH as shown in 160 Figure 1. 162 In terms of SR awareness, there are two types of services, i.e. SR- 163 aware and SR-unaware services, which both impose new requirements on 164 the hardware. The SR-aware service needs to be fully capable of 165 processing SR traffic, while for the SR-unaware services, an SR proxy 166 function needs to be defined. 168 If the Network Service Header (NSH) based SFC [RFC8300] has already 169 been deployed in the network, the compatibility with existing NSH is 170 required. 172 2.4. IOAM 174 IOAM, i.e. "in-situ" Operations, Administration, and Maintenance 175 (OAM), encodes telemetry and operational information within the data 176 packets to complement other "out-of-band" OAM mechnisms, e.g. ICMP 177 and active probing. The IOAM data fields, i.e. a node data list, 178 hold the information collected as the packets traversing the IOAM 179 domain [I-D.ietf-ippm-ioam-data], which is populated iteratively 180 starting with the last entry of the list. 182 The IOAM data can be embedded into a variety of transports. To 183 support the IOAM on the SRv6 data plane, the O-flag in the SRH is 184 defined [I-D.ali-spring-srv6-oam], which implements the "punt a 185 timestamped copy and forward" or "forward and punt a timestamped 186 copy" behavior. The IOAM data fields, i.e. the node data list, are 187 encapsulated in the IOAM TLV in SRH, which further increases the 188 length of the SRH as shown in Figure 1. 190 +-----------+ 191 |IPv6 packet| 192 +-----------+ 193 / / 194 +-----------+ / IOAM Info / 195 |IPv6 packet| / / 196 +-----------+ +-----------+ +-----------+ 197 |IPv6 packet| / / / / 198 +-----------+ +-----------+ / / / / 199 |IPv6 packet| / / / SF Chain / / SF Chain / 200 +-----------+ +-----------+ / TE Path / / / / / 201 |IPv6 packet| /TI-LFA Path/ / / / / / / 202 +-----------+ +-----------+ +-----------+ +-----------+ +-----------+ 203 |SA,DA | |SA,DA | |SA,DA | |SA,DA | |SA,DA | 204 +-----------+ +-----------+ +-----------+ +-----------+ +-----------+ 205 SRv6 BE SRv6 BE+ SRv6 TE SRv6 SFC SRv6 SFC+ 206 TI-LFA IOAM 208 Figure 1. Evolution of SRv6 SRH 210 The compatibility challenges on the legacy devices are summarised as 211 follows, 213 o The legacy devices need to upgrade in order to support the 214 processing of SRH 216 o As the SRH expands, the overhead increases and correspondingly the 217 effective payload decreases 219 o As the SRH expands, the hardware forwarding performance reduces 220 which requires high capability of chipset 222 3. Solutions 224 This section provides solutions to mitigate the above-mentioned 225 challenges. 227 3.1. TE 229 With the strict traffic engineering, the resulted long SID list in 230 the SRH raises high requirements on the hardware chipset, which can 231 be mitigated by the following solutions. 233 3.1.1. Binding SID (BSID) 235 Binding SID involves a list of SIDs, and is bound to an SR Policy. 236 The node(s) that imposes the bound policy needs to store the SID 237 list. When a node receives a packet with its active segment as a 238 BSID, the node will steer the packet onto the bound policy 239 accordingly. 241 To reduce the long SID list of a strict TE explicit path, BSID can be 242 used at the selected nodes, maybe according to the processing 243 capacity of the hardware chipset. BSID can also be used to impose 244 the repair list in the TI-LFA as described in Section 2.1. 246 3.1.2. PCEP FlowSpec 248 When the SR architecture adopts a centralized model, the SDN 249 controller (e.g. Path Computation Element (PCE)) only needs to apply 250 the SR policy at the head-end. There is no state maintained at 251 midpoints and tail-ends. Eliminating states in the network 252 (midpoints and tail-points) is a key benefit of utilizing SR. 253 However, it also leads to a long SID list for expressing a strict TE 254 path. 256 PCEP FlowSpec [I-D.ietf-pce-pcep-flowspec] provides a trade-off 257 solution. PCEP FlowSpec is that PCEP with a set of extensions is 258 able to disseminate Flow Specifications (i.e. filters and actions) 259 to allow indicating how the classified traffic flows will be treated. 260 In an SR-enabled network, PCEP FlowSpec can be applied at the 261 midpoints to enforce traffic engineering policies where it is needed. 262 In that case, states need to be maintained at the corresponding 263 midpoints of a TE explicit path, but the SID list can be shortened. 265 3.2. SFC 267 Currently two approaches are proposed to support SFC over SRv6, i.e. 268 stateless SFC [I-D.xuclad-spring-sr-service-programming] and stateful 269 SFC [I-D.guichard-spring-nsh-sr]. 271 3.2.1. Stateless SFC 273 A service can also be assigned an SRv6 SID which is integrated into 274 an SR policy and used to steer traffic to it. In terms of the 275 capability of processing the SR information in the received packets, 276 there are two types of services, i.e. SR-aware service and SR-unware 277 service. An SR-aware service is capable of processing the SRH in the 278 received packets. While an SR-unaware service, i.e. legacy service, 279 is not able to process the SR information in the traffic it receives, 280 and may drop the received packets. In order to support such services 281 in an SRv6 domain, the SR proxy is introduced to handle the 282 processing of SRH on behalf of the SR-unware service. The service 283 SID associated with the SR-unaware service is instantiated on the SR 284 proxy, which is used to steer traffic to the service. 286 The SR proxy intercepts the SR traffic destined for the service via 287 the locally instantiated service SID, removes the SR information, and 288 sends the non-SR traffic out on a given interface to the service. 289 When receiving the traffic coming back from the service, the SR proxy 290 will restore the SR information and forwards it to the next segment 291 in the segment list. 293 3.2.2. Stateful SFC 295 The NSH and SR can actually be integrated in order to support SFC in 296 an efficient and cost-effective manner while maintaining separation 297 of the service and transport planes . 299 In this NSH-SR integration solution, NSH and SR work jointly and 300 complement each other. Specifically, SR is responsible for steering 301 packets along a given Service Function Path (SFP) while NSH is for 302 maintaining the SFC instance context, i.e. Service Path Identifier 303 (SPI), Service Index (SI), and any associated metadata. 305 When a service chain is established, a packet associated with that 306 chain will be first encapsulated with an NSH and then an SRH, and 307 forwarded in the SR domain. When the packet arrives at an SFF and 308 needs to be forwarded to an SF, the SFF performs a lookup based on 309 the service SID associated with the SF to retrieve the next-hop 310 context (a MAC address) between the SFF and SF. Then the SFF strips 311 the SRH and forwards the packet with NSH carrying metadata to the SF 312 where the packet will be processed as specified in [RFC8300]. In 313 this case, the SF is not required to be capable of the SR operation, 314 neither is the SR proxy. Meanwhile, the stripped SRH will be updated 315 and stored in a cache in the SFF, indexed by the NSH SPI for the 316 forwarding of the packet coming back from the SF. 318 3.3. Light Weight IOAM 320 In most cases, after the IPv6 Destination Address (DA) is updated 321 according to the active segment in the SRH, the SID in the SRH will 322 not be used again. However, the entire SID list in the SRH will 323 still be carried in the packet along the path till a PSP/USP is 324 enforced. 326 The light weight IOAM method [I-D.li-spring-passive-pm-for-srv6-np] 327 makes use of the used segments in the SRH to carry the IOAM 328 information, which saves the extra space in the SRH and mitigate the 329 requirements on the hardware. 331 4. Summary 333 The SRH enables a great number of features for SRv6 and opens new 334 network programming possibilities. By using SRH, it relieves the 335 network devices from states, evolving towards stateless fabric, while 336 the complexity in the control plane increases. The corresponding 337 challenges imposed on the hardware chipset become high as the SRH 338 expands when supporting the diverse use cases. The trade-off 339 solutions presented in this document are able to mitigate these 340 challenges and smooth the evolution in operators' networks. 342 5. IANA Considerations 344 There are no IANA considerations in this document. 346 Note to RFC Editor: this section may be removed on publication as an 347 RFC. 349 6. Security Considerations 351 TBD 353 7. Acknowledgements 355 TBD 357 8. Normative References 359 [I-D.ali-spring-srv6-oam] 360 Ali, Z., Filsfils, C., Kumar, N., Pignataro, C., 361 faiqbal@cisco.com, f., Gandhi, R., Leddy, J., Matsushima, 362 S., Raszuk, R., daniel.voyer@bell.ca, d., Dawra, G., 363 Peirens, B., Chen, M., and G. Naik, "Operations, 364 Administration, and Maintenance (OAM) in Segment Routing 365 Networks with IPv6 Data plane (SRv6)", draft-ali-spring- 366 srv6-oam-02 (work in progress), October 2018. 368 [I-D.bashandy-rtgwg-segment-routing-ti-lfa] 369 Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S., 370 Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P. 371 Camarillo, "Topology Independent Fast Reroute using 372 Segment Routing", draft-bashandy-rtgwg-segment-routing-ti- 373 lfa-05 (work in progress), October 2018. 375 [I-D.filsfils-spring-srv6-network-programming] 376 Filsfils, C., Camarillo, P., Leddy, J., 377 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 378 Network Programming", draft-filsfils-spring-srv6-network- 379 programming-07 (work in progress), February 2019. 381 [I-D.guichard-spring-nsh-sr] 382 Guichard, J., Song, H., Tantsura, J., Halpern, J., 383 Henderickx, W., Boucadair, M., and S. Hassan, "NSH and 384 Segment Routing Integration for Service Function Chaining 385 (SFC)", draft-guichard-spring-nsh-sr-01 (work in 386 progress), March 2019. 388 [I-D.ietf-6man-segment-routing-header] 389 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 390 Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment 391 Routing Header (SRH)", draft-ietf-6man-segment-routing- 392 header-21 (work in progress), June 2019. 394 [I-D.ietf-ippm-ioam-data] 395 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 396 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 397 P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, 398 "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- 399 data-06 (work in progress), July 2019. 401 [I-D.ietf-pce-pcep-flowspec] 402 Dhody, D., Farrel, A., and Z. Li, "PCEP Extension for Flow 403 Specification", draft-ietf-pce-pcep-flowspec-03 (work in 404 progress), February 2019. 406 [I-D.li-spring-passive-pm-for-srv6-np] 407 Li, C. and M. Chen, "Passive Performance Measurement for 408 SRv6 Network Programming", draft-li-spring-passive-pm-for- 409 srv6-np-00 (work in progress), March 2018. 411 [I-D.xuclad-spring-sr-service-programming] 412 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 413 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 414 Henderickx, W., and S. Salsano, "Service Programming with 415 Segment Routing", draft-xuclad-spring-sr-service- 416 programming-02 (work in progress), April 2019. 418 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 419 Requirement Levels", BCP 14, RFC 2119, 420 DOI 10.17487/RFC2119, March 1997, 421 . 423 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 424 "Network Service Header (NSH)", RFC 8300, 425 DOI 10.17487/RFC8300, January 2018, 426 . 428 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 429 Decraene, B., Litkowski, S., and R. Shakir, "Segment 430 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 431 July 2018, . 433 Authors' Addresses 435 Shuping Peng 436 Huawei Technologies 437 Huawei Bld., No.156 Beiqing Rd. 438 Beijing 100095 439 China 441 Email: pengshuping@huawei.com 443 Zhenbin Li 444 Huawei Technologies 445 Huawei Bld., No.156 Beiqing Rd. 446 Beijing 100095 447 China 449 Email: lizhenbin@huawei.com 451 Chongfeng Xie 452 China Telecom 453 China Telecom Information Science&Technology Innovation park, Beiqijia Town,Changping District 454 Beijing 102209 455 China 457 Phone: +86-10-50902116 458 Email: xiechf.bri@chinatelecom.cn 460 Cong Li 461 China Telecom 462 China Telecom Information Science&Technology Innovation park, Beiqijia Town,Changping District 463 Beijing 102209 464 China 466 Phone: +86-10-50902556 467 Email: licong.bri@chinatelecom.cn