%% You should probably cite rfc9491 instead of this I-D. @techreport{ietf-spring-nsh-sr-00, number = {draft-ietf-spring-nsh-sr-00}, type = {Internet-Draft}, institution = {Internet Engineering Task Force}, publisher = {Internet Engineering Task Force}, note = {Work in Progress}, url = {https://datatracker.ietf.org/doc/draft-ietf-spring-nsh-sr/00/}, author = {Jim Guichard and Haoyu Song and Jeff Tantsura and Joel M. Halpern and Wim Henderickx and Mohamed Boucadair and Syed Hassan}, title = {{Network Service Header (NSH) and Segment Routing Integration for Service Function Chaining (SFC)}}, pagetotal = 16, year = , month = , day = , abstract = {This document describes two application scenarios where Network Service Header (NSH) and Segment Routing (SR) techniques can be deployed together to support Service Function Chaining (SFC) in an efficient manner while maintaining separation of the service and transport planes as originally intended by the SFC architecture. In the first scenario, an NSH-based SFC is created using SR as the transport between Service Function Forwarders (SFFs). SR in this case is just one of many encapsulations that could be used to maintain the transport-independent nature of NSH-based service chains. In the second scenario, SR is used to represent each service hop of the NSH-based SFC as a segment within the segment-list. SR and NSH in this case are integrated. In both scenarios SR is responsible for steering packets between SFFs along a given Service Function Path (SFP) while NSH is responsible for maintaining the integrity of the service plane, the SFC instance context, and any associated metadata. These application scenarios demonstrate that NSH and SR can work jointly and complement each other leaving the network operator with the flexibility to use whichever transport technology makes sense in specific areas of their network infrastructure, and still maintain an end-to-end service plane using NSH.}, }