< draft-ietf-spring-nsh-sr-06.txt   draft-ietf-spring-nsh-sr-07.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: December 10, 2021 Apstra inc. Expires: December 24, 2021 Apstra inc.
June 8, 2021 June 22, 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-06 draft-ietf-spring-nsh-sr-07
Abstract Abstract
This document describes the integration of Network Service Header This document describes the integration of 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 December 10, 2021. This Internet-Draft will expire on December 24, 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
skipping to change at page 2, line 33 skipping to change at page 2, line 33
1.1. SFC Overview and Rationale . . . . . . . . . . . . . . . 2 1.1. SFC Overview and Rationale . . . . . . . . . . . . . . . 2
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
5.1. SR-based SFC (SR-MPLS) Packet Processing . . . . . . . . 11 5.1. SR-based SFC (SR-MPLS) Packet Processing . . . . . . . . 11
5.2. SR-based SFC (SRv6) Packet Processing . . . . . . . . . . 11 5.2. SR-based SFC (SRv6) Packet Processing . . . . . . . . . . 11
6. Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. NSH using SR-MPLS Transport . . . . . . . . . . . . . . . 12 6.1. NSH using SR-MPLS Transport . . . . . . . . . . . . . . . 12
6.2. NSH using SRv6 Transport . . . . . . . . . . . . . . . . 12 6.2. NSH using SRv6 Transport . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
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 . . . . . . . . . . . . . . . . . . . . 15
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
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
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
skipping to change at page 12, line 33 skipping to change at page 12, line 33
+------------------+ +------------------+
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], 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 can be achieved using either the NEXT or CONTINUE operation.
the prefix-SID associated with the tail-end of the SFC MUST be
advertised with the CONTINUE operation so that the penultimate hop
node does not pop the top label of the SR-MPLS label stack and
thereby expose NSH to the wrong SFF. This is realized by setting No-
PHP flag in Prefix-SID Sub-TLV [RFC8667], [RFC8665]. It is
RECOMMENDED that a specific prefix-SID be allocated at each node for
use by the SFC application for this purpose.
Alternatively, if NEXT operation is performed, then at the end of the If NEXT operation is to be used, then at the end of the SR-MPLS path
SR-MPLS path it is necessary to provide an indication to the tail-end it is necessary to provide an indication to the tail-end that NSH
that NSH follows the SR-MPLS label stack as described by [RFC8596]. follows the SR-MPLS label stack as described by [RFC8596].
If CONTINUE operation is to be used, this is the equivalent of MPLS
Ultimate Hop Popping (UHP) and therefore it is necessary to ensure
that the penultimate hop node does not pop the top label of the SR-
MPLS label stack and thereby expose NSH to the wrong SFF. This is
realized by setting No-PHP flag in Prefix-SID Sub-TLV [RFC8667],
[RFC8665]. It is RECOMMENDED that a specific prefix-SID be allocated
at each node for use by the SFC 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 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 |
 End of changes. 7 change blocks. 
18 lines changed or deleted 19 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/