Futurewei Technologies

2330 Central Expressway Santa Clara CA United States of America james.n.guichard@futurewei.com

Nvidia

United States of America jefftant.ietf@gmail.com

RTG SPRING NSH SR MPLS-SR SRv6 SFC This document describes the integration of the Network Service Header (NSH) and Segment Routing (SR), as well as encapsulation details, to efficiently support Service Function Chaining (SFC) while maintaining separation of the service and transport planes as originally intended by the SFC architecture. Combining these technologies allows SR to be used for steering packets between Service Function Forwarders (SFFs) along a given Service Function Path (SFP), whereas the NSH is responsible for maintaining the integrity of the service plane, the SFC instance context, and any associated metadata. This integration demonstrates that the NSH and SR can work cooperatively and provide a network operator with the flexibility to use whichever transport technology makes sense in specific areas of their network infrastructure while still maintaining an end-to-end service plane using the NSH.

Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents

• .  Introduction
  • .  SFC Overview and Rationale
  • .  Requirements Language
• .  SFC within Segment Routing Networks
• .  NSH-Based SFC with SR-MPLS or the SRv6 Transport Tunnel
• .  SR-Based SFC with the Integrated NSH Service Plane
• .  Packet Processing for SR-Based SFC
  • .  SR-Based SFC (SR-MPLS) Packet Processing
  • .  SR-Based SFC (SRv6) Packet Processing
• .  Encapsulation
  • .  NSH Using SR-MPLS Transport
  • .  NSH Using SRv6 Transport
• .  Security Considerations
• .  Backwards Compatibility
• .  Caching Considerations
• . MTU Considerations
• . IANA Considerations
  • .  Protocol Number for the NSH
  • .  SRv6 Endpoint Behavior for the NSH
• . References
  • .  Normative References
  • .  Informative References
• Contributors
• Authors' Addresses

Introduction

SFC Overview and Rationale The dynamic enforcement of a service-derived and adequate forwarding policy for packets entering a network that supports advanced Service Functions (SFs) has become a key challenge for network operators. For instance, cascading SFs at the Third Generation Partnership Project (3GPP) Gi interface (N6 interface in 5G architecture) has shown limitations such as 1) redundant classification features that must be supported by many SFs to execute their function; 2) some SFs that receive traffic that they are not supposed to process (e.g., TCP proxies receiving UDP traffic), which inevitably affects their dimensioning and performance; and 3) an increased design complexity related to the properly ordered invocation of several SFs. In order to solve those problems and to decouple the service's topology from the underlying physical network while allowing for simplified service delivery, SFC techniques have been introduced . SFC techniques are meant to rationalize the service delivery logic and reduce the resulting complexity while optimizing service activation time cycles for operators that need more agile service delivery procedures to better accommodate ever-demanding customer requirements. SFC allows network operators to dynamically create service planes that can be used by specific traffic flows. Each service plane is realized by invoking and chaining the relevant service functions in the right sequence. provides an overview of the overall SFC problem space, and specifies an SFC data plane architecture. The SFC architecture does not make assumptions on how advanced features (e.g., load balancing, loose or strict service paths) could be enabled within a domain. Various deployment options are made available to operators with the SFC architecture; this approach is fundamental to accommodate various and heterogeneous deployment contexts. Many approaches can be considered for encoding the information required for SFC purposes (e.g., communicate a service chain pointer, encode a list of loose/explicit paths, or disseminate a service chain identifier together with a set of context information). Likewise, many approaches can also be considered for the channel to be used to carry SFC-specific information (e.g., define a new header, reuse existing packet header fields, or define an IPv6 extension header). Among all these approaches, the IETF created a transport-independent SFC encapsulation scheme: NSH . This design is pragmatic, as it does not require replicating the same specification effort as a function of underlying transport encapsulation. Moreover, this design approach encourages consistent SFC-based service delivery in networks enabling distinct transport protocols in various network segments or even between SFFs vs. SF-SFF hops.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

