< draft-ietf-spring-nsh-sr-03.txt   draft-ietf-spring-nsh-sr-04.txt >
SPRING J. Guichard, Ed. SPRING J. Guichard, Ed.
Internet-Draft Futurewei Technologies Internet-Draft Futurewei Technologies
Intended status: Standards Track J. Tantsura, Ed. Intended status: Standards Track J. Tantsura, Ed.
Expires: March 28, 2021 Apstra inc. Expires: June 14, 2021 Apstra inc.
September 24, 2020 December 11, 2020
Integration of Network Service Header (NSH) and Segment Routing for Integration of Network Service Header (NSH) and Segment Routing for
Service Function Chaining (SFC) Service Function Chaining (SFC)
draft-ietf-spring-nsh-sr-03 draft-ietf-spring-nsh-sr-04
Abstract Abstract
This document describes two application scenarios where Network This document describes the integration of Network Service Header
Service Header (NSH) and Segment Routing (SR) can be deployed (NSH) [RFC8300] and Segment Routing (SR) [RFC8402], as well as
together to support Service Function Chaining (SFC) in an efficient encapsulation details, to support Service Function Chaining (SFC)
manner while maintaining separation of the service and transport [RFC7665] in an efficient manner while maintaining separation of the
planes as originally intended by the SFC architecture. service and transport planes as originally intended by the SFC
architecture.
In both scenarios, SR is responsible for steering packets between Combining these technologies allows SR to be used for steering
SFFs along a given Service Function Path (SFP) while NSH is packets between Service Function Forwarders (SFF) along a given
responsible for maintaining the integrity of the service plane, the Service Function Path (SFP) while NSH has the responsibility for
SFC instance context, and any associated metadata. 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 The integration described in this document demonstrates that NSH and
jointly and complement each other leaving the network operator with SR can work jointly and complement each other leaving the network
the flexibility to use whichever transport technology makes sense in operator with the flexibility to use whichever transport technology
specific areas of their network infrastructure, and still maintain an makes sense in specific areas of their network infrastructure, and
end-to-end service plane using NSH. still maintain an end-to-end service plane using NSH.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 28, 2021. This Internet-Draft will expire on June 14, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 26 skipping to change at page 2, line 26
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. SFC Overview and Rationale . . . . . . . . . . . . . . . 2 1.1. SFC Overview and Rationale . . . . . . . . . . . . . . . 2
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. SFC within Segment Routing Networks . . . . . . . . . . . . . 4 2. SFC within Segment Routing Networks . . . . . . . . . . . . . 4
3. NSH-based SFC with SR-based Transport Tunnel . . . . . . . . 5 3. NSH-based SFC with SR-MPLS or SRv6 Transport Tunnel . . . . . 5
4. SR-based SFC with Integrated NSH Service Plane . . . . . . . 9 4. SR-based SFC with Integrated NSH Service Plane . . . . . . . 9
5. Encapsulation Details . . . . . . . . . . . . . . . . . . . . 11 5. Packet Processing Details . . . . . . . . . . . . . . . . . . 11
5.1. NSH using SR-MPLS Transport . . . . . . . . . . . . . . . 11 6. Encapsulation Details . . . . . . . . . . . . . . . . . . . . 11
5.2. NSH using SRv6 Transport . . . . . . . . . . . . . . . . 12 6.1. NSH using SR-MPLS Transport . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6.2. NSH using SRv6 Transport . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7.1. UDP Port Number for NSH . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7.2. Protocol Number for NSH . . . . . . . . . . . . . . . . . 14 8.1. UDP Port Number for NSH . . . . . . . . . . . . . . . . . 14
8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 14 8.2. Protocol Number for NSH . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.3. SRv6 Endpoint Behavior for NSH . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
1.1. SFC Overview and Rationale 1.1. SFC Overview and Rationale
The dynamic enforcement of a service-derived, 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.
Particularly, cascading SFs at the so-called Third Generation Particularly, cascading SFs at the so-called Third Generation
Partnership Project (3GPP) Gi interface in the context of mobile Partnership Project (3GPP) Gi interface (N6 interface in 5G
network infrastructure, have shown their limitations, such as the architecture) in the context of mobile network infrastructure, have
same redundant classification features must be supported by many SFs shown their limitations, such as the same redundant classification
to execute their function, some SFs are receiving traffic that they features must be supported by many SFs to execute their function,
are not supposed to process (e.g., TCP proxies receiving UDP some SFs receive traffic that they are not supposed to process (e.g.,
traffic), which inevitably affects their dimensioning and TCP proxies receiving UDP traffic), which inevitably affects their
performance, an increased design complexity related to the properly dimensioning and performance, an increased design complexity related
ordered invocation of several SFs, etc. to the properly ordered invocation of several SFs, etc.
In order to solve those problems and to decouple the services In order to solve those problems and to decouple the services
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, Service Function Chaining (SFC)
techniques have been introduced [RFC7665]. techniques have been introduced [RFC7665].
SFC techniques are meant to rationalize the service delivery logic SFC techniques are meant to rationalize the service delivery logic
and master the companion complexity while optimizing service and master the companion 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. Indeed, SFC allows to dynamically create service requirements. Indeed, SFC allows 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 overview of functions in the right sequence. [RFC7498] provides an overview of
the overall SFC problem space and [RFC7665] specifies an SFC data the overall SFC problem space and [RFC7665] specifies an SFC data
plane architecture. The SFC architecture has the merit to not make plane architecture. The SFC architecture does not make assumptions
assumptions on how advanced features (e.g., load-balancing, loose or on how advanced features (e.g., load-balancing, loose or strict
strict service paths) could be enabled within a domain. Various service paths) could be enabled within a domain. Various deployment
deployment options are made available to operators with the SFC options are made available to operators with the SFC architecture and
architecture and this approach is fundamental to accommodate various this approach is fundamental to accommodate various and heterogeneous
and heterogeneous deployment contexts. 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, re-use
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 endorsed a transport-independent Among all these approaches, the IETF created a transport-independent
SFC encapsulation scheme: NSH [RFC8300]; which is the most mature SFC SFC encapsulation scheme: NSH. This design is pragmatic as it does
encapsulation solution. This design is pragmatic as it does not not require replicating the same specification effort as a function
require replicating the same specification effort as a function of of underlying transport encapsulation. Moreover, this design
underlying transport encapsulation. Moreover, this design approach approach encourages consistent SFC-based service delivery in networks
encourages consistent SFC-based service delivery in networks enabling enabling distinct transport protocols in various network segments or
distinct transport protocols in various network segments or even even between SFFs vs SF-SFF hops.
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 "OPTIONAL" in this document are to be interpreted as described in
RFC2119 [RFC2119] when, and only when, they appear in all capitals,
[RFC2119] [RFC8174] when, and only when, they appear in all capitals,
as shown here. as shown here.
2. SFC within Segment Routing Networks 2. SFC within Segment Routing Networks
As described in [RFC8402], Segment Routing (SR) leverages the source As described in [RFC8402], SR leverages the source routing technique.
routing technique. Concretely, a node steers a packet through an SR Concretely, a node steers a packet through an SR policy instantiated
policy instantiated as an ordered list of instructions called as an ordered list of instructions called segments. While initially
segments. While initially designed for policy-based source routing, designed for policy-based source routing, SR also finds its
SR also finds its application in supporting SFC application in supporting SFC
[I-D.ietf-spring-sr-service-programming]. [I-D.ietf-spring-sr-service-programming].
The two SR flavors, namely SR-MPLS [RFC8660] and SRv6 [RFC8754], can The two SR data plane encapsulations, namely SR-MPLS [RFC8660] and
both encode an SF as a segment so that an SFC can be specified as a SRv6 [RFC8754], can both encode an SF as a segment so that an SFC can
segment list. Nevertheless, and as discussed in [RFC7498], traffic be specified as a segment list. Nevertheless, and as discussed in
steering is only a subset of the issues that motivated the design of [RFC7498], traffic steering is only a subset of the issues that
the SFC architecture. Further considerations such as simplifying motivated the design of the SFC architecture. Further considerations
classification at intermediate SFs and allowing for coordinated such as simplifying classification at intermediate SFs and allowing
behaviors among SFs by means of supplying context information for coordinated behaviors among SFs by means of supplying context
(a.k.a., metadata) should be considered when designing an SFC data information (a.k.a. metadata) should be considered when designing an
plane solution. 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 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:
o NSH-based SFC with SR-based transport plane: in this scenario SR o NSH-based SFC with SR-based transport plane: in this scenario SR-
provides the transport encapsulation between SFFs while NSH is MPLS or SRv6 provides the transport encapsulation between SFFs
used to convey and trigger SFC policies. while NSH is used to convey and trigger SFC policies.
o SR-based SFC with integrated NSH service plane: in this scenario o SR-based SFC with integrated NSH service plane: in this scenario
each service hop of the SFC is represented as a segment of the SR each service hop of the SFC is represented as a segment of the SR
segment-list. SR is thus responsible for steering traffic through segment-list. SR is thus responsible for steering traffic through
the necessary SFFs as part of the segment routing path while NSH the necessary SFFs as part of the segment routing path while NSH
is responsible for maintaining the service plane and holding the is responsible for maintaining the service plane and holding the
SFC instance context (including associated metadata). SFC instance context (including associated metadata).
It is of course possible to combine both of these two scenarios to It is of course 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 SHOULD assign an NSH Service Path Identifier (SPI) per A classifier SHOULD assign an NSH Service Path Identifier (SPI) per
SR policy so that different traffic flows that use the same NSH SR policy so that different traffic flows that use the same NSH
Service Function Path (SFP) but different SR policy can coexist on Service Function Path (SFP) but different SR policy can coexist on
the same SFP without conflict during SFF processing. the same SFP without conflict during SFF processing.
3. NSH-based SFC with SR-based Transport Tunnel 3. NSH-based SFC with SR-MPLS or 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 chain are illustration the various SFs involved in a service function chain may
available in a single data center, or spread throughout multiple be available in a single data center, or spread throughout multiple
locations (e.g., data centers, different POPs), depending upon the locations (e.g., data centers, different POPs), depending upon the
operator preference (e.g., hierarchical SFC [RFC8459]) and/or network operator preference and/or availability of service resources.
availability of service resources. Regardless of where the service Regardless of where the SFs are deployed it is necessary to provide
resources are deployed it is necessary to provide traffic steering traffic steering through a set of SFFs, and when NSH and SR are
through a set of SFFs and NSH-based service chains provide the integrated, this is provided by SR-MPLS or SRv6.
flexibility for the network operator to choose which particular
transport encapsulation to use between SFFs, which may be different
depending upon which area of the network the SFFs/SFs are currently
deployed. Therefore from an SFC architecture perspective, segment
routing is simply one of multiple available transport encapsulations
that can be used for traffic steering between SFFs. Concretely, NSH
does not require to use a unique transport encapsulation when
traversing a service chain. NSH-based service forwarding relies upon
underlying service node capabilities.
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 SPI be 100 and DC2. For the purpose of illustration, let the SFC's NSH SPI be
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 SFC and encapsulated after classification as <Inner
Pkt><NSH: SPI 100, SI 255><Outer-transport> and forwarded to SFF1 Pkt><NSH: SPI 100, SI 255><Outer-transport> and forwarded to SFF1
(which is the first SFF hop for this service chain). (which is the first SFF hop for this service function chain).
After removing the outer transport encapsulation, that may or may not After removing the outer transport encapsulation, SFF1 uses the SPI
be SR-MPLS or SRv6, SFF1 uses the SPI and SI carried within the NSH and SI carried within the NSH encapsulation to determine that it
encapsulation to determine that it should forward the packet to SF1. should forward the packet to SF1. SF1 applies its service,
SF1 applies its service, decrements the SI by 1, and returns the decrements the SI by 1, and returns the packet to SFF1. SFF1
packet to SFF1. SFF1 therefore has <SPI 100, SI 254> when the packet therefore has <SPI 100, SI 254> when the packet comes back from SF1.
comes back from SF1. SFF1 does a lookup on <SPI 100, SI 254> which SFF1 does a lookup on <SPI 100, SI 254> which results in <next-hop:
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) | | | F:Inner Pkt| | | | N(100,255) | | | F:Inner Pkt| |
| +------------+ | +------------+ | | +------------+ | +------------+ |
skipping to change at page 6, line 37 skipping to change at page 6, line 37
| +------------+ +------------+ | | +------------+ +------------+ |
| | 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 has the SR segment-list to encapsulation: SR>. The SR encapsulation, which may be SR-MPLS or
forward the packet across the inter-DC network to DC2. SRv6, has the SR segment-list to forward the packet across the inter-
DC network to DC2.
+----------- Inter DC ----------------+ +----------- Inter DC ----------------+
| (5) | | (5) |
+------+ ----> | +---------+ ----> +---------+ | +------+ ----> | +---------+ ----> +---------+ |
| | NSH | | | SR | | | | | NSH | | | SR | | |
+ SFF1 +----------|-+ DC1-GW1 +-------------+ DC2-GW1 + | + SFF1 +----------|-+ DC1-GW1 +-------------+ DC2-GW1 + |
| | | | | | | | | | | | | | | |
+------+ | +---------+ +---------+ | +------+ | +---------+ +---------+ |
| | | |
| +------------+ | | +------------+ |
skipping to change at page 7, line 26 skipping to change at page 7, line 26
| | 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. The outer transport encapsulation which results in next hop: SFF2. When SFF2 receives the packet, it
may be any transport that is able to identify NSH as the next performs a lookup on <NSH: SPI 100, SI 254> and determines to forward
protocol. 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
253> when the packet comes back from SF2. SFF2 does a lookup on
<NSH: SPI 100, SI 253> which results in end of service function
chain.
+------------------------ DC2 ----------------------+ +------------------------ DC2 ----------------------+
| +-----+ | | +-----+ |
| | SF2 | | | | SF2 | |
| +--+--+ | | +--+--+ |
| | | | | |
| | | | | |
| +------------+ | +------------+ | | +------------+ | +------------+ |
| | N(100,254) | | | F:Inner Pkt| | | | N(100,254) | | | F:Inner Pkt| |
| +------------+ | +------------+ | | +------------+ | +------------+ |
skipping to change at page 8, line 37 skipping to change at page 8, line 37
| +------------+ +------------+ | | +------------+ +------------+ |
| | 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:
o The network operator is able to take advantage of the transport- o The network operator is able to take advantage of the transport-
independent nature of the NSH encapsulation. independent nature of the NSH encapsulation, while the service is
provisioned end2end.
o The network operator is able to take advantage of the traffic o The network operator is able to take advantage of the traffic
steering capability of SR where appropriate. steering (traffic engineering) capability of SR where appropriate.
o Clear responsibility division and scope between NSH and SR. o Clear responsibility division and scope between 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 chain are distributed into multiple domains or segments of a service function chain are distributed across multiple
where traffic-engineered paths are necessary between SFFs (strict domains or where traffic-engineered paths are necessary between SFFs
forwarding paths for example). Further note that the above example (strict forwarding paths for example). Further note that the above
can also be implemented using end to end segment routing between SFF1 example can also be implemented using end to end segment routing
and SFF2. (As such DC-GW1 and DC-GW2 are forwarding the packets between SFF1 and SFF2. (As such DC-GW1 and DC-GW2 are forwarding the
based on segment routing instructions and are not looking at the NSH packets based on segment routing instructions and are not looking at
header for forwarding). the NSH header for forwarding).
4. SR-based SFC with Integrated NSH Service Plane 4. SR-based SFC with 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 and therefore
it should not be necessary to implement an SFC proxy to achieve SFC. it should not be necessary to implement an SFC proxy to achieve SFC.
The operation relies upon SR to perform SFF-SFF transport and NSH to The operation relies upon SR-MPLS or SRv6 to perform SFF-SFF
provide the service plane between SFs thereby maintaining SFC context transport and NSH to provide the service plane between SFs thereby
(e.g., the service plane path referenced by the SPI) and any maintaining SFC context (e.g., the service plane path referenced by
associated metadata. the SPI) and any associated metadata.
When a service chain is established, a packet associated with that When a service function chain is established, a packet associated
chain will first carry an NSH that will be used to maintain the end- with that chain will first carry an NSH that will be used to maintain
to-end service plane through use of the SFC context. The SFC context the end-to-end service plane through use of the SFC context. The SFC
is used by an SFF to determine the SR segment list for forwarding the context is used by an SFF to determine the SR segment list for
packet to the next-hop SFFs. The packet is then encapsulated using forwarding the packet to the next-hop SFFs. The packet is then
the (transport-specific) 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 prefix SID associated with the SF to SFF performs a lookup on the SID associated with the SF. In the case
retrieve the next hop context between the SFF and SF (e.g., to of SR-MPLS this will be a prefix SID [RFC8402]. In the case of SRv6,
retrieve the destination MAC address in case native Ethernet the behavior described within this document is assigned the name
encapsulation is used between SFF and SF). How the next hop context END.NSH, and section 8.3 requests allocation of a code point by IANA.
is populated is out of the scope of this document. The SFF strips The result of this lookup allows the SFF to retrieve the next hop
the SR information of the packet, updates the SR information, and context between the SFF and SF (e.g., the destination MAC address in
saves it to a cache indexed by the NSH SPI. This saved SR case native Ethernet encapsulation is used between SFF and SF). In
information is used to encapsulate and forward the packet(s) coming addition the SFF strips the SR information from the packet, updates
back from the SF. 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 stack occurs at the end of the
regularly defined logic. The behavior of reattaching the stack
occurs before the SR process of forwarding the packet to the next
entry in the segment-list. Both behaviors are further detailed in
section 5.
When the SF receives the packet, it processes it as usual and sends When the SF receives the packet, it processes it as usual and sends
it back to the SFF. Once the SFF receives this packet, it extracts it back to the SFF. Once the SFF receives this packet, it extracts
the SR information using the NSH SPI as the index into the cache. the SR information using the NSH SPI and SI as the index into the
The SFF then pushes the SR header on top of the NSH header, and cache. The SFF then pushes the retrieved SR header on top of the NSH
forwards the packet to the next segment in the segment list. header, and forwards the packet to the next segment in the segment
list.
Figure 4 illustrates an example of this scenario. Figure 4 illustrates an example of this scenario.
+-----+ +-----+ +-----+ +-----+
| SF1 | | SF2 | | SF1 | | SF2 |
+--+--+ +--+--+ +--+--+ +--+--+
| | | |
| | | |
+-----------+ | +-----------+ +-----------+ | +-----------+ +-----------+ | +-----------+ +-----------+ | +-----------+
|N(100,255) | | |F:Inner Pkt| |N(100,254) | | |F:Inner Pkt| |N(100,255) | | |F:Inner Pkt| |N(100,254) | | |F:Inner Pkt|
skipping to change at page 10, line 46 skipping to change at page 10, line 46
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:
o It is economically sound for SF vendors to only support one o 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.
o It simplifies the SFF (i.e., the SR router) by nullifying the o It simplifies the SFF (i.e., the SR router) by nullifying the
needs for re-classification and SR proxy. needs for re-classification and SR proxy.
o It provides a unique and standard way to pass metadata to SFs.
Note that currently there is no solution for SR-MPLS to carry
metadata and there is no solution to pass metadata to SR-unaware
SFs.
o SR is also used for forwarding purposes including between SFFs. o SR is also used for forwarding purposes including between SFFs.
o It takes advantage of SR to eliminate the NSH forwarding state in o 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.
o It requires no interworking as would be the case if SR-MPLS based o 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. Encapsulation Details 5. Packet Processing Details
5.1. NSH using SR-MPLS Transport This section describes the End.NSH behavior and NSH processing logic.
The pseudo code 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 RFC 8754 section
4.3.1.1, up through line S.16.
After S.15, if S is a local End.NSH SID, then:
S15.1. Remove and store IPv6 and SRH headers in local cache indexed
by <NSH: path-id, service-index -1>
S15.2. Submit the packet to the NSH FIB lookup and transmit to the
destination associated with <NSH: path-id, service-index>
Note: The End.NSH behavior interrupts the normal SRH packet
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
IPv6 and SRH headers based on the <NSH: path-id, service-index> from
the NSH header. Then resume processing from RFC 8754 section 4.3.1.1
with line S.16.
6. Encapsulation Details
6.1. NSH using SR-MPLS Transport
SR-MPLS instantiates Segment IDs (SIDs) as MPLS labels and therefore SR-MPLS instantiates Segment IDs (SIDs) as MPLS labels and therefore
the segment routing header is a stack of MPLS labels. the segment routing header is a stack of MPLS labels.
When carrying NSH within an SR-MPLS transport, the full encapsulation When carrying NSH within an SR-MPLS transport, the full encapsulation
headers are as illustrated in Figure 5. headers are as illustrated in Figure 5.
+------------------+ +------------------+
~ MPLS-SR Labels ~ ~ MPLS-SR Labels ~
+------------------+ +------------------+
skipping to change at page 11, line 44 skipping to change at page 12, line 27
As described in [RFC8402], the IGP signaling extension for IGP-Prefix As described in [RFC8402], the IGP signaling extension for IGP-Prefix
segment includes a flag to indicate whether directly connected 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 SID.
When NSH is carried beneath SR-MPLS it is necessary to terminate the When 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 NSH-based SFC at the tail-end node of the SR-MPLS label stack. This
is the equivalent of MPLS Ultimate Hop Popping (UHP) and therefore is the equivalent of MPLS Ultimate Hop Popping (UHP) and therefore
the prefix-SID associated with the tail-end of the SFC MUST be the prefix-SID associated with the tail-end of the SFC MUST be
advertised with the CONTINUE operation so that the penultimate hop advertised with the CONTINUE operation so that the penultimate hop
node does not pop the top label of the SR-MPLS label stack and node does not pop the top label of the SR-MPLS label stack and
thereby expose NSH to the wrong SFF. It is RECOMMENDED that a thereby expose NSH to the wrong SFF. This is realized by setting No-
specific prefix-SID be allocated at each node for use by the SFC PHP flag in Prefix-SID Sub-TLV [RFC8667], [RFC8665]. It is
application for this purpose. RECOMMENDED that a specific prefix-SID be allocated at each node for
use by the SFC application for this purpose.
At the end of the SR-MPLS path it is necessary to provide an At the end of the SR-MPLS path it is necessary to provide an
indication to the tail-end that NSH follows the SR-MPLS label stack. indication to the tail-end that NSH follows the SR-MPLS label stack
as described by [RFC8596].
There are several ways to achieve this but its specification is
outside the scope of this document.
5.2. NSH using SRv6 Transport 6.2. NSH using SRv6 Transport
When carrying NSH within an SRv6 transport the full encapsulation is When carrying NSH within an SRv6 transport the full encapsulation is
as illustrated in Figure 6. 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
skipping to change at page 13, line 13 skipping to change at page 14, line 5
Figure 6: NSH using SRv6 Transport Figure 6: NSH using SRv6 Transport
Encapsulation of NSH following SRv6 may be indicated either by Encapsulation of NSH following SRv6 may be indicated either by
encapsulating NSH in UDP (UDP port TBA1) and indicating UDP in the encapsulating NSH in UDP (UDP port TBA1) and indicating UDP in the
Next Header field of the SRH, or by indicating an IP protocol number Next Header field of the SRH, or by indicating an IP protocol number
for NSH in the Next Header of the SRH. The behavior for for NSH in the Next Header of the SRH. The behavior for
encapsulating NSH over UDP, including the selection of the source encapsulating NSH over UDP, including the selection of the source
port number in particular, adheres to similar considerations as those port number in particular, adheres to similar considerations as those
discussed in [RFC8086]. discussed in [RFC8086].
6. 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].
NSH-in-UDP with DTLS [RFC6347] should follow the considerations NSH-in-UDP with DTLS [RFC6347] should follow the considerations
discussed in Section 5 of [RFC8086], with a destination port number discussed in Section 5 of [RFC8086], with a destination port number
set to TBA2. set to TBA2.
Generic segment routing related security considerations are discussed Generic segment routing related security considerations are discussed
in section 7 of [RFC8754] and section 5 of [RFC8663]. in section 7 of [RFC8754] and section 5 of [RFC8663].
7. IANA Considerations 8. IANA Considerations
7.1. UDP Port Number for NSH 8.1. UDP Port Number for NSH
IANA is requested to assign the UDP port numbers TBA1 and TBA2 to the NSH from the "Service Name and Transport Protocol Port Number Registry" available at
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml:
Service Name: NSH-in-UDP IANA is requested to assign the UDP port numbers TBA1 and TBA2 to the
Transport Protocol(s): UDP NSH from the "Service Name and Transport Protocol Port Number Registry"
Assignee: IESG iesg@ietf.org available at
Contact: IETF Chair chair@ietf.org https://www.iana.org/assignments/service-names-port-numbers/
Description: NSH-in-UDP Encapsulation service-names-port-numbers.xhtml:
Reference: [ThisDocument]
Port Number: TBA1
Service Code: N/A
Known Unauthorized Uses: N/A
Assignment Notes: N/A
Service Name: NSH-UDP-DTLS Service Name: NSH-in-UDP
Transport Protocol(s): UDP Transport Protocol(s): UDP
Assignee: IESG iesg@ietf.org Assignee: IESG iesg@ietf.org
Contact: IETF Chair chair@ietf.org Contact: IETF Chair chair@ietf.org
Description: NSH-in-UDP with DTLS Encapsulation Description: NSH-in-UDP Encapsulation
Reference: [ThisDocument] Reference: [ThisDocument]
Port Number: TBA2 Port Number: TBA1
Service Code: N/A Service Code: N/A
Known Unauthorized Uses: N/A Known Unauthorized Uses: N/A
Assignment Notes: N/A Assignment Notes: N/A
7.2. Protocol Number for NSH Service Name: NSH-UDP-DTLS
Transport Protocol(s): UDP
Assignee: IESG iesg@ietf.org
Contact: IETF Chair chair@ietf.org
Description: NSH-in-UDP with DTLS Encapsulation
Reference: [ThisDocument]
Port Number: TBA2
Service Code: N/A
Known Unauthorized Uses: N/A
Assignment Notes: N/A
IANA is requested to assign a protocol number TBA3 for the NSH from the "Assigned Internet Protocol Numbers" registry available at 8.2. Protocol Number for NSH
https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml.
IANA is requested to assign a protocol number TBA3 for the NSH from the
"Assigned Internet Protocol Numbers" registry available at
https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
+---------+---------+--------------+---------------+----------------+ +---------+---------+--------------+---------------+----------------+
| Decimal | Keyword | Protocol | IPv6 | Reference | | Decimal | Keyword | Protocol | IPv6 | Reference |
| | | | Extension | | | | | | Extension | |
| | | | Header | | | | | | Header | |
+---------+---------+--------------+---------------+----------------+ +---------+---------+--------------+---------------+----------------+
| TBA3 | NSH | Network | N | [ThisDocument] | | TBA3 | NSH | Network | N | [ThisDocument] |
| | | Service | | | | | | Service | | |
| | | Header | | | | | | Header | | |
+---------+---------+--------------+---------------+----------------+ +---------+---------+--------------+---------------+----------------+
8. Contributing Authors 8.3. SRv6 Endpoint Behavior for NSH
The following coauthors, along with their respective affiliations at
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
--------------------------------------------------------------
TBA4 End.NSH - NSH Segment [This.ID]
9. Contributing Authors
The following co-authors, along with their respective affiliations at
the time of WG adoption, provided valuable inputs and text contributions the time of WG adoption, provided valuable inputs and text contributions
to this document. to this document.
Mohamed Boucadair Mohamed Boucadair
Orange Orange
mohamed.boucadair@orange.com mohamed.boucadair@orange.com
Joel Halpern Joel Halpern
Ericsson Ericsson
joel.halpern@ericsson.com joel.halpern@ericsson.com
Syed Hassan Syed Hassan
Cisco System, inc. Cisco System, inc.
shassan@cisco.com shassan@cisco.com
Wim Henderickx Wim Henderickx
Nokia Nokia
wim.henderickx@nokia.com wim.henderickx@nokia.com
Haoyu Song Haoyu Song
Futurewei Technologies Futurewei Technologies
haoyu.song@futurewei.com haoyu.song@futurewei.com
9. References 10. References
9.1. Normative References 10.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>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[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>.
[RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE-
in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086,
March 2017, <https://www.rfc-editor.org/info/rfc8086>. March 2017, <https://www.rfc-editor.org/info/rfc8086>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300, "Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018, DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>. <https://www.rfc-editor.org/info/rfc8300>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8596] Malis, A., Bryant, S., Halpern, J., and W. Henderickx,
"MPLS Transport Encapsulation for the Service Function
Chaining (SFC) Network Service Header (NSH)", RFC 8596,
DOI 10.17487/RFC8596, June 2019,
<https://www.rfc-editor.org/info/rfc8596>.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660, Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019, DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/info/rfc8660>. <https://www.rfc-editor.org/info/rfc8660>.
[RFC8663] Xu, X., Bryant, S., Farrel, A., Hassan, S., Henderickx, [RFC8663] Xu, X., Bryant, S., Farrel, A., Hassan, S., Henderickx,
W., and Z. Li, "MPLS Segment Routing over IP", RFC 8663, W., and Z. Li, "MPLS Segment Routing over IP", RFC 8663,
DOI 10.17487/RFC8663, December 2019, DOI 10.17487/RFC8663, December 2019,
<https://www.rfc-editor.org/info/rfc8663>. <https://www.rfc-editor.org/info/rfc8663>.
[RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler,
H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", RFC 8665,
DOI 10.17487/RFC8665, December 2019,
<https://www.rfc-editor.org/info/rfc8665>.
[RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C.,
Bashandy, A., Gredler, H., and B. Decraene, "IS-IS
Extensions for Segment Routing", RFC 8667,
DOI 10.17487/RFC8667, December 2019,
<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>.
9.2. Informative References 10.2. Informative References
[I-D.ietf-spring-sr-service-programming] [I-D.ietf-spring-sr-service-programming]
Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,
d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., d., Li, C., Decraene, B., Ma, S., Yadlapalli, C.,
Henderickx, W., and S. Salsano, "Service Programming with Henderickx, W., and S. Salsano, "Service Programming with
Segment Routing", draft-ietf-spring-sr-service- Segment Routing", draft-ietf-spring-sr-service-
programming-03 (work in progress), September 2020. programming-03 (work in progress), September 2020.
[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>.
[RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair,
"Hierarchical Service Function Chaining (hSFC)", RFC 8459,
DOI 10.17487/RFC8459, September 2018,
<https://www.rfc-editor.org/info/rfc8459>.
Authors' Addresses Authors' Addresses
James N Guichard (editor) James N Guichard (editor)
Futurewei Technologies Futurewei Technologies
2330 Central Express Way 2330 Central Express Way
Santa Clara Santa Clara
USA USA
Email: james.n.guichard@futurewei.com Email: james.n.guichard@futurewei.com
 End of changes. 57 change blocks. 
192 lines changed or deleted 250 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/