rfc9491.original   rfc9491.txt 
SPRING J. Guichard, Ed. Internet Engineering Task Force (IETF) J. Guichard, Ed.
Internet-Draft Futurewei Technologies Request for Comments: 9491 Futurewei Technologies
Intended status: Standards Track J. Tantsura, Ed. Category: Standards Track J. Tantsura, Ed.
Expires: 8 December 2023 Nvidia ISSN: 2070-1721 Nvidia
June 2023 November 2023
Integration of Network Service Header (NSH) and Segment Routing for Integration of the Network Service Header (NSH) and Segment Routing for
Service Function Chaining (SFC) Service Function Chaining (SFC)
draft-ietf-spring-nsh-sr-15
Abstract Abstract
This document describes the integration of the Network Service Header This document describes the integration of the Network Service Header
(NSH) and Segment Routing (SR), as well as encapsulation details, to (NSH) and Segment Routing (SR), as well as encapsulation details, to
efficiently support Service Function Chaining (SFC) while maintaining efficiently support Service Function Chaining (SFC) while maintaining
separation of the service and transport planes as originally intended separation of the service and transport planes as originally intended
by the SFC architecture. by the SFC architecture.
Combining these technologies allows SR to be used for steering Combining these technologies allows SR to be used for steering
packets between Service Function Forwarders (SFF) along a given packets between Service Function Forwarders (SFFs) along a given
Service Function Path (SFP) while NSH has the responsibility for Service Function Path (SFP), whereas the NSH is responsible for
maintaining the integrity of the service plane, the SFC instance maintaining the integrity of the service plane, the SFC instance
context, and any associated metadata. context, and any associated metadata.
This integration demonstrates that NSH and SR can work cooperatively This integration demonstrates that the NSH and SR can work
and provide a network operator with the flexibility to use whichever cooperatively and provide a network operator with the flexibility to
transport technology makes sense in specific areas of their network use whichever transport technology makes sense in specific areas of
infrastructure while still maintaining an end-to-end service plane their network infrastructure while still maintaining an end-to-end
using NSH. service plane using the NSH.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 3 December 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9491.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. SFC Overview and Rationale . . . . . . . . . . . . . . . 3 1.1. SFC Overview and Rationale
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.2. Requirements Language
2. SFC within Segment Routing Networks . . . . . . . . . . . . . 4 2. SFC within Segment Routing Networks
3. NSH-based SFC with SR-MPLS or SRv6 Transport Tunnel . . . . . 5 3. NSH-Based SFC with SR-MPLS or the SRv6 Transport Tunnel
4. SR-based SFC with Integrated NSH Service Plane . . . . . . . 9 4. SR-Based SFC with the Integrated NSH Service Plane
5. Packet Processing for SR-based SFC . . . . . . . . . . . . . 11 5. Packet Processing for SR-Based SFC
5.1. SR-based SFC (SR-MPLS) Packet Processing . . . . . . . . 11 5.1. SR-Based SFC (SR-MPLS) Packet Processing
5.2. SR-based SFC (SRv6) Packet Processing . . . . . . . . . . 11 5.2. SR-Based SFC (SRv6) Packet Processing
6. Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Encapsulation
6.1. NSH using SR-MPLS Transport . . . . . . . . . . . . . . . 12 6.1. NSH Using SR-MPLS Transport
6.2. NSH using SRv6 Transport . . . . . . . . . . . . . . . . 13 6.2. NSH Using SRv6 Transport
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations
8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 14 8. Backwards Compatibility
9. Caching Considerations . . . . . . . . . . . . . . . . . . . 14 9. Caching Considerations
10. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. MTU Considerations
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 11. IANA Considerations
11.1. Protocol Number for NSH . . . . . . . . . . . . . . . . 14 11.1. Protocol Number for the NSH
11.2. SRv6 Endpoint Behavior for NSH . . . . . . . . . . . . . 15 11.2. SRv6 Endpoint Behavior for the NSH
12. Contributing Authors . . . . . . . . . . . . . . . . . . . . 15 12. References
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 12.1. Normative References
13.1. Normative References . . . . . . . . . . . . . . . . . . 16 12.2. Informative References
13.2. Informative References . . . . . . . . . . . . . . . . . 17 Contributors
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses
1. Introduction 1. Introduction
1.1. SFC Overview and Rationale 1.1. SFC Overview and Rationale
The dynamic enforcement of a service-derived and adequate forwarding The dynamic enforcement of a service-derived and adequate forwarding
policy for packets entering a network that supports advanced Service policy for packets entering a network that supports advanced Service
Functions (SFs) has become a key challenge for network operators. Functions (SFs) has become a key challenge for network operators.
For instance, cascading SFs at the 3GPP (Third Generation Partnership For instance, cascading SFs at the Third Generation Partnership
Project) Gi interface (N6 interface in 5G architecture) has shown Project (3GPP) Gi interface (N6 interface in 5G architecture) has
limitations such as 1) redundant classification features must be shown limitations such as 1) redundant classification features that
supported by many SFs to execute their function, 2) some SFs receive must be supported by many SFs to execute their function; 2) some SFs
traffic that they are not supposed to process (e.g., TCP proxies that receive traffic that they are not supposed to process (e.g., TCP
receiving UDP traffic) which inevitably affects their dimensioning proxies receiving UDP traffic), which inevitably affects their
and performance, and 3) an increased design complexity related to the dimensioning and performance; and 3) an increased design complexity
properly ordered invocation of several SFs. related to the properly ordered invocation of several SFs.
In order to solve those problems, and to decouple the service's In order to solve those problems and to decouple the service's
topology from the underlying physical network while allowing for topology from the underlying physical network while allowing for
simplified service delivery, Service Function Chaining (SFC) simplified service delivery, SFC techniques have been introduced
techniques have been introduced [RFC7665]. [RFC7665].
SFC techniques are meant to rationalize the service delivery logic SFC techniques are meant to rationalize the service delivery logic
and master the resulting complexity while optimizing service and reduce the resulting complexity while optimizing service
activation time cycles for operators that need more agile service activation time cycles for operators that need more agile service
delivery procedures to better accommodate ever-demanding customer delivery procedures to better accommodate ever-demanding customer
requirements. SFC allows network operators to dynamically create requirements. SFC allows network operators to dynamically create
service planes that can be used by specific traffic flows. Each service planes that can be used by specific traffic flows. Each
service plane is realized by invoking and chaining the relevant service plane is realized by invoking and chaining the relevant
service functions in the right sequence. [RFC7498] provides an service functions in the right sequence. [RFC7498] provides an
overview of the overall SFC problem space and [RFC7665] specifies an overview of the overall SFC problem space, and [RFC7665] specifies an
SFC data plane architecture. The SFC architecture does not make SFC data plane architecture. The SFC architecture does not make
assumptions on how advanced features (e.g., load-balancing, loose or assumptions on how advanced features (e.g., load balancing, loose or
strict service paths) could be enabled within a domain. Various strict service paths) could be enabled within a domain. Various
deployment options are made available to operators with the SFC deployment options are made available to operators with the SFC
architecture and this approach is fundamental to accommodate various architecture; this approach is fundamental to accommodate various and
and heterogeneous deployment contexts. heterogeneous deployment contexts.
Many approaches can be considered for encoding the information Many approaches can be considered for encoding the information
required for SFC purposes (e.g., communicate a service chain pointer, required for SFC purposes (e.g., communicate a service chain pointer,
encode a list of loose/explicit paths, or disseminate a service chain encode a list of loose/explicit paths, or disseminate a service chain
identifier together with a set of context information). Likewise, identifier together with a set of context information). Likewise,
many approaches can also be considered for the channel to be used to many approaches can also be considered for the channel to be used to
carry SFC-specific information (e.g., define a new header, re-use carry SFC-specific information (e.g., define a new header, reuse
existing packet header fields, or define an IPv6 extension header). existing packet header fields, or define an IPv6 extension header).
Among all these approaches, the IETF created a transport-independent Among all these approaches, the IETF created a transport-independent
SFC encapsulation scheme: NSH [RFC8300]. This design is pragmatic as SFC encapsulation scheme: NSH [RFC8300]. This design is pragmatic,
it does not require replicating the same specification effort as a as it does not require replicating the same specification effort as a
function of underlying transport encapsulation. Moreover, this function of underlying transport encapsulation. Moreover, this
design approach encourages consistent SFC-based service delivery in design approach encourages consistent SFC-based service delivery in
networks enabling distinct transport protocols in various network networks enabling distinct transport protocols in various network
segments or even between SFFs vs SF-SFF hops. segments or even between SFFs vs. SF-SFF hops.
1.2. Requirements Language 1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. SFC within Segment Routing Networks 2. SFC within Segment Routing Networks
[RFC8300] specifies how to encapsulate the Network Service Header [RFC8300] specifies how to encapsulate the NSH directly within a
directly within a link-layer header. In this document, we assign an link-layer header. In this document, IANA has assigned IP protocol
IP protocol number [TBA1] for the NSH, so that it can also be number 145 for the NSH so that it can also be encapsulated directly
encapsulated directly within an IP header. The procedures that within an IP header. The procedures that follow make use of this
follow make use of this property. property.
As described in [RFC8402], SR leverages the source routing technique. As described in [RFC8402], SR leverages the source-routing technique.
Concretely, a node steers a packet through an SR policy instantiated Concretely, a node steers a packet through an SR policy instantiated
as an ordered list of instructions called segments. While initially as an ordered list of instructions called segments. While initially
designed for policy-based source routing, SR also finds its designed for policy-based source routing, SR also finds its
application in supporting SFC application in supporting SFC [SERVICE-PROGRAMMING].
[I-D.ietf-spring-sr-service-programming].
The two SR data plane encapsulations, namely SR-MPLS [RFC8660] and The two SR data plane encapsulations, namely SR-MPLS [RFC8660] and
SRv6 [RFC8754], can both encode an SF as a segment so that an SFC can Segment Routing over IPv6 (SRv6) [RFC8754], can encode an SF as a
be specified as a segment list. Nevertheless, and as discussed in segment so that a service function chain can be specified as a
[RFC7498], traffic steering is only a subset of the issues that segment list. Nevertheless, and as discussed in [RFC7498], traffic
motivated the design of the SFC architecture. Further considerations steering is only a subset of the issues that motivated the design of
such as simplifying classification at intermediate SFs and allowing the SFC architecture. Further considerations, such as simplifying
for coordinated behaviors among SFs by means of supplying context classification at intermediate SFs and allowing for coordinated
information (a.k.a. metadata) should be considered when designing an behaviors among SFs by means of supplying context information (a.k.a.
SFC data plane solution. 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 While each scheme (i.e., NSH-based SFC and SR-based SFC) can work
independently, this document describes how the two can be used independently, this document describes how the two can be used
together in concert and complement each other through two together in concert and to complement each other through two
representative application scenarios. Both application scenarios may representative application scenarios. Both application scenarios may
be supported using either SR-MPLS or SRv6: be supported using either SR-MPLS or SRv6:
* NSH-based SFC with SR-based transport plane: in this scenario SR- NSH-based SFC with the SR-based transport plane:
MPLS or SRv6 provides the transport encapsulation between SFFs In this scenario, SR-MPLS or SRv6 provides the transport
while NSH is used to convey and trigger SFC policies. encapsulation between SFFs, while the NSH is used to convey and
trigger SFC policies.
* SR-based SFC with integrated NSH service plane: in this scenario SR-based SFC with the integrated NSH service plane:
each service hop of the SFC is represented as a segment of the SR In this scenario, each service hop of the service function chain
segment-list. SR is thus responsible for steering traffic through is represented as a segment of the SR segment list. SR is thus
the necessary SFFs as part of the segment routing path while NSH responsible for steering traffic through the necessary SFFs as
is responsible for maintaining the service plane and holding the part of the segment routing path, while the NSH is responsible for
SFC instance context (including associated metadata). maintaining the service plane and holding the SFC instance context
(including associated metadata).
It is of course possible to combine both of these two scenarios to Of course, it is possible to combine both of these two scenarios to
support specific deployment requirements and use cases. support specific deployment requirements and use cases.
A classifier MUST use an NSH Service Path Identifier (SPI) per SR A classifier MUST use one NSH Service Path Identifier (SPI) for each
policy so that different traffic flows that use the same NSH Service SR policy so that different traffic flows can use the same NSH
Function Path (SFP) but different SR policy can coexist on the same Service Function Path (SFP) and different SR policies can coexist on
SFP without conflict during SFF processing. the same SFP without conflict during SFF processing.
3. NSH-based SFC with SR-MPLS or SRv6 Transport Tunnel 3. NSH-Based SFC with SR-MPLS or the SRv6 Transport Tunnel
Because of the transport-independent nature of NSH-based service Because of the transport-independent nature of NSH-based service
function chains, it is expected that the NSH has broad applicability function chains, it is expected that the NSH has broad applicability
across different network domains (e.g., access, core). By way of across different network domains (e.g., access, core). By way of
illustration the various SFs involved in a service function chain may illustration, the various SFs involved in a service function chain
be available in a single data center, or spread throughout multiple may be available in a single data center or spread throughout
locations (e.g., data centers, different Points of Presence (POPs)), multiple locations (e.g., data centers, different Points of Presence
depending upon the network operator preference and/or availability of (POPs)), depending upon the network operator preference and/or
service resources. Regardless of where the SFs are deployed it is availability of service resources. Regardless of where the SFs are
necessary to provide traffic steering through a set of SFFs, and when deployed, it is necessary to provide traffic steering through a set
NSH and SR are integrated, this is provided by SR-MPLS or SRv6. 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 The following three figures provide an example of an SFC-established
flow F that has SF instances located in different data centers, DC1 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 and DC2. For the purpose of illustration, let the SFC's NSH SPI be
100 and the initial Service Index (SI) be 255. 100 and the initial Service Index (SI) be 255.
Referring to Figure 1, packets of flow F in DC1 are classified into Referring to Figure 1, packets of flow F in DC1 are classified into
an NSH-based SFC and encapsulated after classification as <Inner an NSH-based service function chain, encapsulated after
Pkt><NSH: SPI 100, SI 255><Outer-transport> and forwarded to SFF1 classification as <Inner Pkt><NSH: SPI 100, SI 255><Outer-transport>,
(which is the first SFF hop for this service function chain). 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 After removing the outer transport encapsulation, SFF1 uses the SPI
and SI carried within the NSH encapsulation to determine that it and SI carried within the NSH encapsulation to determine that it
should forward the packet to SF1. SF1 applies its service, should forward the packet to SF1. SF1 applies its service,
decrements the SI by 1, and returns the packet to SFF1. SFF1 decrements the SI by 1, and returns the packet to SFF1. Therefore,
therefore has <SPI 100, SI 254> when the packet comes back from SF1. SFF1 has <SPI 100, SI 254> when the packet comes back from SF1. SFF1
SFF1 does a lookup on <SPI 100, SI 254> which results in <next-hop: does a lookup on <SPI 100, SI 254>, which results in <next-hop:
DC1-GW1> and forwards the packet to DC1-GW1. DC1-GW1> and forwards the packet to DC1-GW1.
+--------------------------- DC1 ----------------------------+ +--------------------------- DC1 ----------------------------+
| +-----+ | | +-----+ |
| | SF1 | | | | SF1 | |
| +--+--+ | | +--+--+ |
| | | | | |
| | | | | |
| +------------+ | +------------+ | | +------------+ | +------------+ |
| | N(100,255) | | | N(100,254) | | | | N(100,255) | | | N(100,254) | |
skipping to change at page 6, line 41 skipping to change at line 260
|+------------+ +------+ +---------+ | |+------------+ +------+ +---------+ |
| | | |
| +------------+ +------------+ | | +------------+ +------------+ |
| | N(100,255) | | N(100,254) | | | | N(100,255) | | N(100,254) | |
| +------------+ +------------+ | | +------------+ +------------+ |
| | F:Inner Pkt| | F:Inner Pkt| | | | F:Inner Pkt| | F:Inner Pkt| |
| +------------+ +------------+ | | +------------+ +------------+ |
| | | |
+------------------------------------------------------------+ +------------------------------------------------------------+
Figure 1: SR for inter-DC SFC - Part 1 Figure 1: SR for Inter-DC SFC - Part 1
Referring now to Figure 2, DC1-GW1 performs a lookup using the Referring now to Figure 2, DC1-GW1 performs a lookup using the
information conveyed in the NSH which results in <next-hop: DC2-GW1, information conveyed in the NSH, which results in <next-hop: DC2-GW1,
encapsulation: SR>. The SR encapsulation, which may be SR-MPLS or encapsulation: SR>. The SR encapsulation, which may be SR-MPLS or
SRv6, has the SR segment-list to forward the packet across the inter- SRv6, has the SR segment list to forward the packet across the inter-
DC network to DC2. DC network to DC2.
+----------- Inter DC ----------------+ +----------- Inter DC ----------------+
(4) | (5) | (4) | (5) |
+------+ ----> | +---------+ ----> +---------+ | +------+ ----> | +---------+ ----> +---------+ |
| | NSH | | | SR | | | | | NSH | | | SR | | |
+ SFF1 +----------|-+ DC1-GW1 +-------------+ DC2-GW1 + | + SFF1 +----------|-+ DC1-GW1 +-------------+ DC2-GW1 + |
| | | | | | | | | | | | | | | |
+------+ | +---------+ +---------+ | +------+ | +---------+ +---------+ |
| | | |
| +------------+ | | +------------+ |
| | S(DC2-GW1) | | | | S(DC2-GW1) | |
| +------------+ | | +------------+ |
| | N(100,254) | | | | N(100,254) | |
| +------------+ | | +------------+ |
| | F:Inner Pkt| | | | F:Inner Pkt| |
| +------------+ | | +------------+ |
+-------------------------------------+ +-------------------------------------+
Figure 2: SR for inter-DC SFC - Part 2 Figure 2: SR for Inter-DC SFC - Part 2
When the packet arrives at DC2, as shown in Figure 3, the SR When the packet arrives at DC2, as shown in Figure 3, the SR
encapsulation is removed and DC2-GW1 performs a lookup on the NSH encapsulation is removed, and DC2-GW1 performs a lookup on the NSH,
which results in next hop: SFF2. When SFF2 receives the packet, it 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 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, the packet to SF2. SF2 applies its service, decrements the SI by 1,
and returns the packet to SFF2. SFF2 therefore has <NSH: SPI 100, SI and returns the packet to SFF2. Therefore, SFF2 has <NSH: SPI 100,
253> when the packet comes back from SF2. SFF2 does a lookup on 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 <NSH: SPI 100, SI 253>, which results in the end of the service
function chain. function chain.
+------------------------ DC2 ----------------------+ +------------------------ DC2 ----------------------+
| +-----+ | | +-----+ |
| | SF2 | | | | SF2 | |
| +--+--+ | | +--+--+ |
| | | | | |
| | | | | |
| +------------+ | +------------+ | | +------------+ | +------------+ |
| | N(100,254) | | | N(100,253) | | | | N(100,254) | | | N(100,253) | |
skipping to change at page 8, line 32 skipping to change at line 324
| | | | | | | | | | | | | | | |
+---------+ | +----------+ +------+ | +---------+ | +----------+ +------+ |
| | | |
| +------------+ +------------+ | | +------------+ +------------+ |
| | N(100,254) | | F:Inner Pkt| | | | N(100,254) | | F:Inner Pkt| |
| +------------+ +------------+ | | +------------+ +------------+ |
| | F:Inner Pkt| | | | F:Inner Pkt| |
| +------------+ | | +------------+ |
+---------------------------------------------------+ +---------------------------------------------------+
Figure 3: SR for inter-DC SFC - Part 3 Figure 3: SR for Inter-DC SFC - Part 3
The benefits of this scheme are listed hereafter: The benefits of this scheme are listed hereafter:
* The network operator is able to take advantage of the transport- * The network operator is able to take advantage of the transport-
independent nature of the NSH encapsulation, while the service is independent nature of the NSH encapsulation while the service is
provisioned end-to-end. provisioned end-to-end.
* The network operator is able to take advantage of the traffic * The network operator is able to take advantage of the traffic-
steering (traffic engineering) capability of SR where appropriate. steering (traffic-engineering) capability of SR where appropriate.
* Clear responsibility division and scope between NSH and SR. * Clear responsibility division and scope between the NSH and SR.
Note that this scenario is applicable to any case where multiple Note that this scenario is applicable to any case where multiple
segments of a service function chain are distributed across multiple segments of a service function chain are distributed across multiple
domains or where traffic-engineered paths are necessary between SFFs domains or where traffic-engineered paths are necessary between SFFs
(strict forwarding paths for example). Further, note that the above (strict forwarding paths, for example). Further, note that the above
example can also be implemented using end-to-end segment routing 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 between SFF1 and SFF2. (As such, DC-GW1 and DC-GW2 are forwarding
packets based on segment routing instructions and are not looking at the packets based on segment routing instructions and are not looking
the NSH header for forwarding.) at the NSH header for forwarding.)
4. SR-based SFC with Integrated NSH Service Plane 4. SR-Based SFC with the Integrated NSH Service Plane
In this scenario we assume that the SFs are NSH-aware and therefore In this scenario, we assume that the SFs are NSH-aware; therefore, it
it should not be necessary to implement an SFC proxy to achieve SFC. should not be necessary to implement an SFC proxy to achieve SFC.
The operation relies upon SR-MPLS or SRv6 to perform SFF-SFF The operation relies upon SR-MPLS or SRv6 to perform SFF-SFF
transport and NSH to provide the service plane between SFs thereby transport and the NSH to provide the service plane between SFs,
maintaining SFC context (e.g., the service plane path referenced by thereby maintaining SFC context (e.g., the service plane path
the SPI) and any associated metadata. referenced by the SPI) and any associated metadata.
When a service function chain is established, a packet associated When a service function chain is established, a packet associated
with that chain will first carry an NSH that will be used to maintain 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 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 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 forwarding the packet to the next-hop SFFs. The packet is then
encapsulated using the SR header and forwarded in the SR domain encapsulated using the SR header and forwarded in the SR domain
following normal SR operations. following normal SR operations.
When a packet has to be forwarded to an SF attached to an SFF, the 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 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 [RFC8402]. the SF. In the case of SR-MPLS, this will be a Prefix-SID [RFC8402].
In the case of SRv6, the behavior described within this document is In the case of SRv6, the behavior described within this document is
assigned the name END.NSH, and section 9.2 requests allocation of a assigned the name END.NSH, and Section 11.2 describes the allocation
code point by IANA. The result of this lookup allows the SFF to of the code point by IANA. The result of this lookup allows the SFF
retrieve the next hop context between the SFF and SF (e.g., the to retrieve the next-hop context between the SFF and SF (e.g., the
destination MAC address in case Ethernet encapsulation is used destination Media Access Control (MAC) address in case Ethernet
between SFF and SF). In addition, the SFF strips the SR information encapsulation is used between the SFF and SF). In addition, the SFF
from the packet, updates the SR information, and saves it to a cache strips the SR information from the packet, updates the SR
indexed by the NSH Service Path Identifier (SPI) and the Service information, and saves it to a cache indexed by the NSH Service Path
Index (SI) decremented by 1. This saved SR information is used to Identifier (SPI) and the Service Index (SI) decremented by 1. This
encapsulate and forward the packet(s) coming back from the SF. 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 behavior of remembering the SR segment list occurs at the end of
the regularly defined logic. The behavior of reattaching the the regularly defined logic. The behavior of reattaching the segment
segment-list occurs before the SR process of forwarding the packet to list occurs before the SR process of forwarding the packet to the
the next entry in the segment-list. Both behaviors are further next entry in the segment list. Both behaviors are further detailed
detailed in section 5. in Section 5.
When the SF receives the packet, it processes it as usual. When the 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 SF is co-resident with a classifier, the already-processed packet may
be re-classified. The SF sends the packet back to the SFF. Once the be reclassified. The SF sends the packet back to the SFF. Once the
SFF receives this packet, it extracts the SR information using 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 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 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 to the next segment in the segment list. The lookup in the SFF cache
might fail if re-classification at the SF changed the NSH SPI and/or 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 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. SFF must generate an error and drop the packet.
Figure 4 illustrates an example of this scenario. Figure 4 illustrates an example of this scenario.
+-----+ +-----+ +-----+ +-----+
| SF1 | | SF2 | | SF1 | | SF2 |
+--+--+ +--+--+ +--+--+ +--+--+
| | | |
| | | |
+-----------+ | +-----------+ +-----------+ | +-----------+ +-----------+ | +-----------+ +-----------+ | +-----------+
|N(100,255) | | |N(100,254) | |N(100,254) | | |N(100,253) | , |N(100,255) | | |N(100,254) | |N(100,254) | | |N(100,253) |
+-----------+ | +-----------+ +-----------+ | +-----------+ +-----------+ | +-----------+ +-----------+ | +-----------+
|F:Inner Pkt| | |F:Inner Pkt| |F:Inner Pkt| | |F:Inner Pkt| |F:Inner Pkt| | |F:Inner Pkt| |F:Inner Pkt| | |F:Inner Pkt|
+-----------+ | +-----------+ +-----------+ | +-----------+ +-----------+ | +-----------+ +-----------+ | +-----------+
(2) ^ | (3) | (5) ^ | (6) | (2) ^ | (3) | (5) ^ | (6) |
| | | | | | | | | | | |
| | | | | | | | | | | |
(1) | | v (4) | | v (7) (1) | | v (4) | | v (7)
+------------+ ---> +-+----+ ----> +---+--+ --> +------------+ ---> +-+----+ ----> +---+--+ -->
| | NSHoverSR | | NSHoverSR | | IP | | NSHoverSR | | NSHoverSR | | IP
| Classifier +-----------+ SFF1 +---------------------+ SFF2 | | Classifier +-----------+ SFF1 +---------------------+ SFF2 |
skipping to change at page 11, line 5 skipping to change at line 431
+------------+ +------------+ +------------+ +------------+
| S(SF2) | | F:Inner Pkt| | S(SF2) | | F:Inner Pkt|
+------------+ +------------+ +------------+ +------------+
| N(100,255) | | N(100,255) |
+------------+ +------------+
| F:Inner Pkt| | F:Inner Pkt|
+------------+ +------------+
Figure 4: NSH over SR for SFC Figure 4: NSH over SR for SFC
The benefits of this scheme include: The benefits of this scheme include the following:
* It is economically sound for SF vendors to only support one * It is economically sound for SF vendors to only support one
unified SFC solution. The SF is unaware of the SR. unified SFC solution. The SF is unaware of the SR.
* It simplifies the SFF (i.e., the SR router) by nullifying the * It simplifies the SFF (i.e., the SR router) by nullifying the
needs for re-classification and SR proxy. needs for reclassification and SR proxy.
* SR is also used for forwarding purposes including between SFFs. * SR is also used for forwarding purposes, including between SFFs.
* It takes advantage of SR to eliminate the NSH forwarding state in * It takes advantage of SR to eliminate the NSH forwarding state in
SFFs. This applies each time strict or loose SFPs are in use. 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 * It requires no interworking, as would be the case if SR-MPLS-based
SFC and NSH-based SFC were deployed as independent mechanisms in SFC and NSH-based SFC were deployed as independent mechanisms in
different parts of the network. different parts of the network.
5. Packet Processing for SR-based SFC 5. Packet Processing for SR-Based SFC
This section describes the End.NSH behavior (SRv6), Prefix SID This section describes the End.NSH behavior (SRv6), Prefix-SID
behavior (SR-MPLS), and NSH processing logic. behavior (SR-MPLS), and NSH processing logic.
5.1. SR-based SFC (SR-MPLS) Packet Processing 5.1. SR-Based SFC (SR-MPLS) Packet Processing
When an SFF receives a packet destined to S and S is a local prefix 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 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 stack) from the packet, updates the SR information, and saves it to a
cache indexed by the NSH Service Path Identifier (SPI) and the cache indexed by the NSH Service Path Identifier (SPI) and the
Service Index (SI) decremented by 1. This saved SR information is Service Index (SI) decremented by 1. This saved SR information is
used to re-encapsulate and forward the packet(s) coming back from the used to re-encapsulate and forward the packet(s) coming back from the
SF. SF.
5.2. SR-based SFC (SRv6) Packet Processing 5.2. SR-Based SFC (SRv6) Packet Processing
This section describes the End.NSH behavior and NSH processing logic This section describes the End.NSH behavior and NSH processing logic
for SRv6. The pseudocode is shown below. for SRv6. The pseudocode is shown below.
When N receives a packet destined to S and S is a local End.NSH SID, 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 [RFC8754] section the processing is the same as that specified by [RFC8754],
4.3.1.1, up through line S.15. Section 4.3.1.1, up through line S15.
After S.15, if S is a local End.NSH SID, then: After S15, if S is a local End.NSH SID, then:
S15.1. Remove and store IPv6 and SRH headers in local cache indexed S15.1. Remove and store IPv6 and SRH headers in local cache
by <NSH: service-path-id, service-index -1> 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>
S15.2. Submit the packet to the NSH FIB lookup and transmit to the | Note: The End.NSH behavior interrupts the normal SRH packet
destination associated with <NSH: service-path-id, service-index> | processing, as described in [RFC8754], Section 4.3.1.1, which
Note: The End.NSH behavior interrupts the normal SRH packet | does not continue to S16 at this time.
processing as described in [RFC8754] section 4.3.1.1, which does not
continue to S16 at this time.
When a packet is returned to the SFF from the SF, reattach the cached 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- IPv6 and SRH headers based on the <NSH: service-path-id, service-
index> from the NSH header. Then resume processing from [RFC8754] index> from the NSH header. Then, resume processing from [RFC8754],
section 4.3.1.1 with line S.16. Section 4.3.1.1 with line S16.
6. Encapsulation 6. Encapsulation
6.1. NSH using SR-MPLS Transport 6.1. NSH Using SR-MPLS Transport
SR-MPLS instantiates Segment IDs (SIDs) as MPLS labels and therefore SR-MPLS instantiates segment identifiers (SIDs) as MPLS labels;
the segment routing header is a stack of MPLS labels. therefore, the segment routing header is a stack of MPLS labels.
When carrying NSH within an SR-MPLS transport, the full encapsulation When carrying an NSH within an SR-MPLS transport, the full
headers are as illustrated in Figure 5. encapsulation headers are as illustrated in Figure 5.
+------------------+ +------------------+
~ MPLS-SR Labels ~ ~ SR-MPLS Labels ~
+------------------+ +------------------+
| NSH Base Hdr | | NSH Base Hdr |
+------------------+ +------------------+
| Service Path Hdr | | Service Path Hdr |
+------------------+ +------------------+
~ Metadata ~ ~ Metadata ~
+------------------+ +------------------+
Figure 5: NSH using SR-MPLS Transport Figure 5: NSH Using SR-MPLS Transport
As described in [RFC8402], the IGP signaling extension for IGP-Prefix As described in [RFC8402], "[t]he IGP signaling extension for IGP-
segment includes a flag to indicate whether directly connected Prefix segment includes a flag to indicate whether directly connected
neighbors of the node on which the prefix is attached should perform neighbors of the node on which the prefix is attached should perform
the NEXT operation or the CONTINUE operation when processing the SID. the NEXT operation or the CONTINUE operation when processing the
When NSH is carried beneath SR-MPLS it is necessary to terminate the SID." When an NSH is carried beneath SR-MPLS, it is necessary to
NSH-based SFC at the tail-end node of the SR-MPLS label stack. This terminate the NSH-based SFC at the tail-end node of the SR-MPLS label
can be achieved using either the NEXT or CONTINUE operation. 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 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 path, it is necessary to provide an indication to the tail end that
NSH follows the SR-MPLS label stack as described by [RFC8596]. the NSH follows the SR-MPLS label stack as described by [RFC8596].
If the CONTINUE operation is to be used, this is the equivalent of If the CONTINUE operation is to be used, this is the equivalent of
MPLS Ultimate Hop Popping (UHP) and therefore it is necessary to MPLS Ultimate Hop Popping (UHP); therefore, it is necessary to ensure
ensure that the penultimate hop node does not pop the top label of that the penultimate hop node does not pop the top label of the SR-
the SR-MPLS label stack and thereby expose NSH to the wrong SFF. MPLS label stack and thereby expose the NSH to the wrong SFF. This
This is realized by setting No-PHP flag in Prefix-SID Sub-TLV is realized by setting the No Penultimate Hop Popping (No-PHP) flag
[RFC8667], [RFC8665]. It is RECOMMENDED that a specific prefix-SID in Prefix-SID Sub-TLV [RFC8667] [RFC8665]. It is RECOMMENDED that a
be allocated at each node for use by the SFC application for this specific Prefix-SID be allocated at each node for use by the SFC
purpose. application for this purpose.
6.2. NSH using SRv6 Transport 6.2. NSH Using SRv6 Transport
When carrying NSH within an SRv6 transport the full encapsulation is When carrying a NSH within an SRv6 transport, the full encapsulation
as illustrated in Figure 6. is as illustrated in Figure 6.
0 1 2 3 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 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 | | Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Entry | Flags | Tag | S | Last Entry | Flags | Tag | S
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e
| | g | | g
| Segment List[0] (128-bit IPv6 address) | m | Segment List[0] (128-bit IPv6 address) | m
| | e | | e
| | n | | n
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ t +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ t
| | | |
| | R | | R
~ ... ~ o ~ ... ~ o
| | u | | u
| | t | | t
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i
| | n | | n
| Segment List[n] (128-bit IPv6 address) | g | Segment List[n] (128-bit IPv6 address) | g
| | | |
| | S | | S
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R
// // H // // H
// Optional Type Length Value objects (variable) // // Optional Type Length Value objects (variable) //
// // // //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N
| Service Path Identifier | Service Index | S | Service Path Identifier | Service Index | S
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H
| | | |
~ Variable-Length Context Headers (opt.) ~ ~ Variable-Length Context Headers (opt.) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: NSH using SRv6 Transport
Encapsulation of NSH following SRv6 is indicated by the IP protocol Figure 6: NSH Using SRv6 Transport
number for NSH in the Next Header of the SRH.
Encapsulation of the NSH following SRv6 is indicated by the IP
protocol number for the NSH in the Next Header of the SRH.
7. Security Considerations 7. Security Considerations
Generic SFC-related security considerations are discussed in Generic SFC-related security considerations are discussed in
[RFC7665]. [RFC7665].
NSH-specific security considerations are discussed in [RFC8300]. NSH-specific security considerations are discussed in [RFC8300].
Generic segment routing related security considerations are discussed Generic security considerations related to segment routing are
in section 7 of [RFC8754] and section 5 of [RFC8663]. discussed in Section 7 of [RFC8754] and Section 5 of [RFC8663].
8. Backwards Compatibility 8. Backwards Compatibility
For SRv6/IPv6, if a processing node does not recognize NSH it should For SRv6/IPv6, if a processing node does not recognize the NSH, it
follow the procedures described in section 4 of [RFC8200]. For SR- should follow the procedures described in Section 4 of [RFC8200].
MPLS, if a processing node does not recognize NSH it should follow For SR-MPLS, if a processing node does not recognize the NSH, it
the procedures laid out in section 3.18 of [RFC3031]. should follow the procedures laid out in Section 3.18 of [RFC3031].
9. Caching Considerations 9. Caching Considerations
The cache mechanism must remove cached entries at an appropriate time The cache mechanism must remove cached entries at an appropriate time
determined by the implementation. Further, an implementation MAY determined by the implementation. Further, an implementation MAY
allow network operators to set the said time value. In the case a allow network operators to set the said time value. In the case
packet arriving from an SF does not have a matching cached entry, the where a packet arriving from an SF does not have a matching cached
SFF SHOULD log this event, and MUST drop the packet. entry, the SFF SHOULD log this event and MUST drop the packet.
10. MTU Considerations 10. MTU Considerations
Aligned with Section 5 of [RFC8300] and Section 5.3 of [RFC8754], it Aligned with Section 5 of [RFC8300] and Section 5.3 of [RFC8754], it
is RECOMMENDED for network operators to increase the underlying MTU is RECOMMENDED for network operators to increase the underlying MTU
so that SR/NSH traffic is forwarded within an SR domain without so that SR/NSH traffic is forwarded within an SR domain without
fragmentation. fragmentation.
11. IANA Considerations 11. IANA Considerations
11.1. Protocol Number for NSH 11.1. Protocol Number for the NSH
IANA is requested to assign a protocol number TBA1 for the NSH [RFC8300] from the
"Assigned Internet Protocol Numbers" registry available at
https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
+---------+---------+--------------+---------------+----------------+
| Decimal | Keyword | Protocol | IPv6 | Reference |
| | | | Extension | |
| | | | Header | |
+---------+---------+--------------+---------------+----------------+
| TBA1 | NSH | Network | N | [This Document]|
| | | Service | | |
| | | Header | | |
+---------+---------+--------------+---------------+----------------+
11.2. SRv6 Endpoint Behavior for NSH
This I-D requests IANA to allocate, within the "SRv6 Endpoint Behaviors"
sub-registry belonging to the top-level "Segment-routing with IPv6 data
plane (SRv6) Parameters" registry, the following allocations:
Value Description Reference IANA has assigned protocol number 145 for the NSH [RFC8300] in the
-------------------------------------------------------------- "Assigned Internet Protocol Numbers" registry
TBA2 End.NSH - NSH Segment [This.ID] <https://www.iana.org/assignments/protocol-numbers/>.
12. Contributing Authors +=========+=========+================+================+===========+
The following co-authors, along with their respective affiliations at | Decimal | Keyword | Protocol | IPv6 Extension | Reference |
the time of publication, provided valuable inputs and text contributions | | | | Header | |
to this document. +=========+=========+================+================+===========+
| 145 | NSH | Network | N | RFC 9491 |
| | | Service Header | | |
+---------+---------+----------------+----------------+-----------+
Mohamed Boucadair Table 1: Assigned Internet Protocol Numbers Registry
Orange
mohamed.boucadair@orange.com
Joel Halpern 11.2. SRv6 Endpoint Behavior for the NSH
Ericsson
joel.halpern@ericsson.com
Syed Hassan IANA has allocated the following value in the "SRv6 Endpoint
Cisco System, inc. Behaviors" subregistry under the "Segment Routing" registry:
shassan@cisco.com
Wim Henderickx +=======+========+===================+===========+============+
Nokia | Value | Hex | Endpoint Behavior | Reference | Change |
wim.henderickx@nokia.com | | | | | Controller |
+=======+========+===================+===========+============+
| 84 | 0x0054 | End.NSH - NSH | RFC 9491 | IETF |
| | | Segment | | |
+-------+--------+-------------------+-----------+------------+
Haoyu Song Table 2: SRv6 Endpoint Behaviors Subregistry
Futurewei Technologies
haoyu.song@futurewei.com
13. References 12. References
13.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001, DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/info/rfc3031>. <https://www.rfc-editor.org/info/rfc3031>.
skipping to change at page 17, line 43 skipping to change at line 705
Bashandy, A., Gredler, H., and B. Decraene, "IS-IS Bashandy, A., Gredler, H., and B. Decraene, "IS-IS
Extensions for Segment Routing", RFC 8667, Extensions for Segment Routing", RFC 8667,
DOI 10.17487/RFC8667, December 2019, DOI 10.17487/RFC8667, December 2019,
<https://www.rfc-editor.org/info/rfc8667>. <https://www.rfc-editor.org/info/rfc8667>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>. <https://www.rfc-editor.org/info/rfc8754>.
13.2. Informative References 12.2. Informative References
[I-D.ietf-spring-sr-service-programming]
Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C.,
Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and
S. Salsano, "Service Programming with Segment Routing",
Work in Progress, Internet-Draft, draft-ietf-spring-sr-
service-programming-07, 15 February 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
sr-service-programming-07>.
[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
Service Function Chaining", RFC 7498, Service Function Chaining", RFC 7498,
DOI 10.17487/RFC7498, April 2015, DOI 10.17487/RFC7498, April 2015,
<https://www.rfc-editor.org/info/rfc7498>. <https://www.rfc-editor.org/info/rfc7498>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665, Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015, DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>. <https://www.rfc-editor.org/info/rfc7665>.
[RFC8596] Malis, A., Bryant, S., Halpern, J., and W. Henderickx, [RFC8596] Malis, A., Bryant, S., Halpern, J., and W. Henderickx,
"MPLS Transport Encapsulation for the Service Function "MPLS Transport Encapsulation for the Service Function
Chaining (SFC) Network Service Header (NSH)", RFC 8596, Chaining (SFC) Network Service Header (NSH)", RFC 8596,
DOI 10.17487/RFC8596, June 2019, DOI 10.17487/RFC8596, June 2019,
<https://www.rfc-editor.org/info/rfc8596>. <https://www.rfc-editor.org/info/rfc8596>.
[SERVICE-PROGRAMMING]
Clad, F., Ed., Xu, X., Ed., Filsfils, C., Bernier, D., Li,
C., Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W.,
and S. Salsano, "Service Programming with Segment
Routing", Work in Progress, Internet-Draft, draft-ietf-
spring-sr-service-programming-08, 21 August 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
sr-service-programming-08>.
Contributors
The following coauthors provided valuable inputs and text
contributions to this document.
Mohamed Boucadair
Orange
Email: mohamed.boucadair@orange.com
Joel Halpern
Ericsson
Email: joel.halpern@ericsson.com
Syed Hassan
Cisco System, inc.
Email: shassan@cisco.com
Wim Henderickx
Nokia
Email: wim.henderickx@nokia.com
Haoyu Song
Futurewei Technologies
Email: haoyu.song@futurewei.com
Authors' Addresses Authors' Addresses
James N Guichard (editor) James N Guichard (editor)
Futurewei Technologies Futurewei Technologies
2330 Central Express Way 2330 Central Expressway
Santa Clara, Santa Clara,
United States of America United States of America
Email: james.n.guichard@futurewei.com Email: james.n.guichard@futurewei.com
Jeff Tantsura (editor) Jeff Tantsura (editor)
Nvidia Nvidia
United States of America United States of America
Email: jefftant.ietf@gmail.com Email: jefftant.ietf@gmail.com
 End of changes. 100 change blocks. 
318 lines changed or deleted 330 lines changed or added

This html diff was produced by rfcdiff 1.48.