SFC within Segment Routing Networks specifies how to encapsulate the NSH directly within a link-layer header. In this document, IANA has assigned IP protocol number 145 for the NSH so that it can also be encapsulated directly within an IP header. The procedures that follow make use of this property. As described in , SR leverages the source-routing technique. Concretely, a node steers a packet through an SR policy instantiated as an ordered list of instructions called segments. While initially designed for policy-based source routing, SR also finds its application in supporting SFC . The two SR data plane encapsulations, namely SR-MPLS and Segment Routing over IPv6 (SRv6), can encode an SF as a segment so that a service function chain can be specified as a segment list. Nevertheless, and as discussed in , traffic steering is only a subset of the issues that motivated the design of the SFC architecture. Further considerations, such as simplifying classification at intermediate SFs and allowing for coordinated behaviors among SFs by means of supplying context information (a.k.a. metadata), should be considered when designing an SFC data plane solution. While each scheme (i.e., NSH-based SFC and SR-based SFC) can work independently, this document describes how the two can be used together in concert and to complement each other through two representative application scenarios. Both application scenarios may be supported using either SR-MPLS or SRv6:

NSH-based SFC with the SR-based transport plane:

In this scenario, SR-MPLS or SRv6 provides the transport encapsulation between SFFs, while the NSH is used to convey and trigger SFC policies.

SR-based SFC with the integrated NSH service plane:

In this scenario, each service hop of the service function chain is represented as a segment of the SR segment list. SR is thus responsible for steering traffic through the necessary SFFs as part of the segment routing path, while the NSH is responsible for maintaining the service plane and holding the SFC instance context (including associated metadata).

Of course, it is possible to combine both of these two scenarios to support specific deployment requirements and use cases. A classifier MUST use one NSH Service Path Identifier (SPI) for each SR policy so that different traffic flows can use the same NSH Service Function Path (SFP) and different SR policies can coexist on the same SFP without conflict during SFF processing.

NSH-Based SFC with SR-MPLS or the SRv6 Transport Tunnel Because of the transport-independent nature of NSH-based service function chains, it is expected that the NSH has broad applicability across different network domains (e.g., access, core). By way of illustration, the various SFs involved in a service function chain may be available in a single data center or spread throughout multiple locations (e.g., data centers, different Points of Presence (POPs)), depending upon the network operator preference and/or availability of service resources. Regardless of where the SFs are deployed, it is necessary to provide traffic steering through a set of SFFs, and when NSH and SR are integrated, this is provided by SR-MPLS or SRv6. The following three figures provide an example of an SFC-established flow F that has SF instances located in different data centers, DC1 and DC2. For the purpose of illustration, let the SFC's NSH SPI be 100 and the initial Service Index (SI) be 255. Referring to , packets of flow F in DC1 are classified into an NSH-based service function chain, encapsulated after classification as <Inner Pkt><NSH: SPI 100, SI 255><Outer-transport>, and forwarded to SFF1 (which is the first SFF hop for this service function chain). After removing the outer transport encapsulation, SFF1 uses the SPI and SI carried within the NSH encapsulation to determine that it should forward the packet to SF1. SF1 applies its service, decrements the SI by 1, and returns the packet to SFF1. Therefore, SFF1 has <SPI 100, SI 254> when the packet comes back from SF1. SFF1 does a lookup on <SPI 100, SI 254>, which results in <next-hop: DC1-GW1> and forwards the packet to DC1-GW1.

SR for Inter-DC SFC - Part 1 +--------------------------- DC1 ----------------------------+ | +-----+ | | | SF1 | | | +--+--+ | | | | | | | | +------------+ | +------------+ | | | N(100,255) | | | N(100,254) | | | +------------+ | +------------+ | | | F:Inner Pkt| | | F:Inner Pkt| | | +------------+ ^ | | +------------+ | | (2) | | | (3) | | | | v | | (1) | (4) | |+------------+ ----> +--+---+ ----> +---------+ | || | NSH | | NSH | | | || Classifier +------------+ SFF1 +--------------+ DC1-GW1 + | || | | | | | | |+------------+ +------+ +---------+ | | | | +------------+ +------------+ | | | N(100,255) | | N(100,254) | | | +------------+ +------------+ | | | F:Inner Pkt| | F:Inner Pkt| | | +------------+ +------------+ | | | +------------------------------------------------------------+

