idnits 2.17.1 draft-guichard-sfc-nsh-sr-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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 451: '... end of the SFC MUST be advertised wi...' RFC 2119 keyword, line 454: '... RECOMMENDED that a specific prefix-...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 18, 2018) is 2132 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 476 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-12 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-09 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC J. Guichard, Ed. 3 Internet-Draft H. Song 4 Intended status: Informational Huawei 5 Expires: December 20, 2018 J. Tantsura 6 Nuage Networks 7 J. Halpern 8 Ericsson 9 W. Henderickx 10 Nokia 11 M. Boucadair 12 Orange 13 June 18, 2018 15 NSH and Segment Routing Integration for Service Function Chaining (SFC) 16 draft-guichard-sfc-nsh-sr-02 18 Abstract 20 This document describes two application scenarios where Network 21 Service Header (NSH) and Segment Routing (SR) techniques can be 22 deployed together to support Service Function Chaining (SFC) in an 23 efficient manner while maintaining separation of the service and 24 transport planes as originally intended by the SFC architecture. 26 In the first scenario, an NSH-based SFC is created using SR as the 27 transport between SFFs. SR in this case is just one of many 28 encapsulations that could be used to maintain the transport- 29 independent nature of NSH-based service chains. 31 In the second scenario, SR is used to represent each service hop of 32 the NSH-based SFC as a segment within the segment-list. SR and NSH 33 in this case are integrated. 35 In both scenarios SR is responsible for steering packets between SFFs 36 along a given SFP while NSH is responsible for maintaining the 37 integrity of the service plane, the SFC instance context, and any 38 associated metadata. 40 These application scenarios demonstrate that NSH and SR can work 41 jointly and complement each other leaving the network operator with 42 the flexibility to use whichever transport technology makes sense in 43 specific areas of their network infrastructure, and still maintain an 44 end-to-end service plane using NSH. 46 Status of This Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at https://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on December 20, 2018. 63 Copyright Notice 65 Copyright (c) 2018 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (https://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 81 1.1. SFC Overview and Rationale . . . . . . . . . . . . . . . 3 82 1.2. SFC within SR Networks . . . . . . . . . . . . . . . . . 4 83 2. NSH-based SFC with SR-based transport tunnel . . . . . . . . 5 84 3. SR-based SFC with Integrated NSH Service Plane . . . . . . . 9 85 4. Encapsulation Details . . . . . . . . . . . . . . . . . . . . 11 86 4.1. NSH using MPLS-SR Transport . . . . . . . . . . . . . . . 11 87 4.2. NSH using SRv6 Transport . . . . . . . . . . . . . . . . 12 88 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 90 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 91 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 92 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 93 8.2. Informative References . . . . . . . . . . . . . . . . . 13 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 97 1. Introduction 99 1.1. SFC Overview and Rationale 101 The dynamic enforcement of a service-derived, adequate forwarding 102 policy for packets entering a network that supports advanced Service 103 Functions (SFs) has become a key challenge for operators and service 104 providers. Particularly, cascading SFs, for example at the Gi 105 interface in the context of mobile network infrastructure, have shown 106 their limits, such as the same redundant classification features must 107 be supported by many SFs in order to execute their function, some SFs 108 are receiving traffic that they are not supposed to process (e.g., 109 TCP proxies receiving UDP traffic), which inevitably affects their 110 dimensioning and performance, an increased design complexity related 111 to the properly ordered invocation of several SFs, etc. 113 In order to solve those problems and to avoid the adherence with the 114 underlying physical network topology while allowing for simplified 115 service delivery, Service Function Chaining (SFC) techniques have 116 been introduced. 118 SFC techniques are meant to rationalize the service delivery logic 119 and master the companion complexity while optimizing service 120 activation time cycles for operators that need more agile service 121 delivery procedures to better accommodate ever-demanding customer 122 requirements. Indeed, SFC allows to dynamically create service 123 planes that can be used by specific traffic flows. Each service 124 plane is realized by invoking and chaining the relevant service 125 functions in the right sequence. [RFC7498] provides an overview of 126 the SFC problem space and [RFC7665] specifies an SFC architecture. 127 The SFC architecture has the merit to not make assumptions on how 128 advanced features (e.g., load-balancing, loose or strict service 129 paths) have to be enabled with a domain. Various deployment options 130 are made available to operators with the SFC architecture and this 131 approach is fundamental to accommodate various and heterogeneous 132 deployment contexts. 134 Many approaches can be considered for encoding the information 135 required for SFC purposes (e.g., communicate a service chain pointer, 136 encode a list of loose/explicit paths, disseminate a service chain 137 identifier together with a set of context information, etc.). 138 Likewise, many approaches can also be considered for the channel to 139 be used to carry SFC-specific information (e.g., define a new header, 140 re-use existing fields, define an IPv6 extension header, etc.). 141 Among all these approaches, the IETF endorsed a transport-independent 142 SFC encapsulation scheme: NSH [RFC8300]; which is the most mature SFC 143 encapsulation solution. This design is pragmatic as it does not 144 require replicating the same specification effort as a function of 145 underlying transport encapsulation. Moreover, this design approach 146 encourages consistent SFC-based service delivery in networks enabling 147 distinct transport protocols in various segments of the network or 148 even between SFFs vs SF-SFF hops. 150 1.2. SFC within SR Networks 152 As described in [I-D.ietf-spring-segment-routing], Segment Routing 153 (SR) leverages the source routing technique. Concretely, a node 154 steers a packet through an SR policy instantiated as an ordered list 155 of instructions called segments. While initially designed for 156 policy-based source routing, SR also finds its application in 157 supporting SFC [I-D.xu-clad-spring-sr-service-chaining]. The two SR 158 flavors, namely MPLS-SR [I-D.ietf-spring-segment-routing-mpls] and 159 SRv6 [I-D.ietf-6man-segment-routing-header], can both encode a 160 Service Function (SF) as a segment so that an SFC can be specified as 161 a segment list. Nevertheless, and as discussed in [RFC7498], traffic 162 steering is only a subset of the issues that motivated the design of 163 the SFC architecture. Further considerations such as simplifying 164 classification at intermediate SFs and allowing for coordinated 165 behaviors among SFs by means of supplying context information should 166 be taken into account when designing an SFC data plane solution. 168 While each scheme (i.e., NSH-based SFC and SR-based SFC) can work 169 independently, this document describes how the two can be used 170 together in concert and complement each other through two 171 representative application scenarios. Both application scenarios may 172 be supported using either MPLS-SR or SRv6: 174 o NSH-based SFC with SR-based transport: in this scenario segment 175 routing provides the transport encapsulation between SFFs while 176 NSH is used to convey and trigger SFC polices. 178 o SR-based SFC with integrated NSH service plane: in this scenario 179 each service hop of the SFC is represented as a segment of the SR 180 segment-list. SR is responsible for steering traffic through the 181 necessary SFFs as part of the segment routing path and NSH is 182 responsible for maintaining the service plane, and holding the SFC 183 instance context and associated metadata. 185 It is of course possible to combine both of these two scenarios so as 186 to support specific deployment requirements and use cases. 188 2. NSH-based SFC with SR-based transport tunnel 190 Because of the transport-independent nature of NSH-based service 191 chains, it is expected that the NSH has broad applicability across 192 different domains of a network. By way of illustration the various 193 SFs involved in a service chain are available in a single data 194 center, or spread throughout multiple locations (e.g., data centers, 195 different POPs), depending upon the operator preference and/or 196 availability of service resources. Regardless of where the service 197 resources are deployed it is necessary to provide traffic steering 198 through a set of SFFs and NSH-based service chains provide the 199 flexibility for the network operator to choose which particular 200 transport encapsulation to use between SFFs, which may be different 201 depending upon which area of the network the SFFs/SFs are currently 202 deployed. Therefore from an SFC architecture perspective, segment 203 routing is simply one of multiple available transport encapsulations 204 that can be used for traffic steering between SFFs. Concretely, NSH 205 does not require to use a unique transport encapsulation when 206 traversing a service chain. NSH-based service forwarding relies upon 207 underlying service node capabilities. 209 The following three figures provide an example of an SFC established 210 for flow F that has SF instances located in different data centers, 211 DC1 and DC2. For the purpose of illustration, let the SFC's Service 212 Path Identifier (SPI) be 100 and the initial Service Index (SI) be 213 255. 215 Referring to Figure 1, packets of flow F in DC1 are classified into 216 an NSH-based SFC and encapsulated after classification as and forwarded to SFF1 218 (which is the first SFF hop for this service chain). 220 After removing the outer transport encapsulation, that may or may not 221 be MPLS-SR or SRv6, SFF1 uses the SPI and SI carried within the NSH 222 encapsulation to determine that it should forward the packet to SF1. 223 SF1 applies its service, decrements the SI by 1, and returns the 224 packet to SFF1. SFF1 therefore has when the packet 225 comes back from SF1. SFF1 does a lookup on which 226 results in and forwards the packet to DC1-GW1. 228 +--------------------------- DC1 ----------------------------+ 229 | +-----+ | 230 | | SF1 | | 231 | +--+--+ | 232 | | | 233 | | | 234 | +------------+ | +------------+ | 235 | | N(100,255) | | | F:Inner Pkt| | 236 | +------------+ | +------------+ | 237 | | F:Inner Pkt| | | N(100,254) | | 238 | +------------+ ^ | | +------------+ | 239 | (2) | | | (3) | 240 | | | v | 241 | (1) | (4) | 242 |+------------+ ----> +--+---+ ----> +---------+ | 243 || | NSH | | NSH | | | 244 || Classifier +------------+ SFF1 +--------------+ DC1-GW1 + | 245 || | | | | | | 246 |+------------+ +------+ +---------+ | 247 | | 248 | +------------+ +------------+ | 249 | | N(100,255) | | N(100,254) | | 250 | +------------+ +------------+ | 251 | | F:Inner Pkt| | F:Inner Pkt| | 252 | +------------+ +------------+ | 253 | | 254 +------------------------------------------------------------+ 256 Figure 1: SR for inter-DC SFC - Part 1 258 Referring now to Figure 2, DC1-GW1 performs a lookup on the 259 information conveyed in the NSH which results in . The SR encapsulation has the SR segment-list to 261 forward the packet across the inter-DC network to DC2. 263 +----------- Inter DC ----------------+ 264 | (5) | 265 +------+ ----> | +---------+ ----> +---------+ | 266 | | NSH | | | SR | | | 267 + SFF1 +----------|-+ DC1-GW1 +-------------+ DC2-GW1 + | 268 | | | | | | | | 269 +------+ | +---------+ +---------+ | 270 | | 271 | +------------+ | 272 | | S(DC2-GW1) | | 273 | +------------+ | 274 | | N(100,254) | | 275 | +------------+ | 276 | | F:Inner Pkt| | 277 | +------------+ | 278 +-------------------------------------+ 280 Figure 2: SR for inter-DC SFC - Part 2 282 When the packet arrives at DC2, as shown in Figure 3, the SR 283 encapsulation is removed and DC2-GW1 performs a lookup on the NSH 284 which results in next-hop: SFF2. The outer transport encapsulation 285 may be any transport that is able to identify NSH as the next 286 protocol. 288 +------------------------ DC2 ----------------------+ 289 | +-----+ | 290 | | SF2 | | 291 | +--+--+ | 292 | | | 293 | | | 294 | +------------+ | +------------+ | 295 | | N(100,254) | | | F:Inner Pkt| | 296 | +------------+ | +------------+ | 297 | | F:Inner Pkt| | | N(100,253) | | 298 | +------------+ ^ | | +------------+ | 299 | (7) | | | (8) | 300 | | | v | 301 | (6) | (9) | 302 |+----------+ ----> +--+---+ ----> | 303 || | NSH | | IP | 304 || DC2-GW1 +------------+ SFF2 | | 305 || | | | | 306 |+----------+ +------+ | 307 | | 308 | +------------+ +------------+ | 309 | | N(100,254) | | F:Inner Pkt| | 310 | +------------+ +------------+ | 311 | | F:Inner Pkt| | 312 | +------------+ | 313 +---------------------------------------------------+ 315 Figure 3: SR for inter-DC SFC - Part 3 317 The benefits of this scheme are listed hereafter: 319 o The network operator is able to take advantage of the transport- 320 independent nature of the NSH encapsulation. 322 o The network operator is able to take advantage of the traffic 323 steering capability of SR where appropriate. 325 o Light-weight NSH is used in the data center for SFC and avoids 326 more complex hierarchical SFC schemes between data centers. 328 o Clear responsibility division and scope between NSH and SR. 330 Note that this scenario is applicable to any case where multiple 331 segments of a service chain are distributed into multiple domains or 332 where traffic-engineered paths are necessary between SFFs (strict 333 forwarding paths for example). 335 3. SR-based SFC with Integrated NSH Service Plane 337 In this scenario we assume that the SFs are NSH-aware and therefore 338 it should not be necessary to implement an SFC proxy to achieve 339 Service Function Chaining. The operation relies upon SR to perform 340 SFF-SFF transport and NSH to provide the service plane between SFs 341 thereby maintaining SFC context and metadata. 343 When a service chain is established, a packet associated with that 344 chain will first encapsulate an NSH that will be used to maintain the 345 end-to-end service plane through use of the SFC context. The SFC 346 context (e.g., the service plane path referenced by the SPI) is used 347 by an SFF to determine the SR segment list for forwarding the packet 348 to the next-hop SFFs. The packet is then encapsulated using the 349 (transport-specific) SR header and forwarded in the SR domain 350 following normal SR operation. 352 When a packet has to be forwarded to an SF attached to an SFF, the 353 SFF strips the SR information of the packet, updates the SR 354 information, and saves it to a cache indexed by the NSH SPI. This 355 saved SR information is used to encapsulate and forward the packet(s) 356 coming back from the SF. 358 When the SF receives the packet, it processes it as usual and sends 359 it back to the SFF. Once the SFF receives this packet, it extracts 360 the SR information using the NSH SPI as the index into the cache. 361 The SFF then pushes the SR header on top of the NSH header, and 362 forwards the packet to the next segment in the segment list. 364 Figure 4 illustrates an example of this scenario. 366 +-----+ +-----+ 367 | SF1 | | SF2 | 368 +--+--+ +--+--+ 369 | | 370 | | 371 +-----------+ | +-----------+ +-----------+ | +-----------+ 372 |N(100,255) | | |F:Inner Pkt| |N(100,254) | | |F:Inner Pkt| 373 +-----------+ | +-----------+ +-----------+ | +-----------+ 374 |F:Inner Pkt| | |N(100,254) | |F:Inner Pkt| | |N(100,253) | 375 +-----------+ | +-----------+ +-----------+ | +-----------+ 376 (2) ^ | (3) | (5) ^ | (6) | 377 | | | | | | 378 | | v | | v 379 +------------+ (1)--> +-+----+ (4)--> +---+--+ (7)-->IP 380 | | NSHoSR | | NSHoSR | | 381 | Classifier +--------+ SFF1 +---------------------+ SFF2 | 382 | | | | | | 383 +------------+ +------+ +------+ 385 +------------+ +------------+ 386 | S(SF1) | | S(SF2) | 387 +------------+ +------------+ 388 | S(SFF2) | | N(100,254) | 389 +------------+ +------------+ 390 | S(SF2) | | F:Inner Pkt| 391 +------------+ +------------+ 392 | N(100,255) | 393 +------------+ 394 | F:Inner Pkt| 395 +------------+ 397 Figure 4: NSH over SR for SFC 399 The benefits of this scheme include: 401 o It is economically sound for SF vendors to only support one 402 unified SFC solution. The SF is unaware of the SR. 404 o It simplifies the SFF (i.e., the SR router) by nullifying the 405 needs for re-classification and SR proxy. 407 o It provides a unique and standard way to pass metadata to SFs. 408 Note that currently there is no solution for MPLS-SR to carry 409 metadata and there is no solution to pass metadata to SR-unaware 410 SFs. 412 o SR is also used for forwarding purposes including between SFFs. 414 o It takes advantage of SR to eliminate the NSH forwarding state in 415 SFFs. This applies each time strict or loose SFPs are in use. 417 o It requires no interworking as would be the case if MPLS-SR based 418 SFC and NSH-based SFC were deployed as independent mechanisms in 419 different parts of the network. 421 4. Encapsulation Details 423 4.1. NSH using MPLS-SR Transport 425 MPLS-SR instantiates Segment IDs (SIDs) as MPLS labels and therefore 426 the segment routing header is a stack of MPLS labels. 428 When carrying NSH within an MPLS-SR transport, the full encapsulation 429 headers are as illustrated in Figure 5. 431 +------------------+ 432 ~ MPLS-SR Labels ~ 433 +------------------+ 434 | NSH Base Hdr | 435 +------------------+ 436 | Service Path Hdr | 437 +------------------+ 438 ~ Metadata ~ 439 +------------------+ 441 Figure 5: NSH using MPLS-SR Transport 443 As described in [I-D.ietf-spring-segment-routing] the IGP signaling 444 extension for IGP-Prefix segment includes a flag to indicate whether 445 directly connected neighbors of the node on which the prefix is 446 attached should perform the NEXT operation or the CONTINUE operation 447 when processing the SID. When NSH is carried beneath MPLS-SR it is 448 necessary to terminate the NSH-based SFC at the tail-end node of the 449 MPLS-SR label stack. This is the equivalent of MPLS Ultimate Hop 450 Popping (UHP) and therefore the prefix-SID associated with the tail- 451 end of the SFC MUST be advertised with the CONTINUE operation so that 452 the penultimate hop node does not pop the top label of the MPLS-SR 453 label stack and thereby expose NSH to the wrong SFF. It is 454 RECOMMENDED that a specific prefix-SID be allocated at each node for 455 use by the SFC application for this purpose. 457 At the end of the MPLS-SR path it is necessary to provide an 458 indication to the tail-end that NSH follows the MPLS-SR label stack. 460 There are several ways to achieve this but its specification is 461 outside the scope of this document. 463 4.2. NSH using SRv6 Transport 465 When carrying NSH within an SRv6 transport the full encapsulation is 466 as illustrated in Figure 6. 468 0 1 2 3 469 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 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | Last Entry | Flags | Tag | S 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e 475 | | g 476 | Segment List[0] (128 bits IPv6 address) | m 477 | | e 478 | | n 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ t 480 | | 481 | | R 482 ~ ... ~ o 483 | | u 484 | | t 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i 486 | | n 487 | Segment List[n] (128 bits IPv6 address) | g 488 | | 489 | | S 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R 491 // // H 492 // Optional Type Length Value objects (variable) // 493 // // 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N 497 | Service Path Identifier | Service Index | S 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H 499 | | 500 ~ Variable-Length Context Headers (opt.) ~ 501 | | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 Figure 6: NSH using SRv6 Transport 506 5. Security Considerations 508 Generic SFC-related security considerations are discussed in 509 [RFC7665]. NSH-specific security considerations are discussed in 510 [RFC8300]. 512 6. IANA Considerations 514 This memo includes no request to IANA. 516 7. Acknowledgments 518 TBD. 520 8. References 522 8.1. Normative References 524 [I-D.ietf-spring-segment-routing] 525 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 526 Litkowski, S., and R. Shakir, "Segment Routing 527 Architecture", draft-ietf-spring-segment-routing-15 (work 528 in progress), January 2018. 530 [I-D.ietf-spring-segment-routing-mpls] 531 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 532 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 533 data plane", draft-ietf-spring-segment-routing-mpls-12 534 (work in progress), February 2018. 536 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 537 Chaining (SFC) Architecture", RFC 7665, 538 DOI 10.17487/RFC7665, October 2015, 539 . 541 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 542 "Network Service Header (NSH)", RFC 8300, 543 DOI 10.17487/RFC8300, January 2018, 544 . 546 8.2. Informative References 548 [I-D.ietf-6man-segment-routing-header] 549 Previdi, S., Filsfils, C., Raza, K., Dukes, D., Leddy, J., 550 Field, B., daniel.voyer@bell.ca, d., 551 daniel.bernier@bell.ca, d., Matsushima, S., Leung, I., 552 Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun, 553 D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing 554 Header (SRH)", draft-ietf-6man-segment-routing-header-09 555 (work in progress), March 2018. 557 [I-D.xu-clad-spring-sr-service-chaining] 558 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 559 d., Decraene, B., Yadlapalli, C., Henderickx, W., Salsano, 560 S., and S. Ma, "Segment Routing for Service Chaining", 561 draft-xu-clad-spring-sr-service-chaining-00 (work in 562 progress), December 2017. 564 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 565 Service Function Chaining", RFC 7498, 566 DOI 10.17487/RFC7498, April 2015, 567 . 569 Authors' Addresses 571 James N Guichard (editor) 572 Huawei 573 2330 Central Express Way 574 Santa Clara 575 USA 577 Email: james.n.guichard@huawei.com 579 Haoyu Song 580 Huawei 581 2330 Central Express Way 582 Santa Clara 583 USA 585 Email: haoyu.song@huawei.com 587 Jeff Tantsura 588 Nuage Networks 589 USA 591 Email: jefftant.ietf@gmail.com 592 Joel Halpern 593 Ericsson 594 USA 596 Email: joel.halpern@ericsson.com 598 Wim Henderickx 599 Nokia 600 USA 602 Email: wim.henderickx@nokia.com 604 Mohamed Boucadair 605 Orange 606 USA 608 Email: mohamed.boucadair@orange.com