< draft-ietf-spring-nsh-sr-05.txt   draft-ietf-spring-nsh-sr-06.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: November 8, 2021 Apstra inc. Expires: December 10, 2021 Apstra inc.
May 7, 2021 June 8, 2021
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-05 draft-ietf-spring-nsh-sr-06
Abstract Abstract
This document describes the integration of Network Service Header This document describes the integration of Network Service Header
(NSH) [RFC8300] and Segment Routing (SR) [RFC8402], as well as (NSH) and Segment Routing (SR), as well as encapsulation details, to
encapsulation details, to support Service Function Chaining (SFC) support Service Function Chaining (SFC) in an efficient manner while
[RFC7665] in an efficient manner while maintaining separation of the maintaining separation of the service and transport planes as
service and transport planes as originally intended by the SFC originally intended by the SFC architecture.
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 (SFF) along a given
Service Function Path (SFP) while NSH has the responsibility for Service Function Path (SFP) while NSH has the responsibility 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.
The integration described in this document demonstrates that NSH and The integration described in this document demonstrates that NSH and
SR can work jointly and complement each other leaving the network SR can work jointly and complement each other leaving the network
operator with the flexibility to use whichever transport technology operator with the flexibility to use whichever transport technology
skipping to change at page 1, line 49 skipping to change at page 1, line 48
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 November 8, 2021. This Internet-Draft will expire on December 10, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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 . . . . . . . . . . . . . . . . . . 4
2. SFC within Segment Routing Networks . . . . . . . . . . . . . 4 2. SFC within Segment Routing Networks . . . . . . . . . . . . . 4
3. NSH-based SFC with SR-MPLS or SRv6 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. Packet Processing Details . . . . . . . . . . . . . . . . . . 11 5. Packet Processing for SR-based SFC . . . . . . . . . . . . . 11
6. Encapsulation Details . . . . . . . . . . . . . . . . . . . . 11 5.1. SR-based SFC (SR-MPLS) Packet Processing . . . . . . . . 11
6.1. NSH using SR-MPLS Transport . . . . . . . . . . . . . . . 11 5.2. SR-based SFC (SRv6) Packet Processing . . . . . . . . . . 11
6. Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. NSH using SR-MPLS Transport . . . . . . . . . . . . . . . 12
6.2. NSH using SRv6 Transport . . . . . . . . . . . . . . . . 12 6.2. NSH using SRv6 Transport . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9.1. Protocol Number for NSH . . . . . . . . . . . . . . . . . 14 9.1. Protocol Number for NSH . . . . . . . . . . . . . . . . . 14
9.2. SRv6 Endpoint Behavior for NSH . . . . . . . . . . . . . 14 9.2. SRv6 Endpoint Behavior for NSH . . . . . . . . . . . . . 14
10. Contributing Authors . . . . . . . . . . . . . . . . . . . . 14 10. Contributing Authors . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . 17 11.2. Informative References . . . . . . . . . . . . . . . . . 17
skipping to change at page 4, line 47 skipping to change at page 5, line 5
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 MUST assign an NSH Service Path Identifier (SPI) per SR
SR policy so that different traffic flows that use the same NSH policy so that different traffic flows that use the same NSH Service
Service Function Path (SFP) but different SR policy can coexist on Function Path (SFP) but different SR policy can coexist on the same
the same SFP without conflict during SFF processing. 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 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 may
be 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
network operator preference and/or availability of service resources. network operator preference and/or availability of service resources.
skipping to change at page 9, line 28 skipping to change at page 9, line 28
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 SID associated with the SF. In the case SFF performs a lookup on the SID associated with the SF. In the case
of SR-MPLS this will be a prefix SID [RFC8402]. In the case of SRv6, of SR-MPLS this will be a prefix SID [RFC8402]. In the case of SRv6,
the behavior described within this document is assigned the name the behavior described within this document is assigned the name
END.NSH, and section 8.3 requests allocation of a code point by IANA. END.NSH, and section 9.2 requests allocation of a code point by IANA.
The result of this lookup allows the SFF to retrieve the next hop The result of this lookup allows the SFF to retrieve the next hop
context between the SFF and SF (e.g., the destination MAC address in context between the SFF and SF (e.g., the destination MAC address in
case native Ethernet encapsulation is used between SFF and SF). In case native Ethernet encapsulation is used between SFF and SF). In
addition the SFF strips the SR information from the packet, updates addition the SFF strips the SR information from the packet, updates
the SR information, and saves it to a cache indexed by the NSH the SR information, and saves it to a cache indexed by the NSH
Service Path Identifier (SPI) and the Service Index (SI) decremented Service Path Identifier (SPI) and the Service Index (SI) decremented
by 1. This saved SR information is used to encapsulate and forward by 1. This saved SR information is used to encapsulate and forward
the packet(s) coming back from the SF. the packet(s) coming back from the SF.
The behavior of remembering the SR stack occurs at the end of the The behavior of remembering the SR segment-list occurs at the end of
regularly defined logic. The behavior of reattaching the stack the regularly defined logic. The behavior of reattaching the
occurs before the SR process of forwarding the packet to the next segment-list occurs before the SR process of forwarding the packet to
entry in the segment-list. Both behaviors are further detailed in the next entry in the segment-list. Both behaviors are further
section 5. 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 and SI as the index into the the SR information using the NSH SPI and SI as the index into the
cache. The SFF then pushes the retrieved SR header on top of the NSH cache. The SFF then pushes the retrieved SR header on top of the NSH
header, and forwards the packet to the next segment in the segment header, and forwards the packet to the next segment in the segment-
list. list.
Figure 4 illustrates an example of this scenario. Figure 4 illustrates an example of this scenario.
+-----+ +-----+ +-----+ +-----+
| SF1 | | SF2 | | SF1 | | SF2 |
+--+--+ +--+--+ +--+--+ +--+--+
| | | |
| | | |
+-----------+ | +-----------+ +-----------+ | +-----------+ +-----------+ | +-----------+ +-----------+ | +-----------+
skipping to change at page 11, line 9 skipping to change at page 11, line 9
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. Packet Processing Details 5. Packet Processing for SR-based SFC
This section describes the End.NSH behavior and NSH processing logic. This section describes the End.NSH behavior (SRv6), Prefix SID
The pseudo code is shown below. behavior (SR-MPLS) and NSH processing logic.
5.1. SR-based SFC (SR-MPLS) Packet Processing
When an SFF receives a packet destined to S and S is a local prefix
SID associated with an SF, the SFF strips the SR segment-list (label
stack) from the packet, updates the SR information, and saves it to a
cache indexed by the NSH Service Path Identifier (SPI) and the
Service Index (SI) decremented by 1. This saved SR information is
used to re-encapsulate and forward the packet(s) coming back from the
SF.
5.2. SR-based SFC (SRv6) Packet Processing
This section describes the End.NSH behavior and NSH processing logic
for SRv6. The pseudo code 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 RFC 8754 section the processing is the same as that specified by RFC 8754 section
4.3.1.1, up through line S.16. 4.3.1.1, up through line S.16.
After S.15, if S is a local End.NSH SID, then: 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 S15.1. Remove and store IPv6 and SRH headers in local cache indexed
by <NSH: path-id, service-index -1> by <NSH: service-path-id, service-index -1>
S15.2. Submit the packet to the NSH FIB lookup and transmit to the S15.2. Submit the packet to the NSH FIB lookup and transmit to the
destination associated with <NSH: path-id, service-index> destination associated with <NSH: service-path-id, service-index>
Note: The End.NSH behavior interrupts the normal SRH packet Note: The End.NSH behavior interrupts the normal SRH packet
processing as described in RFC8754 section 4.3.1.1, which does not processing as described in RFC8754 section 4.3.1.1, which does not
continue to S16 at this time. 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: path-id, service-index> from IPv6 and SRH headers based on the <NSH: service-path-id, service-
the NSH header. Then resume processing from RFC 8754 section 4.3.1.1 index> from the NSH header. Then resume processing from [RFC8754]
with line S.16. section 4.3.1.1 with line S.16.
6. Encapsulation Details 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 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.
+------------------+ +------------------+
 End of changes. 16 change blocks. 
33 lines changed or deleted 49 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/