Referring now to , DC1-GW1 performs a lookup using the information conveyed in the NSH, which results in <next-hop: DC2-GW1, encapsulation: SR>. The SR encapsulation, which may be SR-MPLS or SRv6, has the SR segment list to forward the packet across the inter-DC network to DC2.

SR for Inter-DC SFC - Part 2 +----------- Inter DC ----------------+ (4) | (5) | +------+ ----> | +---------+ ----> +---------+ | | | NSH | | | SR | | | + SFF1 +----------|-+ DC1-GW1 +-------------+ DC2-GW1 + | | | | | | | | | +------+ | +---------+ +---------+ | | | | +------------+ | | | S(DC2-GW1) | | | +------------+ | | | N(100,254) | | | +------------+ | | | F:Inner Pkt| | | +------------+ | +-------------------------------------+

When the packet arrives at DC2, as shown in , the SR encapsulation is removed, and DC2-GW1 performs a lookup on the NSH, which results in next hop: SFF2. When SFF2 receives the packet, it performs a lookup on <NSH: SPI 100, SI 254> and determines to forward the packet to SF2. SF2 applies its service, decrements the SI by 1, and returns the packet to SFF2. Therefore, SFF2 has <NSH: SPI 100, SI 253> when the packet comes back from SF2. SFF2 does a lookup on <NSH: SPI 100, SI 253>, which results in the end of the service function chain.

SR for Inter-DC SFC - Part 3 +------------------------ DC2 ----------------------+ | +-----+ | | | SF2 | | | +--+--+ | | | | | | | | +------------+ | +------------+ | | | N(100,254) | | | N(100,253) | | | +------------+ | +------------+ | | | F:Inner Pkt| | | F:Inner Pkt| | | +------------+ ^ | | +------------+ | | (7) | | | (8) | | | | v | (5) | (6) | (9) | +---------+ ---> | +----------+ ----> +--+---+ ----> | | | SR | | | NSH | | IP | + DC1-GW1 +--------|-+ DC2-GW1 +------------+ SFF2 | | | | | | | | | | +---------+ | +----------+ +------+ | | | | +------------+ +------------+ | | | N(100,254) | | F:Inner Pkt| | | +------------+ +------------+ | | | F:Inner Pkt| | | +------------+ | +---------------------------------------------------+

The benefits of this scheme are listed hereafter:

• The network operator is able to take advantage of the transport-independent nature of the NSH encapsulation while the service is provisioned end-to-end.
• The network operator is able to take advantage of the traffic-steering (traffic-engineering) capability of SR where appropriate.
• Clear responsibility division and scope between the NSH and SR.

Note that this scenario is applicable to any case where multiple segments of a service function chain are distributed across multiple domains or where traffic-engineered paths are necessary between SFFs (strict forwarding paths, for example). Further, note that the above example can also be implemented using end-to-end segment routing between SFF1 and SFF2. (As such, DC-GW1 and DC-GW2 are forwarding the packets based on segment routing instructions and are not looking at the NSH header for forwarding.)

