< draft-ietf-spring-nsh-sr-10.txt   draft-ietf-spring-nsh-sr-11.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: June 16, 2022 Microsoft Expires: 21 October 2022 Microsoft
December 13, 2021 April 2022
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-10 draft-ietf-spring-nsh-sr-11
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
support Service Function Chaining (SFC) in an efficient manner while support Service Function Chaining (SFC) in an efficient manner while
maintaining separation of the service and transport planes as maintaining separation of the service and transport planes as
originally intended by the SFC architecture. originally intended by the SFC architecture.
Combining these technologies allows SR to be used for steering Combining these technologies allows SR to be used for steering
skipping to change at page 1, line 48 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 June 16, 2022. This Internet-Draft will expire on 3 October 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 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/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Revised BSD License text as
include Simplified BSD License text as described in Section 4.e of described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Revised 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 . . . . . . . . . . . . . . . 3 1.1. SFC Overview and Rationale . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 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 for SR-based SFC . . . . . . . . . . . . . 11 5. Packet Processing for SR-based SFC . . . . . . . . . . . . . 11
skipping to change at page 4, line 40 skipping to change at page 5, line 5
for coordinated behaviors among SFs by means of supplying context for coordinated behaviors among SFs by means of supplying context
information (a.k.a. metadata) should be considered when designing an information (a.k.a. metadata) should be considered when designing an
SFC data 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- * NSH-based SFC with SR-based transport plane: in this scenario SR-
MPLS or SRv6 provides the transport encapsulation between SFFs MPLS or SRv6 provides the transport encapsulation between SFFs
while NSH is 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 * 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 MUST assign an NSH Service Path Identifier (SPI) per SR A classifier MUST use an NSH Service Path Identifier (SPI) per SR
policy so that different traffic flows that use the same NSH Service policy so that different traffic flows that use the same NSH Service
Function Path (SFP) but different SR policy can coexist on the same Function Path (SFP) but different SR policy can coexist on 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 Points of Presense (POPs)), locations (e.g., data centers, different Points of Presence (POPs)),
depending upon the network operator preference and/or availability of depending upon the network operator preference and/or availability of
service resources. Regardless of where the SFs are deployed it is service resources. Regardless of where the SFs are deployed it is
necessary to provide traffic steering through a set of SFFs, and when necessary to provide traffic steering through a set of SFFs, and when
NSH and SR are integrated, this is provided by SR-MPLS or SRv6. 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.
skipping to change at page 6, line 33 skipping to change at page 6, line 41
|+------------+ +------+ +---------+ | |+------------+ +------+ +---------+ |
| | | |
| +------------+ +------------+ | | +------------+ +------------+ |
| | 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) |
+------+ ----> | +---------+ ----> +---------+ | +------+ ----> | +---------+ ----> +---------+ |
skipping to change at page 7, line 22 skipping to change at page 7, line 22
| | | |
| +------------+ | | +------------+ |
| | 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. SFF2 therefore has <NSH: SPI 100, SI
253> when the packet comes back from SF2. SFF2 does a lookup on 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.
skipping to change at page 8, line 32 skipping to change at page 8, line 32
| | | | | | | | | | | | | | | |
+---------+ | +----------+ +------+ | +---------+ | +----------+ +------+ |
| | | |
| +------------+ +------------+ | | +------------+ +------------+ |
| | 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:
o 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.
o 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.
o Clear responsibility division and scope between NSH and SR. * 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 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 the
packets based on segment routing instructions and are not looking at packets based on segment routing instructions and are not looking at
the NSH header for forwarding.) the NSH header for forwarding.)
skipping to change at page 10, line 41 skipping to change at page 10, line 50
+------------+ +------------+ +------------+ +------------+ +------------+ +------------+
| S(SFF2) | | N(100,254) | | S(SFF2) | | N(100,254) |
+------------+ +------------+ +------------+ +------------+
| 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:
o 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.
o 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 re-classification and SR proxy.
o SR is also used for forwarding purposes including between SFFs. * SR is also used for forwarding purposes including between SFFs.
o 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.
o 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
skipping to change at page 13, line 45 skipping to change at page 14, line 4
// // // //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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
Figure 6: NSH using SRv6 Transport
Encapsulation of NSH following SRv6 is indicated by the IP protocol Encapsulation of NSH following SRv6 is indicated by the IP protocol
number for NSH in the Next Header of the SRH. number for 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].
skipping to change at page 17, line 49 skipping to change at page 17, line 49
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 13.2. Informative References
[I-D.ietf-spring-sr-service-programming] [I-D.ietf-spring-sr-service-programming]
Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C., Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C.,
Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and
S. Salsano, "Service Programming with Segment Routing", S. Salsano, "Service Programming with Segment Routing",
draft-ietf-spring-sr-service-programming-05 (work in Work in Progress, Internet-Draft, draft-ietf-spring-sr-
progress), September 2021. service-programming-05, 10 September 2021,
<https://www.ietf.org/archive/id/draft-ietf-spring-sr-
service-programming-05.txt>.
[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>.
skipping to change at page 18, line 26 skipping to change at page 18, line 26
"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>.
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 United States of America
Email: james.n.guichard@futurewei.com Email: james.n.guichard@futurewei.com
Jeff Tantsura (editor) Jeff Tantsura (editor)
Microsoft Microsoft
USA United States of America
Email: jefftant.ietf@gmail.com Email: jefftant.ietf@gmail.com
 End of changes. 25 change blocks. 
38 lines changed or deleted 36 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/