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