SR-Based SFC with the Integrated NSH Service Plane In this scenario, we assume that the SFs are NSH-aware; therefore, it should not be necessary to implement an SFC proxy to achieve SFC. The operation relies upon SR-MPLS or SRv6 to perform SFF-SFF transport and the NSH to provide the service plane between SFs, thereby maintaining SFC context (e.g., the service plane path referenced by the SPI) and any associated metadata. When a service function chain is established, a packet associated with that chain will first carry an NSH that will be used to maintain the end-to-end service plane through use of the SFC context. The SFC context is used by an SFF to determine the SR segment list for forwarding the packet to the next-hop SFFs. The packet is then encapsulated using the SR header and forwarded in the SR domain following normal SR operations. When a packet has to be forwarded to an SF attached to an SFF, the SFF performs a lookup on the segment identifier (SID) associated with the SF. In the case of SR-MPLS, this will be a Prefix-SID . In the case of SRv6, the behavior described within this document is assigned the name END.NSH, and describes the allocation of the code point by IANA. The result of this lookup allows the SFF to retrieve the next-hop context between the SFF and SF (e.g., the destination Media Access Control (MAC) address in case Ethernet encapsulation is used between the SFF and SF). In addition, the SFF strips the SR information from the packet, updates the SR information, and saves it to a cache indexed by the NSH Service Path Identifier (SPI) and the Service Index (SI) decremented by 1. This saved SR information is used to encapsulate and forward the packet(s) coming back from the SF. The behavior of remembering the SR segment list occurs at the end of the regularly defined logic. The behavior of reattaching the segment list occurs before the SR process of forwarding the packet to the next entry in the segment list. Both behaviors are further detailed in . When the SF receives the packet, it processes it as usual. When the SF is co-resident with a classifier, the already-processed packet may be reclassified. The SF sends the packet back to the SFF. Once the SFF receives this packet, it extracts the SR information using the NSH SPI and SI as the index into the cache. The SFF then pushes the retrieved SR header on top of the NSH header and forwards the packet to the next segment in the segment list. The lookup in the SFF cache might fail if reclassification at the SF changed the NSH SPI and/or SI to values that do not exist in the SFF cache. In such a case, the SFF must generate an error and drop the packet. illustrates an example of this scenario.

NSH over SR for SFC +-----+ +-----+ | SF1 | | SF2 | +--+--+ +--+--+ | | | | +-----------+ | +-----------+ +-----------+ | +-----------+ |N(100,255) | | |N(100,254) | |N(100,254) | | |N(100,253) | +-----------+ | +-----------+ +-----------+ | +-----------+ |F:Inner Pkt| | |F:Inner Pkt| |F:Inner Pkt| | |F:Inner Pkt| +-----------+ | +-----------+ +-----------+ | +-----------+ (2) ^ | (3) | (5) ^ | (6) | | | | | | | | | | | | | (1) | | v (4) | | v (7) +------------+ ---> +-+----+ ----> +---+--+ --> | | NSHoverSR | | NSHoverSR | | IP | Classifier +-----------+ SFF1 +---------------------+ SFF2 | | | | | | | +------------+ +------+ +------+ +------------+ +------------+ +------------+ | S(SF1) | | S(SF2) | | F:Inner Pkt| +------------+ +------------+ +------------+ | S(SFF2) | | N(100,254) | +------------+ +------------+ | S(SF2) | | F:Inner Pkt| +------------+ +------------+ | N(100,255) | +------------+ | F:Inner Pkt| +------------+

The benefits of this scheme include the following:

• It is economically sound for SF vendors to only support one unified SFC solution. The SF is unaware of the SR.
• It simplifies the SFF (i.e., the SR router) by nullifying the needs for reclassification and SR proxy.
• SR is also used for forwarding purposes, including between SFFs.
• It takes advantage of SR to eliminate the NSH forwarding state in SFFs. This applies each time strict or loose SFPs are in use.
• It requires no interworking, as would be the case if SR-MPLS-based SFC and NSH-based SFC were deployed as independent mechanisms in different parts of the network.

Packet Processing for SR-Based SFC This section describes the End.NSH behavior (SRv6), Prefix-SID behavior (SR-MPLS), and NSH processing logic.

