idnits 2.17.1 draft-peng-spring-srv6-compatibility-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 : ---------------------------------------------------------------------------- ** There are 15 instances of too long lines in the document, the longest one being 1 character 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 (January 10, 2020) is 1565 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-08 == Outdated reference: A later version (-13) exists of draft-ietf-pce-pcep-flowspec-07 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-01 == Outdated reference: A later version (-15) exists of draft-ietf-spring-nsh-sr-01 == Outdated reference: A later version (-09) exists of draft-ietf-spring-sr-service-programming-01 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-07 == Outdated reference: A later version (-16) exists of draft-song-ippm-postcard-based-telemetry-06 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group H. Tian 3 Internet-Draft F. Zhao 4 Intended status: Informational CAICT 5 Expires: July 13, 2020 C. Xie 6 China Telecom 7 T. Li 8 J. Ma 9 China Unicom 10 S. Peng 11 Z. Li 12 Huawei Technologies 13 J. Guichard 14 Futurewei Technologies Ltd. 15 January 10, 2020 17 SRv6 Compatibility with Legacy Devices 18 draft-peng-spring-srv6-compatibility-02 20 Abstract 22 When deploying SRv6 on legacy devices, there are some compatibility 23 challenges that must be addressed such as the support for SRH 24 processing. 26 This document identifies some of the major challenges, and provides 27 solutions that can mitigate those challenges and smooth the migration 28 towards SRv6 deployment. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in RFC 2119 [RFC2119]. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on July 13, 2020. 53 Copyright Notice 55 Copyright (c) 2020 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Compatibility Challenges . . . . . . . . . . . . . . . . . . 3 72 2.1. Fast Reroute (FRR) . . . . . . . . . . . . . . . . . . . 3 73 2.2. Traffic Engineering (TE) . . . . . . . . . . . . . . . . 4 74 2.3. Service Function Chaining (SFC) . . . . . . . . . . . . . 4 75 2.4. IOAM . . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 3.1. Traffic Engineering . . . . . . . . . . . . . . . . . . . 6 78 3.1.1. Binding SID (BSID) . . . . . . . . . . . . . . . . . 6 79 3.1.2. PCEP FlowSpec . . . . . . . . . . . . . . . . . . . . 6 80 3.2. SFC . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 81 3.2.1. Stateless SFC . . . . . . . . . . . . . . . . . . . . 6 82 3.2.2. Stateful SFC . . . . . . . . . . . . . . . . . . . . 7 83 3.3. Light Weight IOAM . . . . . . . . . . . . . . . . . . . . 7 84 3.4. Postcard Telemetry . . . . . . . . . . . . . . . . . . . 8 85 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 86 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 88 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 89 8. Normative References . . . . . . . . . . . . . . . . . . . . 9 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 92 1. Introduction 94 Segment Routing (SR) is a source routing paradigm, which allows a 95 headend node to steer packets into an SR policy which is instantiated 96 through an ordered list of instructions, i.e. segments [RFC8402]. A 97 segment can either be topological or service based. SR over IPv6 98 (SRv6) [I-D.ietf-spring-srv6-network-programming] is the 99 instantiation of SR on the IPv6 data plane with a new type of routing 100 extension header, i.e. SR Header (SRH) 101 [I-D.ietf-6man-segment-routing-header]. An SRv6 segment, also called 102 SRv6 SID, is a 128-bit value, represented as LOC:FUNCT:ARGS (ARGS is 103 optional), and is encoded as an IPv6 address. An ordered list of 104 SRv6 SIDs forms an SR Policy, which can be used for Traffic 105 Engineering (TE), Service Function Chaining (SFC), and In-situ 106 Operations, Administration, and Maintenance (IOAM). Meanwhile, the 107 deployment of SRv6 will bring challenges for legacy devices that do 108 not natively support SRv6. 110 This document provides solutions that can mitigate the identified 111 compatibility challenges and ease the evolution towards SRv6 112 deployment. 114 2. Compatibility Challenges 116 By adopting SR Policy, state in the network devices can be greatly 117 reduced, which ultimately evolves the network into a stateless 118 fabric. However, it also brings compatibility challenges on the 119 legacy devices. In particular, the legacy devices need to upgrade 120 software and/or hardware in order to support the processing of SRH. 122 Furthermore, as the segments in the segment list increase the SR 123 Policy incrementally expands, the encapsulation header overhead 124 increases, which imposes high performance requirements on the 125 performance of hardware forwarding (i.e. the capability of the 126 chipset). 128 This section identifies the challenges for legacy devices imposed by 129 SRv6 in the following SPRING use cases. 131 2.1. Fast Reroute (FRR) 133 FRR is deployed to cope with link or node failures by precomputing 134 backup paths. By relying on SR, Topology Independent Loop-free 135 Alternate Fast Re-route (TI-LFA) 136 [I-D.ietf-rtgwg-segment-routing-ti-lfa] provides a local repair 137 mechanism with the ability to activate the data plane switch-over on 138 to a loop-free backup path irrespective of topologies prior and after 139 the failure. 141 Using SR, there is no need to create state in the network in order to 142 enforce FRR behavior. Correspondingly, the Point of Local Repair, 143 i.e. the protecting router, needs to insert a repair list at the head 144 of the segment list in the SRH, encoding the explicit post- 145 convergence path to the destination. This action will increase the 146 length of the segment list in the SRH as shown in Figure 1. 148 2.2. Traffic Engineering (TE) 150 TE enables network operators to control specific traffic flows going 151 through configured explicit paths. There are loose and strict 152 options. With the loose option, only a small number of hops along 153 the path is explicitly expressed, while the strict option specifies 154 each individual hop in the explicit path, e.g. to encode a low 155 latency path from one network node to another. 157 With SRv6, the strict source-routed explicit paths will result in a 158 long segment list in the SRH as shown in Figure 1, which places high 159 requirements on the devices. 161 2.3. Service Function Chaining (SFC) 163 The SR segments can also encode instructions, called service 164 segments, for steering packets through services running on physical 165 service appliances or virtual network functions (VNF) running in a 166 virtual environment [I-D.ietf-spring-sr-service-programming]. These 167 service segments can also be integrated in an SR policy along with 168 node and adjacency segments. This feature of SR will further 169 increase the length of the segment list in the SRH as shown in 170 Figure 1. 172 In terms of SR awareness, there are two types of services, i.e. SR- 173 aware and SR-unaware services, which both impose new requirements on 174 the hardware. The SR-aware service needs to be fully capable of 175 processing SR traffic, while for the SR-unaware services, an SR proxy 176 function needs to be defined. 178 If the Network Service Header (NSH) based SFC [RFC8300] has already 179 been deployed in the network, the compatibility with existing NSH is 180 required. 182 2.4. IOAM 184 IOAM, i.e. "in-situ" Operations, Administration, and Maintenance 185 (OAM), encodes telemetry and operational information within the data 186 packets to complement other "out-of-band" OAM mechanisms, e.g. ICMP 187 and active probing. The IOAM data fields, i.e. a node data list, 188 hold the information collected as the packets traverse the IOAM 189 domain [I-D.ietf-ippm-ioam-data], which is populated iteratively 190 starting with the last entry of the list. 192 The IOAM data can be embedded into a variety of transports. To 193 support the IOAM on the SRv6 data plane, the O-flag in the SRH is 194 defined [I-D.ali-spring-srv6-oam], which implements the "punt a 195 timestamped copy and forward" or "forward and punt a timestamped 196 copy" behavior. The IOAM data fields, i.e. the node data list, are 197 encapsulated in the IOAM TLV in SRH, which further increases the 198 length of the SRH as shown in Figure 1. 200 +-----------+ 201 |IPv6 packet| 202 +-----------+ 203 / / 204 +-----------+ / IOAM Info / 205 |IPv6 packet| / / 206 +-----------+ +-----------+ +-----------+ 207 |IPv6 packet| / / / / 208 +-----------+ +-----------+ / / / / 209 |IPv6 packet| / / / SF Chain / / SF Chain / 210 +-----------+ +-----------+ / TE Path / / / / / 211 |IPv6 packet| /TI-LFA Path/ / / / / / / 212 +-----------+ +-----------+ +-----------+ +-----------+ +-----------+ 213 |SA,DA | |SA,DA | |SA,DA | |SA,DA | |SA,DA | 214 +-----------+ +-----------+ +-----------+ +-----------+ +-----------+ 215 SRv6 BE SRv6 BE+ SRv6 TE SRv6 SFC SRv6 SFC+ 216 TI-LFA IOAM 218 Figure 1. Evolution of SRv6 SRH 220 Compatibility challenges for legacy devices can be summarized as 221 follows: 223 o Legacy devices need to upgrade software and/or hardware in order 224 to support the processing of SRH 226 o As the SRH expands, the encapsulation overhead increases and 227 correspondingly the effective payload decreases 229 o As the SRH expands, the hardware forwarding performance reduces 230 which requires higher capabilities of the chipset 232 3. Solutions 234 This section provides solutions to mitigate the challenges outlined 235 in section 2. 237 3.1. Traffic Engineering 239 With strict traffic engineering, the resultant long SID list in the 240 SRH raises high requirements on the hardware chipset, which can be 241 mitigated by the following solutions. 243 3.1.1. Binding SID (BSID) 245 Binding SID [RFC8402] involves a list of SIDs and is bound to an SR 246 Policy. The node(s) that imposes the bound policy needs to store the 247 SID list. When a node receives a packet with its active segment as a 248 BSID, the node will steer the packet in to the bound policy 249 accordingly. 251 To reduce the long SID list of a strict TE explicit path, BSID can be 252 used at selective nodes, maybe according to the processing capacity 253 of the hardware chipset. BSID can also be used to impose the repair 254 list in the TI-LFA as described in Section 2.1. 256 3.1.2. PCEP FlowSpec 258 When the SR architecture adopts a centralized model, the SDN 259 controller (e.g. Path Computation Element (PCE)) only needs to apply 260 the SR policy at the head-end. There is no state maintained at 261 midpoints and tail-ends. Eliminating state in the network (midpoints 262 and tail-points) is a key benefit of utilizing SR. However, it also 263 leads to a long SID list for expressing a strict TE path. 265 PCEP FlowSpec [I-D.ietf-pce-pcep-flowspec] provides a trade-off 266 solution. PCEP FlowSpec is able to disseminate Flow Specifications 267 (i.e. filters and actions) to indicate how the classified traffic 268 flows will be treated. In an SR-enabled network, PCEP FlowSpec can 269 be applied at the midpoints to enforce traffic engineering policies 270 where it is needed. In that case, state needs to be maintained at 271 the corresponding midpoints of a TE explicit path, but the SID list 272 can be shortened. 274 3.2. SFC 276 Currently two approaches are proposed to support SFC over SRv6, i.e. 277 stateless SFC [I-D.ietf-spring-sr-service-programming] and stateful 278 SFC [I-D.ietf-spring-nsh-sr]. 280 3.2.1. Stateless SFC 282 A service can also be assigned an SRv6 SID which is integrated into 283 an SR policy and used to steer traffic to it. In terms of the 284 capability of processing the SR information in the received packets, 285 there are two types of services, i.e. SR-aware service and SR-unware 286 service. An SR-aware service can process the SRH in the received 287 packets. An SR-unaware service, i.e. legacy service, is not able to 288 process the SR information in the traffic it receives, and may drop 289 the received packets. In order to support such services in an SRv6 290 domain, the SR proxy is introduced to handle the processing of SRH on 291 behalf of the SR-unware service. The service SID associated with the 292 SR-unaware service is instantiated on the SR proxy, which is used to 293 steer traffic to the service. 295 The SR proxy intercepts the SR traffic destined for the service via 296 the locally instantiated service SID, removes the SR information, and 297 sends the non-SR traffic out on a given interface to the service. 298 When receiving the traffic coming back from the service, the SR proxy 299 will restore the SR information and forwards it to the next segment 300 in the segment list. 302 3.2.2. Stateful SFC 304 The NSH and SR can be integrated in order to support SFC in an 305 efficient and cost-effective manner while maintaining separation of 306 the service and transport planes. 308 In this NSH-SR integration solution, NSH and SR work jointly and 309 complement each other. Specifically, SR is responsible for steering 310 packets along a given Service Function Path (SFP) while NSH is for 311 maintaining the SFC instance context, i.e. Service Path Identifier 312 (SPI), Service Index (SI), and any associated metadata. 314 When a service chain is established, a packet associated with that 315 chain will be first encapsulated with an NSH and then an SRH, and 316 forwarded in the SR domain. When the packet arrives at an SFF and 317 needs to be forwarded to an SF, the SFF performs a lookup based on 318 the service SID associated with the SF to retrieve the next-hop 319 context (a MAC address) between the SFF and SF. Then the SFF strips 320 the SRH and forwards the packet with NSH carrying metadata to the SF 321 where the packet will be processed as specified in [RFC8300]. In 322 this case, the SF is not required to be capable of the SR operation, 323 neither is the SR proxy. Meanwhile, the stripped SRH will be updated 324 and stored in a cache in the SFF, indexed by the NSH SPI for the 325 forwarding of the packet coming back from the SF. 327 3.3. Light Weight IOAM 329 In most cases, after the IPv6 Destination Address (DA) is updated 330 according to the active segment in the SRH, the SID in the SRH will 331 not be used again. However, the entire SID list in the SRH will 332 still be carried in the packet along the path till a PSP/USP is 333 enforced. 335 The light weight IOAM method [I-D.li-spring-passive-pm-for-srv6-np] 336 makes use of the used segments in the SRH to carry the IOAM 337 information, which saves the extra space in the SRH and mitigate the 338 requirements on the hardware. 340 3.4. Postcard Telemetry 342 Existing in-situ OAM techniques incur encapsulation and header 343 overhead issues as described in section 2. Postcard-based Telemetry 344 with Packet Marking for SRv6 on-path 345 OAM[I-D.song-ippm-postcard-based-telemetry], provides a solution that 346 avoids the extra overhead for encapsulating telemetry-related 347 instruction and metadata in SRv6 packets. 349 4. Summary 351 The SRH enables a great number of features for SRv6 and opens new 352 network programming possibilities. By using SRH, it relieves the 353 network devices from state, evolving towards stateless fabric, while 354 the complexity in the control plane increases. The corresponding 355 challenges imposed on the hardware chipset become high as the SRH 356 expands when supporting the diverse use cases. The trade-off 357 solutions presented in this document can mitigate these challenges 358 and smooth the evolution in operators' networks. 360 5. IANA Considerations 362 There are no IANA considerations in this document. 364 Note to RFC Editor: this section may be removed on publication as an 365 RFC. 367 6. Security Considerations 369 TBD 371 7. Contributors 373 Hailong Bai 374 China Unicom 375 China 377 Ruizhao Hu 378 Huawei 379 China 380 Email: huruizhao@huawei.com 382 Jianwei Mao 383 Huawei 384 China 386 Email: maojianwei@huawei.com 388 8. Normative References 390 [I-D.ali-spring-srv6-oam] 391 Ali, Z., Filsfils, C., Kumar, N., Pignataro, C., 392 faiqbal@cisco.com, f., Gandhi, R., Leddy, J., Matsushima, 393 S., Raszuk, R., daniel.voyer@bell.ca, d., Dawra, G., 394 Peirens, B., Chen, M., and G. Naik, "Operations, 395 Administration, and Maintenance (OAM) in Segment Routing 396 Networks with IPv6 Data plane (SRv6)", draft-ali-spring- 397 srv6-oam-02 (work in progress), October 2018. 399 [I-D.ietf-6man-segment-routing-header] 400 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 401 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 402 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 403 progress), October 2019. 405 [I-D.ietf-ippm-ioam-data] 406 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 407 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 408 P., remy@barefootnetworks.com, r., daniel.bernier@bell.ca, 409 d., and J. Lemon, "Data Fields for In-situ OAM", draft- 410 ietf-ippm-ioam-data-08 (work in progress), October 2019. 412 [I-D.ietf-pce-pcep-flowspec] 413 Dhody, D., Farrel, A., and Z. Li, "PCEP Extension for Flow 414 Specification", draft-ietf-pce-pcep-flowspec-07 (work in 415 progress), January 2020. 417 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 418 Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., 419 Francois, P., Voyer, D., Clad, F., and P. Camarillo, 420 "Topology Independent Fast Reroute using Segment Routing", 421 draft-ietf-rtgwg-segment-routing-ti-lfa-01 (work in 422 progress), March 2019. 424 [I-D.ietf-spring-nsh-sr] 425 Guichard, J., Song, H., Tantsura, J., Halpern, J., 426 Henderickx, W., Boucadair, M., and S. Hassan, "Network 427 Service Header (NSH) and Segment Routing Integration for 428 Service Function Chaining (SFC)", draft-ietf-spring-nsh- 429 sr-01 (work in progress), October 2019. 431 [I-D.ietf-spring-sr-service-programming] 432 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 433 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 434 Henderickx, W., and S. Salsano, "Service Programming with 435 Segment Routing", draft-ietf-spring-sr-service- 436 programming-01 (work in progress), November 2019. 438 [I-D.ietf-spring-srv6-network-programming] 439 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 440 Matsushima, S., and Z. Li, "SRv6 Network Programming", 441 draft-ietf-spring-srv6-network-programming-07 (work in 442 progress), December 2019. 444 [I-D.li-spring-passive-pm-for-srv6-np] 445 Li, C. and M. Chen, "Passive Performance Measurement for 446 SRv6 Network Programming", draft-li-spring-passive-pm-for- 447 srv6-np-00 (work in progress), March 2018. 449 [I-D.song-ippm-postcard-based-telemetry] 450 Song, H., Zhou, T., Li, Z., Shin, J., and K. Lee, 451 "Postcard-based On-Path Flow Data Telemetry", draft-song- 452 ippm-postcard-based-telemetry-06 (work in progress), 453 October 2019. 455 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 456 Requirement Levels", BCP 14, RFC 2119, 457 DOI 10.17487/RFC2119, March 1997, 458 . 460 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 461 "Network Service Header (NSH)", RFC 8300, 462 DOI 10.17487/RFC8300, January 2018, 463 . 465 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 466 Decraene, B., Litkowski, S., and R. Shakir, "Segment 467 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 468 July 2018, . 470 Authors' Addresses 472 Hui Tian 473 CAICT 474 China 476 Email: tianhui@caict.ac.cn 478 Feng Zhao 479 CAICT 480 China 482 Email: zhaofeng@caict.ac.cn 484 Chongfeng Xie 485 China Telecom 486 China 488 Email: xiechf.bri@chinatelecom.cn 490 Tong Li 491 China Unicom 492 China 494 Email: litong@chinaunicom.cn 496 Jichun Ma 497 China Unicom 498 China 500 Email: majc16@chinaunicom.cn 502 Shuping Peng 503 Huawei Technologies 504 China 506 Email: pengshuping@huawei.com 507 Zhenbin Li 508 Huawei Technologies 509 China 511 Email: lizhenbin@huawei.com 513 James N Guichard 514 Futurewei Technologies Ltd. 515 USA 517 Email: jguichar@futurewei.com