< draft-ietf-sfc-oam-packet-00.txt   draft-ietf-sfc-oam-packet-01.txt >
sfc M. Boucadair sfc M. Boucadair
Internet-Draft Orange Internet-Draft Orange
Updates: 8300 (if approved) 25 March 2022 Updates: 8300 (if approved) 25 April 2022
Intended status: Standards Track Intended status: Standards Track
Expires: 26 September 2022 Expires: 27 October 2022
OAM Packet and Behavior in the Network Service Header (NSH) OAM Packet and Behavior in the Network Service Header (NSH)
draft-ietf-sfc-oam-packet-00 draft-ietf-sfc-oam-packet-01
Abstract Abstract
This document clarifies an ambiguity in the Network Service Header This document clarifies an ambiguity in the Network Service Header
(NSH) specification related to the handling of O bit. In particular, (NSH) specification related to the handling of O bit. In particular,
this document clarifies the meaning of "OAM packet". this document clarifies the meaning of "OAM packet".
This document updates RFC 8300. This document updates RFC 8300.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 September 2022. This Internet-Draft will expire on 27 October 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 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 (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 12 skipping to change at page 2, line 12
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. An Update to RFC8300 . . . . . . . . . . . . . . . . . . . . 3 3. An Update to RFC8300 . . . . . . . . . . . . . . . . . . . . 3
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 5 7.2. Informative References . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
This document clarifies an ambiguity related to the definition of This document clarifies an ambiguity related to the definition of
Operations, Administration, and Maintenance (OAM) packet discussed in Operations, Administration, and Maintenance (OAM) packet discussed in
[RFC8300]. [RFC8300].
The processing of the O bit in the Network Service Header (NSH) must The processing of the O bit in the Network Service Header (NSH) must
follow the updated behavior specified in Section 3. follow the updated behavior specified in Section 3.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This document makes use of the terms defined in [RFC7665] and This document makes use of the terms defined in [RFC7665] and
[RFC8300]. [RFC8300].
The document defines the following terms: The document defines the following terms:
SFC data plane element: refers to SFC-aware SF, SFF, SFC Proxy, or SFC data plane element: refers to SFC-aware SF, SFF, SFC Proxy, or
Classifier as defined in the SFC data plane architecture [RFC7665] Classifier as defined in the SFC data plane architecture [RFC7665]
and further refined in [RFC8300]. and further refined in [RFC8300].
OAM control element: an NSH-aware elements that is capable of OAM control element: an NSH-aware element that is capable of
generating NSH OAM packets. An SFC data plane element may behave generating NSH OAM packets. An SFC data plane element may behave
as an OAM control element. as an OAM control element.
OAM data: refers to an OAM request (e.g., Connectivity Verification SFC OAM data: refers to an OAM request (e.g., Connectivity
and Continuity Checks [RFC7276]), any data that influences how to Verification and Continuity Checks [RFC7276]), any data that
execute a companion OAM request (e.g., identity of a terminating influences how to execute a companion OAM request (e.g., identity
Service Function (SF)), the output data of an OAM request, and any of a terminating Service Function (SF)), the output data of an OAM
combination thereof. request, and any combination thereof.
User data: refers to user packets cited in Section 5.7 of [RFC7665]. User data: refers to user packets cited in Section 5.7 of [RFC7665].
3. An Update to RFC8300 3. An Update to RFC8300
This document updates Section 2.2 of [RFC8300] as follows: This document updates Section 2.2 of [RFC8300] as follows:
OLD: OLD:
O bit: Setting this bit indicates an OAM packet (see [RFC6291]). O bit: Setting this bit indicates an OAM packet (see [RFC6291]).
skipping to change at page 3, line 34 skipping to change at page 3, line 34
OAM packets unmodified to the next element in the chain. OAM packets unmodified to the next element in the chain.
Forwarding OAM packets unmodified by SFC elements that do not Forwarding OAM packets unmodified by SFC elements that do not
support SFC OAM procedures may be acceptable for a subset of OAM support SFC OAM procedures may be acceptable for a subset of OAM
functions, but it can result in unexpected outcomes for others; functions, but it can result in unexpected outcomes for others;
thus, it is recommended to analyze the impact of forwarding an OAM thus, it is recommended to analyze the impact of forwarding an OAM
packet for all OAM functions prior to enabling this behavior. The packet for all OAM functions prior to enabling this behavior. The
configurable parameter MUST be disabled by default. configurable parameter MUST be disabled by default.
NEW: NEW:
O bit: Setting this bit indicates an SFC OAM packet. Such a packet O bit: Setting this bit indicates an NSH OAM packet. Such a packet
is any NSH-encapsulated packet that exclusively includes OAM data. is any NSH-encapsulated packet that exclusively includes SFC OAM
An OAM data can be included in the Fixed-Length Context Header, data. SFC OAM data can be included in the Fixed-Length Context
optional Context Headers, and/or the inner packet. Header, optional Context Headers, and/or the inner packet.
The O bit is typically set by an OAM controller or a final The O bit is typically set by an OAM controller or a final
destination of an SFC OAM packet that triggers a response (e.g., a destination of an NSH OAM packet that triggers a response (e.g., a
specific SFC-aware SF, the last SFF of an SFP). specific SFC-aware SF, the last SFF of an SFP).
The O bit MUST be set for SFC OAM packets and MUST NOT be set for The O bit MUST be set for NSH OAM packets and MUST NOT be set for
non-OAM packets. The O bit MUST NOT be modified along the SFP. non-OAM packets. The O bit MUST NOT be modified along the SFP.
NSH-encapsulated packets that include user data are not considered NSH-encapsulated packets that include user data are not considered
as SFC OAM packets even if some OAM data (e.g., record route) is as NSH OAM packets even if some SFC OAM data (e.g., record route)
also supplied in the packet. is also supplied in the packet.
When an OAM data is included in the inner packet, the Next When SFC OAM data is included in the inner packet, the Next
Protocol field is set to reflect the structure of that inner OAM Protocol field is set to reflect the structure of that inner OAM
packet. The setting and processing of the O bit neither assumes packet. The setting and processing of the O bit neither assumes
nor expects detailed analysis of the content of any inner IP nor expects detailed analysis of the content of any inner IP
packet carried by the NSH. As such, SFFs, SFC-aware SFs, and SFC packet carried by the NSH. As such, SFFs, SFC-aware SFs, and SFC
Proxies SHOULD discard any NSH packets with the O bit set and Next Proxies SHOULD discard any NSH packets with the O bit set and Next
Protocol set to something that is not itself an OAM protocol. Protocol set to something that is not itself an OAM protocol.
This includes discarding the packet when the O bit is set and the This includes discarding the packet when the O bit is set and the
Next Protocol is set to 0x01 (IPv4), 0x02 (IPv6), 0x03 (MPLS), or Next Protocol is set to 0x01 (IPv4), 0x02 (IPv6), 0x03 (MPLS), or
0x05 (Ethernet). 0x05 (Ethernet).
An SFC OAM packet MAY include optional Context Headers (e.g., a An NSH OAM packet MAY include optional Context Headers (e.g., a
subscriber identifier [RFC8979] or a flow identifier subscriber identifier [RFC8979] or a flow identifier
[I-D.ietf-sfc-nsh-tlv]) that are used to influence the processing [I-D.ietf-sfc-nsh-tlv]) that are used to influence the processing
of the packet by SFC data plane elements. of the packet by SFC data plane elements.
An SFC OAM packet MAY include OAM data in both Context Headers and An NSH OAM packet MAY include SFC OAM data in both Context Headers
the inner packet. The processing (including the order) of the OAM and the inner packet. The processing (including the order) of the
data SHOULD be specified in the relevant OAM or Context Header SFC OAM data SHOULD be specified in the relevant OAM or Context
specification. Header specification.
SFC-aware SF/SFF/SFC Proxy/Classifier implementations that do not SFC-aware SF/SFF/SFC Proxy/Classifier implementations that do not
support SFC OAM procedures SHOULD discard packets with O bit set, support SFC OAM procedures SHOULD discard packets with O bit set,
but MAY support a configurable parameter to enable forwarding but MAY support a configurable parameter to enable forwarding
received SFC OAM packets unmodified to the next element in the received NSH OAM packets unmodified to the next element in the
chain. Forwarding SFC OAM packets unmodified by SFC elements that chain. Forwarding NSH OAM packets unmodified by SFC data plane
do not support SFC OAM procedures may be acceptable for a subset elements that do not support SFC OAM procedures may be acceptable
of OAM functions, but it can result in unexpected outcomes for for a subset of OAM functions, but it can result in unexpected
others; thus, it is recommended to analyze the impact of outcomes for others; thus, it is recommended to analyze the impact
forwarding an SFC OAM packet for all OAM functions prior to of forwarding an NSH OAM packet for all OAM functions prior to
enabling this behavior. The configurable parameter MUST be enabling this behavior. The configurable parameter MUST be
disabled by default. disabled by default.
The actual format and additional processing of SFC OAM packets is The actual format and additional processing of NSH OAM packets is
outside the scope of this specification. outside the scope of this specification.
4. IANA Considerations 4. IANA Considerations
This document does not make any request to IANA. This document does not make any request to IANA.
5. Security Considerations 5. Security Considerations
Data plane SFC-related security considerations, including privacy, Data plane SFC-related security considerations, including privacy,
are discussed in Section 6 of [RFC7665] and Section 8 of [RFC8300]. are discussed in Section 6 of [RFC7665] and Section 8 of [RFC8300].
Additional security considerations related to SFC OAM are discussed Additional security considerations related to SFC OAM are discussed
in Section 9 of [RFC8924]. in Section 9 of [RFC8924].
Any data included in an SFC OAM packet SHOULD be integrity-protected Any data included in an NSH OAM packet SHOULD be integrity-protected
[RFC9145]. [RFC9145].
6. Acknowledgements 6. Acknowledgments
Thanks to Jim Guichard, Greg Mirsky, Joel Halpern, Christian Thanks to Jim Guichard, Greg Mirsky, Joel Halpern, Christian
Jacquenet, Dirk von-Hugo, and Carlos Pignataro for the comments. Jacquenet, Dirk von-Hugo, Carlos Pignataro, and Frank Brockners for
the comments.
7. References 7. References
7.1. Normative References 7.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>.
skipping to change at page 5, line 38 skipping to change at page 5, line 39
[RFC9145] Boucadair, M., Reddy.K, T., and D. Wing, "Integrity [RFC9145] Boucadair, M., Reddy.K, 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", RFC 9145, Encryption of Sensitive Context Headers", RFC 9145,
DOI 10.17487/RFC9145, December 2021, DOI 10.17487/RFC9145, December 2021,
<https://www.rfc-editor.org/info/rfc9145>. <https://www.rfc-editor.org/info/rfc9145>.
7.2. Informative References 7.2. Informative References
[I-D.ietf-sfc-nsh-tlv] [I-D.ietf-sfc-nsh-tlv]
Wei, Y., Elzur, U., Majee, S., Pignataro, C., and D. E. Wei, Y., Elzur, U., Majee, S., Pignataro, C., and D. E.
Eastlake, "Network Service Header Metadata Type 2 Eastlake, "Network Service Header (NSH) Metadata Type 2
Variable-Length Context Headers", Work in Progress, Variable-Length Context Headers", Work in Progress,
Internet-Draft, draft-ietf-sfc-nsh-tlv-13, 26 January Internet-Draft, draft-ietf-sfc-nsh-tlv-15, 20 April 2022,
2022, <https://www.ietf.org/archive/id/draft-ietf-sfc-nsh- <https://www.ietf.org/archive/id/draft-ietf-sfc-nsh-tlv-
tlv-13.txt>. 15.txt>.
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
D., and S. Mansfield, "Guidelines for the Use of the "OAM"
Acronym in the IETF", BCP 161, RFC 6291,
DOI 10.17487/RFC6291, June 2011,
<https://www.rfc-editor.org/info/rfc6291>.
[RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y.
Weingarten, "An Overview of Operations, Administration, Weingarten, "An Overview of Operations, Administration,
and Maintenance (OAM) Tools", RFC 7276, and Maintenance (OAM) Tools", RFC 7276,
DOI 10.17487/RFC7276, June 2014, DOI 10.17487/RFC7276, June 2014,
<https://www.rfc-editor.org/info/rfc7276>. <https://www.rfc-editor.org/info/rfc7276>.
[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,
 End of changes. 22 change blocks. 
40 lines changed or deleted 47 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/