SR-Based SFC (SR-MPLS) Packet Processing When an SFF receives a packet destined to S and S is a local Prefix-SID associated with an SF, the SFF strips the SR segment list (label stack) from the packet, updates the SR information, and saves it to a cache indexed by the NSH Service Path Identifier (SPI) and the Service Index (SI) decremented by 1. This saved SR information is used to re-encapsulate and forward the packet(s) coming back from the SF.

SR-Based SFC (SRv6) Packet Processing This section describes the End.NSH behavior and NSH processing logic for SRv6. The pseudocode is shown below. When N receives a packet destined to S and S is a local End.NSH SID, the processing is the same as that specified by , up through line S15. After S15, if S is a local End.NSH SID, then: S15.1. Remove and store IPv6 and SRH headers in local cache indexed by <NSH: service-path-id, service-index -1> S15.2. Submit the packet to the NSH FIB lookup and transmit to the destination associated with <NSH: service-path-id, service-index> When a packet is returned to the SFF from the SF, reattach the cached IPv6 and SRH headers based on the <NSH: service-path-id, service-index> from the NSH header. Then, resume processing from with line S16.

Encapsulation

NSH Using SR-MPLS Transport SR-MPLS instantiates segment identifiers (SIDs) as MPLS labels; therefore, the segment routing header is a stack of MPLS labels. When carrying an NSH within an SR-MPLS transport, the full encapsulation headers are as illustrated in .

NSH Using SR-MPLS Transport +------------------+ ~ SR-MPLS Labels ~ +------------------+ | NSH Base Hdr | +------------------+ | Service Path Hdr | +------------------+ ~ Metadata ~ +------------------+

As described in , "[t]he IGP signaling extension for IGP-Prefix segment includes a flag to indicate whether directly connected neighbors of the node on which the prefix is attached should perform the NEXT operation or the CONTINUE operation when processing the SID." When an NSH is carried beneath SR-MPLS, it is necessary to terminate the NSH-based SFC at the tail-end node of the SR-MPLS label stack. This can be achieved using either the NEXT or CONTINUE operation. If the NEXT operation is to be used, then at the end of the SR-MPLS path, it is necessary to provide an indication to the tail end that the NSH follows the SR-MPLS label stack as described by . If the CONTINUE operation is to be used, this is the equivalent of MPLS Ultimate Hop Popping (UHP); therefore, it is necessary to ensure that the penultimate hop node does not pop the top label of the SR-MPLS label stack and thereby expose the NSH to the wrong SFF. This is realized by setting the No Penultimate Hop Popping (No-PHP) flag in Prefix-SID Sub-TLV . It is RECOMMENDED that a specific Prefix-SID be allocated at each node for use by the SFC application for this purpose.

NSH Using SRv6 Transport When carrying a NSH within an SRv6 transport, the full encapsulation is as illustrated in .

NSH Using SRv6 Transport 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | Routing Type | Segments Left | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Last Entry | Flags | Tag | S +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e | | g | Segment List[0] (128-bit IPv6 address) | m | | e | | n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ t | | | | R ~ ... ~ o | | u | | t +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i | | n | Segment List[n] (128-bit IPv6 address) | g | | | | S +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R // // H // Optional Type Length Value objects (variable) // // // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N | Service Path Identifier | Service Index | S +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H | | ~ Variable-Length Context Headers (opt.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Encapsulation of the NSH following SRv6 is indicated by the IP protocol number for the NSH in the Next Header of the SRH.

Security Considerations Generic SFC-related security considerations are discussed in . NSH-specific security considerations are discussed in . Generic security considerations related to segment routing are discussed in and .

Backwards Compatibility For SRv6/IPv6, if a processing node does not recognize the NSH, it should follow the procedures described in . For SR-MPLS, if a processing node does not recognize the NSH, it should follow the procedures laid out in .

Caching Considerations The cache mechanism must remove cached entries at an appropriate time determined by the implementation. Further, an implementation MAY allow network operators to set the said time value. In the case where a packet arriving from an SF does not have a matching cached entry, the SFF SHOULD log this event and MUST drop the packet.

