draft-ietf-sfc-multi-layer-oam-11.txt   draft-ietf-sfc-multi-layer-oam-12.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: 26 November 2021 B. Khasnabish Expires: 5 December 2021 B. Khasnabish
C. Wang C. Wang
Individual contributor Individual contributor
25 May 2021 3 June 2021
Active OAM for Service Function Chaining Active OAM for Service Function Chaining
draft-ietf-sfc-multi-layer-oam-11 draft-ietf-sfc-multi-layer-oam-12
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. Particularly, it updates the This document updates RFC 8300. Particularly, it updates the
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 26 November 2021. This Internet-Draft will expire on 5 December 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 20 skipping to change at page 2, line 20
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements for Active OAM in SFC Network . . . . . . . . . 5 3. Requirements for Active OAM in SFC Network . . . . . . . . . 4
4. Active OAM Identification in the NSH . . . . . . . . . . . . 7 4. Active OAM Identification in the NSH . . . . . . . . . . . . 6
5. Echo Request/Echo Reply for SFC . . . . . . . . . . . . . . . 8 5. Echo Request/Echo Reply for SFC . . . . . . . . . . . . . . . 8
5.1. Return Codes . . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . 13 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
5.7. Tracing an SFP . . . . . . . . . . . . . . . . . . . . . 15 5.7. Tracing an SFP . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8.1. SFC Active OAM Protocol . . . . . . . . . . . . . . . . . 16 8.1. SFC Active OAM Protocol . . . . . . . . . . . . . . . . . 16
8.2. SFC Active OAM Message Type . . . . . . . . . . . . . . . 16 8.2. SFC Active OAM Message Type . . . . . . . . . . . . . . . 16
8.3. SFC Echo Request/Echo Reply Parameters . . . . . . . . . 17 8.3. SFC Echo Request/Echo Reply Parameters . . . . . . . . . 17
8.4. SFC Echo Request/Echo Reply Message Types . . . . . . . . 17 8.4. SFC Echo Request/Echo Reply Message Types . . . . . . . . 17
8.5. SFC Echo Reply Modes . . . . . . . . . . . . . . . . . . 18 8.5. SFC Echo Reply Modes . . . . . . . . . . . . . . . . . . 18
8.6. SFC Echo Return Codes . . . . . . . . . . . . . . . . . . 20 8.6. SFC Echo Return Codes . . . . . . . . . . . . . . . . . . 20
8.7. SFC TLV Type . . . . . . . . . . . . . . . . . . . . . . 21 8.7. SFC TLV Type . . . . . . . . . . . . . . . . . . . . . . 21
8.8. SFC OAM UDP Port . . . . . . . . . . . . . . . . . . . . 21 8.8. SFC OAM UDP Port . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
[RFC7665] defines data plane elements necessary to implement a [RFC7665] defines data plane elements necessary to implement a
Service Function Chaining (SFC). These include: Service Function Chaining (SFC). These include:
1. Classifiers that perform the classification of incoming packets. 1. Classifiers that perform the classification of incoming packets.
Such classification may result in associating a received packet Such classification may result in associating a received packet
to a service function chain. to a service function chain.
skipping to change at page 4, line 31 skipping to change at page 4, line 31
2.2. Acronyms 2.2. Acronyms
E2E: End-to-End E2E: End-to-End
FM: Fault Management FM: Fault Management
NSH: Network Service Header NSH: Network Service Header
OAM: Operations, Administration, and Maintenance OAM: Operations, Administration, and Maintenance
PRNG: Pseudorandom number generator
RDI: Remote Defect Indication
RSP: Rendered Service Path RSP: Rendered Service Path
SF: Service Function SF: Service Function
SFC: Service Function Chain SFC: Service Function Chain
SFF: Service Function Forwarder SFF: Service Function Forwarder
SFP: Service Function Path SFP: Service Function Path
skipping to change at page 5, line 41 skipping to change at page 5, line 33
scope: scope:
REQ#1: Packets of active SFC OAM in SFC SHOULD be fate sharing REQ#1: Packets of active SFC OAM in SFC SHOULD be fate sharing
with the monitored SFC data, in the forward direction from ingress with the monitored SFC data, in the forward direction from ingress
toward egress endpoint(s) of the OAM test. toward egress endpoint(s) of the OAM test.
The fate sharing, in the SFC environment, is achieved when a test The fate sharing, in the SFC environment, is achieved when a test
packet traverses the same path and receives the same treatment in the packet traverses the same path and receives the same treatment in the
transport layer as an SFC NSH packet. transport layer as an SFC NSH packet.
REQ#2: SFC OAM MUST support pro-active monitoring of the REQ#2: SFC OAM MUST support monitoring of the continuity of the
continuity of the SFP between any of its elements. SFP between any of its elements.
A network failure might be declared when several consecutive test A network failure might be declared when several consecutive test
packets are not received within a pre-determined time. For example, packets are not received within a pre-determined time. For example,
in the E2E SFC OAM FM case, the egress, SFF3, in the example in in the E2E SFC OAM FM case, the egress, SFF3, in the example in
Figure 1, could be the entity that detects the SFP's failure by Figure 1, could be the entity that detects the SFP's failure by
monitoring a flow of periodic test packets. The ingress may be monitoring a flow of periodic test packets. The ingress may be
capable of recovering from the failure, e.g., using redundant SFC capable of recovering from the failure, e.g., using redundant SFC
elements. Thus, it is beneficial for the egress to signal the new elements. Thus, it is beneficial for the egress to signal the new
defect state to the ingress, which in this example is the Classifier. defect state to the ingress, which in this example is the Classifier.
Hence the following requirement: Hence the following requirement:
REQ#3: SFC OAM MUST support Remote Defect Indication (RDI) REQ#3: SFC OAM MUST support Remote Defect Indication notification
notification by the egress to the ingress. by the egress to the ingress.
REQ#4: SFC OAM MUST support connectivity verification of the SFP. REQ#4: SFC OAM MUST support connectivity verification of the SFP.
Definition of the misconnection defect, entry and exit criteria Definition of the misconnection defect, entry and exit criteria
are outside the scope of this document. are outside the scope of this document.
Once the SFF1 detects the defect, the objective of the SFC OAM Once the SFF1 detects the defect, the objective of the SFC OAM
changes from the detection of a defect to defect characterization and changes from the detection of a defect to defect characterization and
localization. localization.
REQ#5: SFC OAM MUST support fault localization of the Loss of REQ#5: SFC OAM MUST support fault localization of the Loss of
skipping to change at page 9, line 4 skipping to change at page 8, line 36
active OAM control packet in octets. active OAM control packet in octets.
5. Echo Request/Echo Reply for SFC 5. Echo Request/Echo Reply for SFC
Echo Request/Reply is a well-known active OAM mechanism that is Echo Request/Reply is a well-known active OAM mechanism that is
extensively used to verify a path's continuity, detect extensively used to verify a path's continuity, detect
inconsistencies between a state in control and the data planes, and inconsistencies between a state in control and the data planes, and
localize defects in the data plane. ICMP ([RFC0792] for IPv4 and localize defects in the data plane. ICMP ([RFC0792] for IPv4 and
[RFC4443] for IPv6 networks respectively) and [RFC8029] are examples [RFC4443] for IPv6 networks respectively) and [RFC8029] are examples
of broadly used active OAM protocols based on Echo Request/Reply of broadly used active OAM protocols based on Echo Request/Reply
principle. The SFC NSH Echo Request/Reply control message format is principle. The SFC NSH Echo Request/Reply defined in this document
presented in Figure 3. addresses several requirements listed in Section 3. Specifically, as
defined in this specification, it can be used to check the continuity
of an SFP, trace an SFP, localize the failure of the SFP. The SFC
NSH Echo Request/Reply control message format is presented in
Figure 3.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | Reserved | Global Flags | | V | Reserved | Global Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Reply mode | Return Code |Return Subcode | | Message Type | Reply mode | Return Code |Return Subcode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Handle | | Sender's Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 10, line 8 skipping to change at page 9, line 49
Return Codes and Subcodes are one-octet fields each. These can be Return Codes and Subcodes are one-octet fields each. These can be
used to inform the sender about the result of processing its used to inform the sender about the result of processing its
request. Initial Return Code values are according to Table 1. request. Initial Return Code values are according to Table 1.
For all Return Code values defined in this document, the value of For all Return Code values defined in this document, the value of
the Return Subcode field MUST be set to zero. the Return Subcode field MUST be set to zero.
The Sender's Handle is a four-octet field. It is filled in by the The Sender's Handle is a four-octet field. It is filled in by the
sender of the Echo Request and returned unchanged by the Echo sender of the Echo Request and returned unchanged by the Echo
Reply sender. The sender of the Echo Request MAY use a pseudo- Reply sender. The sender of the Echo Request MAY use a pseudo-
random number generator (PRNG) to set the value of the Sender's random number generator to set the value of the Sender's Handle
Handle field. field.
The Sequence Number is a four-octet field. It is assigned by the The Sequence Number is a four-octet field. It is assigned by the
sender and can be (for example) used to detect missed replies. sender and can be (for example) used to detect missed replies.
The value of the Sequence Number field SHOULD be monotonically The value of the Sequence Number field SHOULD be monotonically
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 |
skipping to change at page 12, line 21 skipping to change at page 12, line 12
* 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.
* 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.
* 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.
[I-D.ao-sfc-oam-return-path-specified] provides an example of the
defining a specific path for the Echo Reply.
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 NSH Service Index (SI) expiration, or the receiver is the terminal
SFF for an SFP. SFF for an SFP.
Firstly, if the SFC Echo Request is authenticated, the receiving SFF Firstly, if the SFC Echo Request is authenticated, the receiving SFF
MUST verify the authentication. If the verification fails, the MUST verify the authentication. If the verification fails, the
skipping to change at page 13, line 44 skipping to change at page 13, line 36
field in octets. field in octets.
The Value field contains the TLVs, encoded as sub-TLVs, that were The Value field contains the TLVs, encoded as sub-TLVs, that were
not understood or failed to be parsed correctly. not understood or failed to be parsed correctly.
5.5. SFC Echo Reply Transmission 5.5. SFC Echo Reply Transmission
The Reply Mode field directs whether and how the Echo Reply message The Reply Mode field directs whether and how the Echo Reply message
should be sent. The sender of the Echo Request MAY use TLVs to should be sent. The sender of the Echo Request MAY use TLVs to
request that the corresponding Echo Reply is transmitted over the request that the corresponding Echo Reply is transmitted over the
specified path. Value TBA3 is referred to as the "Do not reply" mode specified path. [I-D.ao-sfc-oam-return-path-specified] provides an
and suppresses the Echo Reply packet transmission. The default value example of a TLV that can be used to specify the path of the Echo
Reply. Value TBA3 is referred to as the "Do not reply" mode and
suppresses the Echo Reply packet transmission. The default value
(TBA6) for the Reply mode field requests the responder to send the (TBA6) for the Reply mode field requests the responder to send the
Echo Reply packet out-of-band as IPv4 or IPv6 UDP packet. Echo Reply packet out-of-band as IPv4 or IPv6 UDP packet.
Responder to the SFC Echo Request sends the Echo Reply over IP Responder to the SFC Echo Request sends the Echo Reply over IP
network if the Reply mode is Reply via an IPv4/IPv6 UDP Packet. network if the Reply mode is Reply via an IPv4/IPv6 UDP Packet.
Because the NSH does not identify the ingress node that generated the Because the NSH does not identify the ingress node that generated the
Echo Request, the source ID MUST be included in the message and used Echo Request, the source ID MUST be included in the message and used
as the IP destination address for IP/UDP encapsulation of the SFC as the IP destination address for IP/UDP encapsulation of the SFC
Echo Reply. The sender of the SFC Echo Request MUST include SFC Echo Reply. The sender of the SFC Echo Request MUST include SFC
Source TLV Figure 6. Source TLV Figure 6.
skipping to change at page 15, line 11 skipping to change at page 15, line 7
* 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 in the Echo Request sent is equal to the value of Sender's Handle in 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;
* 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.
5.7. Tracing an SFP 5.7. Tracing an SFP
SFP Echo Request/Reply can be used to isolate a defect detected in SFC Echo Request/Reply can be used to isolate a defect detected in
the SFP and trace an RSP. As for ICMP echo request/reply [RFC0792] the SFP and trace an RSP. As for ICMP echo request/reply [RFC0792]
and MPLS echo request/reply [RFC8029], this mode is referred to as and MPLS echo request/reply [RFC8029], this mode is referred to as
"traceroute". In the traceroute mode, the sender transmits a "traceroute". In the traceroute mode, the sender transmits a
sequence of SFP Echo Request messages starting with the NSH TTL value sequence of SFC Echo Request messages starting with the NSH TTL value
set to 1 and is incremented by 1 in each next Echo Request packet. set to 1 and is incremented by 1 in each next Echo Request packet.
The sender stops transmitting SFP Echo Request packets when the The sender stops transmitting SFC Echo Request packets when the
Return Code in the received Echo Reply equals 5 ("End of the SFP"). Return Code in the received Echo Reply equals 5 ("End of the SFP").
To trace a particular RSP, the sender may use NSH MD Type 2 Flow ID Suppose a specialized information element (e.g., IPv6 Flow Label
TLV [I-D.ietf-sfc-nsh-tlv]. The value of the Flow ID field of the [RFC6437] or Flow ID [I-D.ietf-sfc-nsh-tlv]) is used for distributing
SFP Echo Request packet MUST be set to the same value as of the the load across Equal Cost Multi-Path or Link Aggregation Group
monitored flow. paths. In that case, such an element MAY also be used for the SFC
OAM traffic. Doing so is meant to control whether the SFC Echo
Request follows the same RSP as the monitored flow.
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-
calculation of the MAC when the value of the NSH Base Header's TTL calculation of the MAC when the value of the NSH Base Header's TTL
field is changed. The integrity protection for SFC active OAM can field is changed. The integrity protection for SFC active OAM can
skipping to change at page 22, line 33 skipping to change at page 22, line 33
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>.
[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.ao-sfc-oam-return-path-specified]
Mirsky, G., Ao, T., Chen, Z., and G. Mishra, "Controlled
Return Path for Service Function Chain (SFC) OAM", Work in
Progress, Internet-Draft, draft-ao-sfc-oam-return-path-
specified-09, 30 March 2021, <https://tools.ietf.org/html/
draft-ao-sfc-oam-return-path-specified-09>.
[I-D.ietf-sfc-nsh-integrity] [I-D.ietf-sfc-nsh-integrity]
Boucadair, M., Reddy, 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", Work in Encryption of Sensitive Context Headers", Work in
Progress, Internet-Draft, draft-ietf-sfc-nsh-integrity-05, Progress, Internet-Draft, draft-ietf-sfc-nsh-integrity-05,
23 March 2021, <https://tools.ietf.org/html/draft-ietf- 23 March 2021, <https://tools.ietf.org/html/draft-ietf-
sfc-nsh-integrity-05>. sfc-nsh-integrity-05>.
[I-D.ietf-sfc-nsh-tlv] [I-D.ietf-sfc-nsh-tlv]
Wei, Y. (., Elzur, U., Majee, S., and C. Pignataro, Wei, Y. (., Elzur, U., Majee, S., and C. Pignataro,
skipping to change at page 23, line 19 skipping to change at page 23, line 30
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005, RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>. <https://www.rfc-editor.org/info/rfc4303>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89, Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006, RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>. <https://www.rfc-editor.org/info/rfc4443>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011,
<https://www.rfc-editor.org/info/rfc6437>.
[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>.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <https://www.rfc-editor.org/info/rfc7799>. May 2016, <https://www.rfc-editor.org/info/rfc7799>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
 End of changes. 21 change blocks. 
30 lines changed or deleted 48 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/