draft-ietf-sfc-multi-layer-oam-09.txt   draft-ietf-sfc-multi-layer-oam-10.txt 
SFC WG G. Mirsky SFC WG G. Mirsky
Internet-Draft ZTE Corp. Internet-Draft ZTE Corp.
Updates: 8300 (if approved) W. Meng Updates: 8300 (if approved) W. Meng
Intended status: Standards Track ZTE Corporation Intended status: Standards Track ZTE Corporation
Expires: August 15, 2021 B. Khasnabish Expires: 1 October 2021 B. Khasnabish
C. Wang C. Wang
Individual contributor Individual contributor
February 11, 2021 30 March 2021
Active OAM for Service Function Chaining Active OAM for Service Function Chaining
draft-ietf-sfc-multi-layer-oam-09 draft-ietf-sfc-multi-layer-oam-10
Abstract Abstract
A set of requirements for active Operation, Administration, and A set of requirements for active Operation, Administration, and
Maintenance (OAM) of Service Function Chains (SFCs) in a network is Maintenance (OAM) of Service Function Chains (SFCs) in a network is
presented in this document. Based on these requirements, an presented in this document. Based on these requirements, an
encapsulation of active OAM messages in SFC and a mechanism to detect encapsulation of active OAM messages in SFC and a mechanism to detect
and localize defects are described. and localize defects are described.
This document updates RFC 8300 in the definition of O (OAM) bit in This document updates RFC 8300 in the definition of O (OAM) bit in
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 August 15, 2021. This Internet-Draft will expire on 1 October 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/
(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 Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as 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 Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements for Active OAM in SFC Network . . . . . . . . . 4 3. Requirements for Active OAM in SFC Network . . . . . . . . . 4
4. Active OAM Identification in SFC NSH . . . . . . . . . . . . 6 4. Active OAM Identification in SFC NSH . . . . . . . . . . . . 6
5. Echo Request/Echo Reply for SFC . . . . . . . . . . . . . . . 8 5. Echo Request/Echo Reply for SFC . . . . . . . . . . . . . . . 8
5.1. Return Codes . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Return Codes . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Authentication in Echo Request/Reply . . . . . . . . . . 11 5.2. Authentication in Echo Request/Reply . . . . . . . . . . 11
5.3. SFC Echo Request Transmission . . . . . . . . . . . . . . 11 5.3. SFC Echo Request Transmission . . . . . . . . . . . . . . 11
5.4. SFC Echo Request Reception . . . . . . . . . . . . . . . 12 5.4. SFC Echo Request Reception . . . . . . . . . . . . . . . 12
5.4.1. Errored TLVs TLV . . . . . . . . . . . . . . . . . . 12 5.4.1. Errored TLVs TLV . . . . . . . . . . . . . . . . . . 12
5.5. SFC Echo Reply Transmission . . . . . . . . . . . . . . . 13 5.5. SFC Echo Reply Transmission . . . . . . . . . . . . . . . 13
5.6. SFC Echo Reply Reception . . . . . . . . . . . . . . . . 14 5.6. SFC Echo Reply Reception . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8.1. SFC Active OAM Protocol . . . . . . . . . . . . . . . . . 15 8.1. SFC Active OAM Protocol . . . . . . . . . . . . . . . . . 15
8.2. SFC Active OAM Message Type . . . . . . . . . . . . . . . 15 8.2. SFC Active OAM Message Type . . . . . . . . . . . . . . . 16
8.3. SFC Echo Request/Echo Reply Parameters . . . . . . . . . 16 8.3. SFC Echo Request/Echo Reply Parameters . . . . . . . . . 16
8.4. SFC Echo Request/Echo Reply Message Types . . . . . . . . 16 8.4. SFC Echo Request/Echo Reply Message Types . . . . . . . . 16
8.5. SFC Echo Reply Modes . . . . . . . . . . . . . . . . . . 17 8.5. SFC Echo Reply Modes . . . . . . . . . . . . . . . . . . 17
8.6. SFC Echo Return Codes . . . . . . . . . . . . . . . . . . 18 8.6. SFC Echo Return Codes . . . . . . . . . . . . . . . . . . 19
8.7. SFC TLV Type . . . . . . . . . . . . . . . . . . . . . . 19 8.7. SFC TLV Type . . . . . . . . . . . . . . . . . . . . . . 19
8.8. SFC OAM UDP Port . . . . . . . . . . . . . . . . . . . . 20 8.8. SFC OAM UDP Port . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
[RFC7665] defines components necessary to implement a Service [RFC7665] defines components necessary to implement a Service
Function Chain (SFC). These include: Function Chain (SFC). These include:
1. a classifier that performs the classification of incoming packets 1. a classifier that performs the classification of incoming packets
2. Service Function Forwarders (SFFs) that are responsible for 2. Service Function Forwarders (SFFs) that are responsible for
forwarding traffic to one or more connected Service Functions forwarding traffic to one or more connected Service Functions
(SFs) according to the information carried in the SFC service (SFs) according to the information carried in the SFC service
skipping to change at page 5, line 13 skipping to change at page 5, line 13
active FM OAM mechanisms to be used in an SFC architecture. active FM OAM mechanisms to be used in an SFC architecture.
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
|SF1| |SF2| |SF3| |SF4| |SF5| |SF6| |SF1| |SF2| |SF3| |SF4| |SF5| |SF6|
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
\ / \ / \ / \ / \ / \ /
+----------+ +----+ +----+ +----+ +----------+ +----+ +----+ +----+
|Classifier|-------|SFF1|---------|SFF2|--------|SFF3| |Classifier|-------|SFF1|---------|SFF2|--------|SFF3|
+----------+ +----+ +----+ +----+ +----------+ +----+ +----+ +----+
Figure 1: SFC Data Plane Reference Model Figure 1: SFC Data Plane Reference Model
Regarding the reference model depicted in Figure 1, consider a Regarding the reference model depicted in Figure 1, consider a
service function chain that includes three distinct service service function chain that includes three distinct service
functions. In this example, the SFP traverses SFF1, SFF2, and SFF3, functions. In this example, the SFP traverses SFF1, SFF2, and SFF3,
each SFF being connected to two instances of the same service each SFF being connected to two instances of the same service
function. End-to-end (e2e) SFC OAM, in this example, has the function. End-to-end (e2e) SFC OAM, in this example, has the
Classifier as the ingress of the SFC OAM domain, and SFF3 - as its Classifier as the ingress of the SFC OAM domain, and SFF3 - as its
egress. Segment SFC OAM is always within the E2E SFC OAM domain egress. Segment SFC OAM is always within the E2E SFC OAM domain
between two elements that are part of the same SFP. Following are between two elements that are part of the same SFP. Following are
the requirements for an FM SFC OAM, whether with the E2E or segment the requirements for an FM SFC OAM, whether with the E2E or segment
skipping to change at page 7, line 7 skipping to change at page 7, line 12
O bit: Setting this bit indicates an OAM command and/or data in O bit: Setting this bit indicates an OAM command and/or data in
the NSH Context Header or packet payload. the NSH Context Header or packet payload.
Active SFC OAM is defined as a combination of OAM commands and/or Active SFC OAM is defined as a combination of OAM commands and/or
data included in a message that immediately follows the NSH. To data included in a message that immediately follows the NSH. To
identify the active OAM message, the Next Protocol field's value MUST identify the active OAM message, the Next Protocol field's value MUST
be set to Active SFC OAM (TBA1) (Section 8.1). The rules for be set to Active SFC OAM (TBA1) (Section 8.1). The rules for
interpreting the values of O bit and the Next Protocol field are as interpreting the values of O bit and the Next Protocol field are as
follows: follows:
o O bit set and the Next Protocol value is not one of identifying * O bit set and the Next Protocol value is not one of identifying
active or hybrid OAM protocol (per [RFC7799] definitions), e.g., active or hybrid OAM protocol (per [RFC7799] definitions), e.g.,
defined in this specification Active SFC OAM: defined in this specification Active SFC OAM:
- a Fixed-Length Context Header or Variable-Length Context - a Fixed-Length Context Header or Variable-Length Context
Header(s) contain an OAM command or data. Header(s) contain an OAM command or data.
- the type of payload is determined by the Next Protocol field. - the type of payload is determined by the Next Protocol field.
o O bit set and the Next Protocol value is one of identifying active * O bit set and the Next Protocol value is one of identifying active
or hybrid OAM protocol: or hybrid OAM protocol:
- the payload that immediately follows SFC NSH MUST contain an - the payload that immediately follows SFC NSH MUST contain an
OAM command or data. OAM command or data.
o O bit is clear: * O bit is clear:
- no OAM in a Fixed-Length Context Header or Variable-Length - no OAM in a Fixed-Length Context Header or Variable-Length
Context Header(s). Context Header(s).
- the payload determined by the Next Protocol field's value - the payload determined by the Next Protocol field's value
MUST be present. MUST be present.
o O bit is clear and the Next Protocol field's value identifies * O bit is clear and the Next Protocol field's value identifies
active or hybrid OAM protocol MUST be identified and reported as active or hybrid OAM protocol MUST be identified and reported as
the erroneous combination. An implementation MAY have control to the erroneous combination. An implementation MAY have control to
enable processing of the OAM payload. enable processing of the OAM payload.
One conclusion from the above-listed rules of processing O bit and One conclusion from the above-listed rules of processing O bit and
the Next Protocol field's value is to avoid the combination of OAM in the Next Protocol field's value is to avoid the combination of OAM in
an NSH Context Header (Fixed-Length or Variable-Length) and the an NSH Context Header (Fixed-Length or Variable-Length) and the
payload immediately following the SFC NSH because there is no payload immediately following the SFC NSH because there is no
unambiguous way to identify such combination using the O bit and the unambiguous way to identify such combination using the O bit and the
Next Protocol field. Next Protocol field.
skipping to change at page 9, line 19 skipping to change at page 9, line 19
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Reply mode | Return Code |Return Subcode | | Message Type | Reply mode | Return Code |Return Subcode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Handle | | Sender's Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~ ~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: SFC Echo Request/Reply Format Figure 3: SFC Echo Request/Reply Format
The interpretation of the fields is as follows: The interpretation of the fields is as follows:
Version (V) is a two-bit field that indicates the current version Version (V) is a two-bit field that indicates the current version
of the SFC Echo Request/Reply. The current value is 0. The of the SFC Echo Request/Reply. The current value is 0. The
version number is to be incremented whenever a change is made that version number is to be incremented whenever a change is made that
affects the ability of an implementation to parse or process affects the ability of an implementation to parse or process
control packet correctly. control packet correctly.
Reserved - fourteen-bit field. It MUST be zeroed on transmission Reserved - fourteen-bit field. It MUST be zeroed on transmission
skipping to change at page 10, line 18 skipping to change at page 10, line 18
increasing in the course of the test session. increasing in the course of the test session.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Length | | Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value ~ ~ Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: SFC Echo Request/Reply TLV Format Figure 4: SFC Echo Request/Reply TLV Format
TLV is a variable-length field. Multiple TLVs MAY be placed in an TLV is a variable-length field. Multiple TLVs MAY be placed in an
SFC Echo Request/Reply packet. Additional TLVs may be enclosed SFC Echo Request/Reply packet. Additional TLVs may be enclosed
within a given TLV, subject to the semantics of the (outer) TLV in within a given TLV, subject to the semantics of the (outer) TLV in
question. If more than one TLV is to be included, the value of the question. If more than one TLV is to be included, the value of the
Type field of the outmost outer TLV MUST be set to Multiple TLVs Used Type field of the outmost outer TLV MUST be set to Multiple TLVs Used
(TBA12), as assigned by IANA according to Section 8.7. Figure 4 (TBA12), as assigned by IANA according to Section 8.7. Figure 4
presents the format of an SFC Echo Request/Reply TLV, where fields presents the format of an SFC Echo Request/Reply TLV, where fields
are defined as the following: are defined as the following:
skipping to change at page 11, line 5 skipping to change at page 11, line 5
Value - a variable-length field. The value of the Type field Value - a variable-length field. The value of the Type field
determines its interpretation and encoding. determines its interpretation and encoding.
5.1. Return Codes 5.1. Return Codes
The value of the Return Code field is set to zero by the sender of an The value of the Return Code field is set to zero by the sender of an
Echo Request. The receiver of said Echo Request can set it to one of Echo Request. The receiver of said Echo Request can set it to one of
the values listed in Table 1 in the corresponding Echo Reply that it the values listed in Table 1 in the corresponding Echo Reply that it
generates. generates.
+-------+--------------------------------------------+ +=======+============================================+
| Value | Description | | Value | Description |
+-------+--------------------------------------------+ +=======+============================================+
| 0 | No Return Code | | 0 | No Return Code |
+-------+--------------------------------------------+
| 1 | Malformed Echo Request received | | 1 | Malformed Echo Request received |
+-------+--------------------------------------------+
| 2 | One or more of the TLVs was not understood | | 2 | One or more of the TLVs was not understood |
+-------+--------------------------------------------+
| 3 | Authentication failed | | 3 | Authentication failed |
+-------+--------------------------------------------+ +-------+--------------------------------------------+
Table 1: SFC Echo Return Codes Table 1: SFC Echo Return Codes
5.2. Authentication in Echo Request/Reply 5.2. Authentication in Echo Request/Reply
Authentication can be used to protect the integrity of the Authentication can be used to protect the integrity of the
information in SFC Echo Request and/or Echo Reply. In the information in SFC Echo Request and/or Echo Reply. In the
[I-D.ietf-sfc-nsh-integrity] a variable-length Context Header has [I-D.ietf-sfc-nsh-integrity] a variable-length Context Header has
skipping to change at page 11, line 40 skipping to change at page 11, line 43
SFC Echo Request control packet MUST use the appropriate SFC Echo Request control packet MUST use the appropriate
encapsulation of the monitored SFP. If the NSH is used, Echo Request encapsulation of the monitored SFP. If the NSH is used, Echo Request
MUST set O bit, as defined in [RFC8300]. SFC NSH MUST be immediately MUST set O bit, as defined in [RFC8300]. SFC NSH MUST be immediately
followed by the SFC Active OAM Header defined in Section 4. The followed by the SFC Active OAM Header defined in Section 4. The
Message Type field's value in the SFC Active OAM Header MUST be set Message Type field's value in the SFC Active OAM Header MUST be set
to SFC Echo Request/Echo Reply value (TBA2) per Section 8.2. to SFC Echo Request/Echo Reply value (TBA2) per Section 8.2.
Value of the Reply Mode field MAY be set to: Value of the Reply Mode field MAY be set to:
o Do Not Reply (TBA5) if one-way monitoring is desired. If the Echo * Do Not Reply (TBA5) if one-way monitoring is desired. If the Echo
Request is used to measure synthetic packet loss; the receiver may Request is used to measure synthetic packet loss; the receiver may
report loss measurement results to a remote node. report loss measurement results to a remote node.
o Reply via an IPv4/IPv6 UDP Packet (TBA6) value likely will be the * Reply via an IPv4/IPv6 UDP Packet (TBA6) value likely will be the
most used. most used.
o Reply via Application Level Control Channel (TBA7) value if the * Reply via Application Level Control Channel (TBA7) value if the
SFP may have bi-directional paths. SFP may have bi-directional paths.
o Reply via Specified Path (TBA8) value to enforce the use of the * Reply via Specified Path (TBA8) value to enforce the use of the
particular return path specified in the included TLV to verify bi- particular return path specified in the included TLV to verify bi-
directional continuity and also increase the robustness of the directional continuity and also increase the robustness of the
monitoring by selecting a more stable path. monitoring by selecting a more stable path.
5.4. SFC Echo Request Reception 5.4. SFC Echo Request Reception
Sending an SFC Echo Request to the control plane is triggered by one Sending an SFC Echo Request to the control plane is triggered by one
of the following packet processing exceptions: NSH TTL expiration, of the following packet processing exceptions: NSH TTL expiration,
NSH Service Index (SI) expiration or the receiver is the terminal SFF NSH Service Index (SI) expiration or the receiver is the terminal SFF
for an SFP. for an SFP.
skipping to change at page 12, line 49 skipping to change at page 13, line 4
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Errored TLVs | Reserved | Length | | Errored TLVs | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Value |
. . . .
. . . .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Errored TLVs TLV
Figure 5: Errored TLVs TLV
where where
The Errored TLVs Type MUST be set to TBA14 Section 8.7. The Errored TLVs Type MUST be set to TBA14 Section 8.7.
Reserved - one-octet-long field. Reserved - one-octet-long field.
Length - two-octet-long field equal to the length of the Value Length - two-octet-long field equal to the length of the Value
field in octets. field in octets.
skipping to change at page 13, line 43 skipping to change at page 13, line 44
TLV Figure 6. TLV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ID | Reserved | Length | | Source ID | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: SFC Source TLV Figure 6: SFC Source TLV
where where
Source ID Type is a one-octet-long field and has the value of Source ID Type is a one-octet-long field and has the value of
TBA13 Section 8.7. TBA13 Section 8.7.
Reserved - one-octet-long field. Reserved - one-octet-long field.
Length is a two-octets-long field, and the value equals the length Length is a two-octets-long field, and the value equals the length
of the Value field in octets. of the Value field in octets.
skipping to change at page 14, line 19 skipping to change at page 14, line 21
control message, IPv4 or IPv6. control message, IPv4 or IPv6.
The UDP destination port for SFC Echo Reply TBA15 will be allocated The UDP destination port for SFC Echo Reply TBA15 will be allocated
by IANA Section 8.8. by IANA Section 8.8.
5.6. SFC Echo Reply Reception 5.6. SFC Echo Reply Reception
An SFF SHOULD NOT accept SFC Echo Reply unless the received passes An SFF SHOULD NOT accept SFC Echo Reply unless the received passes
the following checks: the following checks:
o the received SFC Echo Reply is well-formed; * the received SFC Echo Reply is well-formed;
o it has an outstanding SFC Echo Request sent from the UDP port that * it has an outstanding SFC Echo Request sent from the UDP port that
matches destination UDP port number of the received packet; matches destination UDP port number of the received packet;
o if the matching to the Echo Request found, the value of the * if the matching to the Echo Request found, the value of the
Sender's Handle n the Echo Request sent is equal to the value of Sender's Handle n the Echo Request sent is equal to the value of
Sender's Handle in the Echo Reply received; Sender's Handle in the Echo Reply received;
o if all checks passed, the SFF checks if the Sequence Number in the * if all checks passed, the SFF checks if the Sequence Number in the
Echo Request sent matches to the Sequence Number in the Echo Reply Echo Request sent matches to the Sequence Number in the Echo Reply
received. received.
6. Security Considerations 6. Security Considerations
When the integrity protection for SFC active OAM, and SFC Echo When the integrity protection for SFC active OAM, and SFC Echo
Request/Reply in particular, is required, it is RECOMMENDED to use Request/Reply in particular, is required, it is RECOMMENDED to use
one of Context Headers defined in [I-D.ietf-sfc-nsh-integrity]. one of Context Headers defined in [I-D.ietf-sfc-nsh-integrity].
MAC#1 (Message Authentication Code) Context Header could be more MAC#1 (Message Authentication Code) Context Header could be more
suitable for active SFC OAM because it does not require re- suitable for active SFC OAM because it does not require re-
skipping to change at page 15, line 36 skipping to change at page 15, line 40
Authors greatly appreciate thorough review and the most helpful Authors greatly appreciate thorough review and the most helpful
comments from Dan Wing, Dirk von Hugo, and Mohamed Boucadair. comments from Dan Wing, Dirk von Hugo, and Mohamed Boucadair.
8. IANA Considerations 8. IANA Considerations
8.1. SFC Active OAM Protocol 8.1. SFC Active OAM Protocol
IANA is requested to assign a new type from the SFC Next Protocol IANA is requested to assign a new type from the SFC Next Protocol
registry as follows: registry as follows:
+-------+----------------+---------------+ +=======+================+===============+
| Value | Description | Reference | | Value | Description | Reference |
+-------+----------------+---------------+ +=======+================+===============+
| TBA1 | SFC Active OAM | This document | | TBA1 | SFC Active OAM | This document |
+-------+----------------+---------------+ +-------+----------------+---------------+
Table 2: SFC Active OAM Protocol Table 2: SFC Active OAM Protocol
8.2. SFC Active OAM Message Type 8.2. SFC Active OAM Message Type
IANA is requested to create a new registry called "SFC Active OAM IANA is requested to create a new registry called "SFC Active OAM
Message Type". All code points in the range 1 through 32767 in this Message Type". All code points in the range 1 through 32767 in this
registry shall be allocated according to the "IETF Review" procedure registry shall be allocated according to the "IETF Review" procedure
specified in [RFC8126]. The remaining code points to be allocated specified in [RFC8126]. The remaining code points to be allocated
according to Table 3: according to Table 3:
+---------------+-------------+-------------------------+ +===============+=============+=========================+
| Value | Description | Reference | | Value | Description | Reference |
+---------------+-------------+-------------------------+ +===============+=============+=========================+
| 0 | Reserved | | | 0 | Reserved | |
+---------------+-------------+-------------------------+
| 1 - 32767 | Reserved | IETF Consensus | | 1 - 32767 | Reserved | IETF Consensus |
+---------------+-------------+-------------------------+
| 32768 - 65530 | Reserved | First Come First Served | | 32768 - 65530 | Reserved | First Come First Served |
+---------------+-------------+-------------------------+
| 65531 - 65534 | Reserved | Private Use | | 65531 - 65534 | Reserved | Private Use |
+---------------+-------------+-------------------------+
| 65535 | Reserved | | | 65535 | Reserved | |
+---------------+-------------+-------------------------+ +---------------+-------------+-------------------------+
Table 3: SFC Active OAM Message Type Table 3: SFC Active OAM Message Type
IANA is requested to assign a new type from the SFC Active OAM IANA is requested to assign a new type from the SFC Active OAM
Message Type registry as follows: Message Type registry as follows:
+-------+-----------------------------+---------------+ +=======+=============================+===============+
| Value | Description | Reference | | Value | Description | Reference |
+-------+-----------------------------+---------------+ +=======+=============================+===============+
| TBA2 | SFC Echo Request/Echo Reply | This document | | TBA2 | SFC Echo Request/Echo Reply | This document |
+-------+-----------------------------+---------------+ +-------+-----------------------------+---------------+
Table 4: SFC Echo Request/Echo Reply Type Table 4: SFC Echo Request/Echo Reply Type
8.3. SFC Echo Request/Echo Reply Parameters 8.3. SFC Echo Request/Echo Reply Parameters
IANA is requested to create a new SFC Echo Request/Echo Reply IANA is requested to create a new SFC Echo Request/Echo Reply
Parameters registry. Parameters registry.
skipping to change at page 17, line 5 skipping to change at page 17, line 7
IANA is requested to create in the SFC Echo Request/Echo Reply IANA is requested to create in the SFC Echo Request/Echo Reply
Parameters registry the new sub-registry Message Types. All code Parameters registry the new sub-registry Message Types. All code
points in the range 1 through 175 in this registry shall be allocated points in the range 1 through 175 in this registry shall be allocated
according to the "IETF Review" procedure specified in [RFC8126]. according to the "IETF Review" procedure specified in [RFC8126].
Code points in the range 176 through 239 in this registry shall be Code points in the range 176 through 239 in this registry shall be
allocated according to the "First Come First Served" procedure allocated according to the "First Come First Served" procedure
specified in [RFC8126]. The remaining code points are allocated specified in [RFC8126]. The remaining code points are allocated
according to Table 5: as specified in Table 5. according to Table 5: as specified in Table 5.
+-----------+--------------+---------------+ +===========+==============+===============+
| Value | Description | Reference | | Value | Description | Reference |
+-----------+--------------+---------------+ +===========+==============+===============+
| 0 | Reserved | This document | | 0 | Reserved | This document |
+-----------+--------------+---------------+
| 1- 175 | Unassigned | This document | | 1- 175 | Unassigned | This document |
+-----------+--------------+---------------+
| 176 - 239 | Unassigned | This document | | 176 - 239 | Unassigned | This document |
+-----------+--------------+---------------+
| 240 - 251 | Experimental | This document | | 240 - 251 | Experimental | This document |
+-----------+--------------+---------------+
| 252 - 254 | Private Use | This document | | 252 - 254 | Private Use | This document |
+-----------+--------------+---------------+
| 255 | Reserved | This document | | 255 | Reserved | This document |
+-----------+--------------+---------------+ +-----------+--------------+---------------+
Table 5: SFC Echo Request/Echo Reply Message Types Table 5: SFC Echo Request/Echo Reply
Message Types
IANA is requested to assign values as listed in Table 6. IANA is requested to assign values as listed in Table 6.
+-------+------------------+---------------+ +=======+==================+===============+
| Value | Description | Reference | | Value | Description | Reference |
+-------+------------------+---------------+ +=======+==================+===============+
| TBA3 | SFC Echo Request | This document | | TBA3 | SFC Echo Request | This document |
+-------+------------------+---------------+
| TBA4 | SFC Echo Reply | This document | | TBA4 | SFC Echo Reply | This document |
+-------+------------------+---------------+ +-------+------------------+---------------+
Table 6: SFC Echo Request/Echo Reply Message Types Values Table 6: SFC Echo Request/Echo Reply
Message Types Values
8.5. SFC Echo Reply Modes 8.5. SFC Echo Reply Modes
IANA is requested to create in the SFC Echo Request/Echo Reply IANA is requested to create in the SFC Echo Request/Echo Reply
Parameters registry the new sub-registry Reply Mode. All code points Parameters registry the new sub-registry Reply Mode. All code points
in the range 1 through 175 in this registry shall be allocated in the range 1 through 175 in this registry shall be allocated
according to the "IETF Review" procedure specified in [RFC8126]. according to the "IETF Review" procedure specified in [RFC8126].
Code points in the range 176 through 239 in this registry shall be Code points in the range 176 through 239 in this registry shall be
allocated according to the "First Come First Served" procedure allocated according to the "First Come First Served" procedure
specified in [RFC8126]. The remaining code points are allocated specified in [RFC8126]. The remaining code points are allocated
according to Table 7: as specified in Table 7. according to Table 7: as specified in Table 7.
+-----------+--------------+---------------+ +===========+==============+===============+
| Value | Description | Reference | | Value | Description | Reference |
+-----------+--------------+---------------+ +===========+==============+===============+
| 0 | Reserved | This document | | 0 | Reserved | This document |
+-----------+--------------+---------------+
| 1- 175 | Unassigned | This document | | 1- 175 | Unassigned | This document |
+-----------+--------------+---------------+
| 176 - 239 | Unassigned | This document | | 176 - 239 | Unassigned | This document |
+-----------+--------------+---------------+
| 240 - 251 | Experimental | This document | | 240 - 251 | Experimental | This document |
+-----------+--------------+---------------+
| 252 - 254 | Private Use | This document | | 252 - 254 | Private Use | This document |
+-----------+--------------+---------------+
| 255 | Reserved | This document | | 255 | Reserved | This document |
+-----------+--------------+---------------+ +-----------+--------------+---------------+
Table 7: SFC Echo Reply Mode Table 7: SFC Echo Reply Mode
All code points in the range 1 through 191 in this registry shall be All code points in the range 1 through 191 in this registry shall be
allocated according to the "IETF Review" procedure specified in allocated according to the "IETF Review" procedure specified in
[RFC8126] and assign values as listed in Table 8. [RFC8126] and assign values as listed in Table 8.
+-------+-----------------------------------------------+-----------+ +=======+====================================+===============+
| Value | Description | Reference | | Value | Description | Reference |
+-------+-----------------------------------------------+-----------+ +=======+====================================+===============+
| 0 | Reserved | | | 0 | Reserved | |
| TBA5 | Do Not Reply | This docu | +-------+------------------------------------+---------------+
| | | ment | | TBA5 | Do Not Reply | This document |
| TBA6 | Reply via an IPv4/IPv6 UDP Packet | This docu | +-------+------------------------------------+---------------+
| | | ment | | TBA6 | Reply via an IPv4/IPv6 UDP Packet | This document |
| TBA7 | Reply via Application Level Control Channel | This docu | +-------+------------------------------------+---------------+
| | | ment | | TBA7 | Reply via Application Level | This document |
| TBA8 | Reply via Specified Path | This docu | | | Control Channel | |
| | | ment | +-------+------------------------------------+---------------+
| TBA9 | Reply via an IPv4/IPv6 UDP Packet with the | This docu | | TBA8 | Reply via Specified Path | This document |
| | data integrity protection | ment | +-------+------------------------------------+---------------+
| TBA10 | Reply via Application Level Control Channel | This docu | | TBA9 | Reply via an IPv4/IPv6 UDP Packet | This document |
| | with the data integrity protection | ment | | | with the data integrity protection | |
| TBA11 | Reply via Specified Path with the data | This docu | +-------+------------------------------------+---------------+
| | integrity protection | ment | | TBA10 | Reply via Application Level | This document |
+-------+-----------------------------------------------+-----------+ | | Control Channel with the data | |
| | integrity protection | |
+-------+------------------------------------+---------------+
| TBA11 | Reply via Specified Path with the | This document |
| | data integrity protection | |
+-------+------------------------------------+---------------+
Table 8: SFC Echo Reply Mode Values Table 8: SFC Echo Reply Mode Values
8.6. SFC Echo Return Codes 8.6. SFC Echo Return Codes
IANA is requested to create in the SFC Echo Request/Echo Reply IANA is requested to create in the SFC Echo Request/Echo Reply
Parameters registry the new sub-registry Return Codes as described in Parameters registry the new sub-registry Return Codes as described in
Table 9. Table 9.
+---------+-------------+-------------------------+ +=========+=============+=========================+
| Value | Description | Reference | | Value | Description | Reference |
+---------+-------------+-------------------------+ +=========+=============+=========================+
| 0-191 | Unassigned | IETF Review | | 0-191 | Unassigned | IETF Review |
+---------+-------------+-------------------------+
| 192-251 | Unassigned | First Come First Served | | 192-251 | Unassigned | First Come First Served |
+---------+-------------+-------------------------+
| 252-254 | Unassigned | Private Use | | 252-254 | Unassigned | Private Use |
+---------+-------------+-------------------------+
| 255 | Reserved | | | 255 | Reserved | |
+---------+-------------+-------------------------+ +---------+-------------+-------------------------+
Table 9: SFC Echo Return Codes Table 9: SFC Echo Return Codes
Values defined for the Return Codes sub-registry are listed in Values defined for the Return Codes sub-registry are listed in
Table 10. Table 10.
+-------+-------------------------------------------+---------------+ +=======+=================================+===============+
| Value | Description | Reference | | Value | Description | Reference |
+-------+-------------------------------------------+---------------+ +=======+=================================+===============+
| 0 | No Return Code | This document | | 0 | No Return Code | This document |
| 1 | Malformed Echo Request received | This document | +-------+---------------------------------+---------------+
| 2 | One or more of the TLVs was not | This document | | 1 | Malformed Echo Request received | This document |
| | understood | | +-------+---------------------------------+---------------+
| 3 | Authentication failed | This document | | 2 | One or more of the TLVs was not | This document |
+-------+-------------------------------------------+---------------+ | | understood | |
+-------+---------------------------------+---------------+
| 3 | Authentication failed | This document |
+-------+---------------------------------+---------------+
Table 10: SFC Echo Return Codes Values Table 10: SFC Echo Return Codes Values
8.7. SFC TLV Type 8.7. SFC TLV Type
IANA is requested to create the SFC OAM TLV Type registry. All code IANA is requested to create the SFC OAM TLV Type registry. All code
points in the range 1 through 175 in this registry shall be allocated points in the range 1 through 175 in this registry shall be allocated
according to the "IETF Review" procedure specified in [RFC8126]. according to the "IETF Review" procedure specified in [RFC8126].
Code points in the range 176 through 239 in this registry shall be Code points in the range 176 through 239 in this registry shall be
allocated according to the "First Come First Served" procedure allocated according to the "First Come First Served" procedure
specified in [RFC8126]. The remaining code points are allocated specified in [RFC8126]. The remaining code points are allocated
according to Table 11: according to Table 11:
+-----------+--------------+---------------+ +===========+==============+===============+
| Value | Description | Reference | | Value | Description | Reference |
+-----------+--------------+---------------+ +===========+==============+===============+
| 0 | Reserved | This document | | 0 | Reserved | This document |
+-----------+--------------+---------------+
| 1- 175 | Unassigned | This document | | 1- 175 | Unassigned | This document |
+-----------+--------------+---------------+
| 176 - 239 | Unassigned | This document | | 176 - 239 | Unassigned | This document |
+-----------+--------------+---------------+
| 240 - 251 | Experimental | This document | | 240 - 251 | Experimental | This document |
+-----------+--------------+---------------+
| 252 - 254 | Private Use | This document | | 252 - 254 | Private Use | This document |
+-----------+--------------+---------------+
| 255 | Reserved | This document | | 255 | Reserved | This document |
+-----------+--------------+---------------+ +-----------+--------------+---------------+
Table 11: SFC OAM TLV Type Registry Table 11: SFC OAM TLV Type Registry
This document defines the following new values in SFC OAM TLV Type This document defines the following new values in SFC OAM TLV Type
registry: registry:
+-------+--------------------+---------------+ +=======+====================+===============+
| Value | Description | Reference | | Value | Description | Reference |
+-------+--------------------+---------------+ +=======+====================+===============+
| TBA12 | Multiple TLVs Used | This document | | TBA12 | Multiple TLVs Used | This document |
+-------+--------------------+---------------+
| TBA13 | Source ID TLV | This document | | TBA13 | Source ID TLV | This document |
+-------+--------------------+---------------+
| TBA14 | Errored TLVs | This document | | TBA14 | Errored TLVs | This document |
+-------+--------------------+---------------+ +-------+--------------------+---------------+
Table 12: SFC OAM Type Values Table 12: SFC OAM Type Values
8.8. SFC OAM UDP Port 8.8. SFC OAM UDP Port
IANA is requested to allocate UDP port number according to IANA is requested to allocate UDP port number according to
+--------+-------+-----------+-------------+------------+-----------+ +=============+============+===================+============+=====================+=============+
| Servic | Port | Transport | Description | Semantics | Reference | |Service Name |Port Number |Transport Protocol |Description |Semantics Definition |Reference |
| e Name | Numbe | Protocol | | Definition | | +=============+============+===================+============+=====================+=============+
| | r | | | | | |SFC OAM |TBA15 |UDP |SFC OAM Echo|Section 5.5 |This document|
+--------+-------+-----------+-------------+------------+-----------+ | | | |Reply | | |
| SFC | TBA15 | UDP | SFC OAM | Section 5. | This docu | +-------------+------------+-------------------+------------+---------------------+-------------+
| OAM | | | Echo Reply | 5 | ment |
+--------+-------+-----------+-------------+------------+-----------+
Table 13: SFC OAM Port Table 13: SFC OAM Port
9. References 9. References
9.1. Normative References 9.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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
skipping to change at page 20, line 41 skipping to change at page 21, line 23
May 2017, <https://www.rfc-editor.org/info/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>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-sfc-nsh-integrity] [I-D.ietf-sfc-nsh-integrity]
Boucadair, M., Reddy.K, T., and D. Wing, "Integrity Boucadair, M., Reddy, T., and D. Wing, "Integrity
Protection for the Network Service Header (NSH) and Protection for the Network Service Header (NSH) and
Encryption of Sensitive Context Headers", draft-ietf-sfc- Encryption of Sensitive Context Headers", Work in
nsh-integrity-03 (work in progress), January 2021. Progress, Internet-Draft, draft-ietf-sfc-nsh-integrity-05,
23 March 2021, <https://tools.ietf.org/html/draft-ietf-
sfc-nsh-integrity-05>.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981, RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>. <https://www.rfc-editor.org/info/rfc792>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005, DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>. <https://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
skipping to change at page 21, line 46 skipping to change at page 22, line 31
R., and A. Ghanwani, "Service Function Chaining (SFC) R., and A. Ghanwani, "Service Function Chaining (SFC)
Operations, Administration, and Maintenance (OAM) Operations, Administration, and Maintenance (OAM)
Framework", RFC 8924, DOI 10.17487/RFC8924, October 2020, Framework", RFC 8924, DOI 10.17487/RFC8924, October 2020,
<https://www.rfc-editor.org/info/rfc8924>. <https://www.rfc-editor.org/info/rfc8924>.
Authors' Addresses Authors' Addresses
Greg Mirsky Greg Mirsky
ZTE Corp. ZTE Corp.
Email: gregimirsky@gmail.com Email: gregimirsky@gmail.com, gregory.mirsky@ztetx.com
Wei Meng Wei Meng
ZTE Corporation ZTE Corporation
No.50 Software Avenue, Yuhuatai District No.50 Software Avenue, Yuhuatai District
Nanjing Nanjing,
China China
Email: meng.wei2@zte.com.cn Email: meng.wei2@zte.com.cn
Bhumip Khasnabish Bhumip Khasnabish
Individual contributor Individual contributor
Email: vumip1@gmail.com Email: vumip1@gmail.com
Cui Wang Cui Wang
 End of changes. 91 change blocks. 
107 lines changed or deleted 143 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/