MTU Considerations Aligned with and , it is RECOMMENDED for network operators to increase the underlying MTU so that SR/NSH traffic is forwarded within an SR domain without fragmentation.

IANA Considerations

Protocol Number for the NSH IANA has assigned protocol number 145 for the NSH in the "Assigned Internet Protocol Numbers" registry . Assigned Internet Protocol Numbers Registry

Decimal	Keyword	Protocol	IPv6 Extension Header	Reference
145	NSH	Network Service Header	N	RFC 9491

SRv6 Endpoint Behavior for the NSH IANA has allocated the following value in the "SRv6 Endpoint Behaviors" subregistry under the "Segment Routing" registry: SRv6 Endpoint Behaviors Subregistry

Value	Hex	Endpoint Behavior	Reference	Change Controller
84	0x0054	End.NSH - NSH Segment	RFC 9491	IETF

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document specifies the architecture for Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK] RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. This document describes a Network Service Header (NSH) imposed on packets or frames to realize Service Function Paths (SFPs). The NSH also provides a mechanism for metadata exchange along the instantiated service paths. The NSH is the Service Function Chaining (SFC) encapsulation required to support the SFC architecture (defined in RFC 7665). Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. Segment Routing (SR) leverages the source-routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. In the MPLS data plane, the SR header is instantiated through a label stack. This document specifies the forwarding behavior to allow instantiating SR over the MPLS data plane (SR-MPLS). MPLS Segment Routing (SR-MPLS) is a method of source routing a packet through an MPLS data plane by imposing a stack of MPLS labels on the packet to specify the path together with any packet-specific instructions to be executed on it. SR-MPLS can be leveraged to realize a source-routing mechanism across MPLS, IPv4, and IPv6 data planes by using an MPLS label stack as a source-routing instruction set while making no changes to SR-MPLS specifications and interworking with SR-MPLS implementations. This document describes how SR-MPLS-capable routers and IP-only routers can seamlessly coexist and interoperate through the use of SR-MPLS label stacks and IP encapsulation/tunneling such as MPLS-over-UDP as defined in RFC 7510. Segment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological subpaths called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). This document describes the OSPFv2 extensions required for Segment Routing. Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). This document describes the IS-IS extensions that need to be introduced for Segment Routing operating on an MPLS data plane. Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable. Informative References This document provides an overview of the issues associated with the deployment of service functions (such as firewalls, load balancers, etc.) in large-scale environments. The term "service function chaining" is used to describe the definition and instantiation of an ordered list of instances of such service functions, and the subsequent "steering" of traffic flows through those service functions. The set of enabled service function chains reflects operator service offerings and is designed in conjunction with application delivery and service and network policy. This document also identifies several key areas that the Service Function Chaining (SFC) working group will investigate to guide its architectural and protocol work and associated documents. This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFCs) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in the IETF. This document does not propose solutions, protocols, or extensions to existing protocols. This document describes how to use a Service Function Forwarder (SFF) Label (similar to a pseudowire label or VPN label) to indicate the presence of a Service Function Chaining (SFC) Network Service Header (NSH) between an MPLS label stack and the packet original packet/ frame. This allows SFC packets using the NSH to be forwarded between SFFs over an MPLS network, and to select one of multiple SFFs in the destination MPLS node. Cisco Systems, Inc. China Mobile Cisco Systems, Inc. Bell Canada Huawei Orange Mellanox AT&T Nokia Universita di Roma "Tor Vergata" Work in Progress

Contributors The following coauthors provided valuable inputs and text contributions to this document. Orange

mohamed.boucadair@orange.com

Ericsson

joel.halpern@ericsson.com

Cisco System, inc.

shassan@cisco.com

Nokia

wim.henderickx@nokia.com

Futurewei Technologies

haoyu.song@futurewei.com

Authors' Addresses Futurewei Technologies

2330 Central Expressway Santa Clara CA United States of America james.n.guichard@futurewei.com

Nvidia

United States of America jefftant.ietf@gmail.com