rfc9451.original   rfc9451.txt 
sfc M. Boucadair Internet Engineering Task Force (IETF) M. Boucadair
Internet-Draft Orange Request for Comments: 9451 Orange
Updates: 8300 (if approved) 26 March 2023 Updates: 8300 August 2023
Intended status: Standards Track Category: Standards Track
Expires: 27 September 2023 ISSN: 2070-1721
OAM Packet and Behavior in the Network Service Header (NSH) Operations, Administration, and Maintenance (OAM) Packet and Behavior in
draft-ietf-sfc-oam-packet-03 the Network Service Header (NSH)
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
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 27 September 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9451.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2023 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
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology
3. An Update to RFC8300 . . . . . . . . . . . . . . . . . . . . 3 3. An Update to RFC 8300
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 4. IANA Considerations
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 6. References
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. Normative References
7.1. Normative References . . . . . . . . . . . . . . . . . . 5 6.2. Informative References
7.2. Informative References . . . . . . . . . . . . . . . . . 5 Acknowledgments
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address
1. Introduction 1. Introduction
This document clarifies an ambiguity related to the definition of This document clarifies an ambiguity related to the definition of the
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 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
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 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 Service Function (SF), Service Function Chaining (SFC) data plane element: refers to the
Service Function Forwarder (SFF), SFC Proxy, or Classifier as SFC-aware Service Function (SF), Service Function Forwarder (SFF),
defined in the SFC data plane architecture [RFC7665] and further SFC Proxy, or Classifier as defined in the SFC data plane
refined in [RFC8300]. architecture [RFC7665] and further refined in [RFC8300].
OAM control element: an NSH-aware element 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.
SFC OAM data: refers to an OAM request (e.g., Connectivity SFC OAM data: refers to an OAM request (e.g., Connectivity
Verification and Continuity Checks [RFC7276]), any data that Verification and Continuity Checks [RFC7276]), any data that
influences how to execute a companion OAM request (e.g., identity influences how to execute a companion OAM request (e.g., identity
of a terminating SF), the output data of an OAM request, and any of a terminating SF), the output data of an OAM request, and any
combination thereof. 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 RFC 8300
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]).
The actual format and processing of SFC OAM packets is outside
the scope of this specification (for example, see [SFC-OAM-
FRAMEWORK] for one approach).
The O bit MUST be set for OAM packets and MUST NOT be set for | O bit: Setting this bit indicates an OAM packet (see [RFC6291]).
non-OAM packets. The O bit MUST NOT be modified along the SFP. | The actual format and processing of SFC OAM packets is outside
| the scope of this specification (for example, see [SFC-OAM-
SF/SFF/SFC Proxy/Classifier implementations that do not support | FRAMEWORK] for one approach).
SFC OAM procedures SHOULD discard packets with O bit set, but |
MAY support a configurable parameter to enable forwarding | The O bit MUST be set for OAM packets and MUST NOT be set for
received SFC OAM packets unmodified to the next element in the | non-OAM packets. The O bit MUST NOT be modified along the SFP.
chain. Forwarding OAM packets unmodified by SFC elements that |
do not support SFC OAM procedures may be acceptable for a | SF/SFF/SFC Proxy/Classifier implementations that do not support
subset of OAM functions, but it can result in unexpected | SFC OAM procedures SHOULD discard packets with O bit set, but
outcomes for others; thus, it is recommended to analyze the | MAY support a configurable parameter to enable forwarding
impact of forwarding an OAM packet for all OAM functions prior | received SFC OAM packets unmodified to the next element in the
to enabling this behavior. The configurable parameter MUST be | chain. Forwarding OAM packets unmodified by SFC elements that
disabled by default. | do not support SFC OAM procedures may be acceptable for a
| subset of OAM functions, but it can result in unexpected
| outcomes for others; thus, it is recommended to analyze the
| impact of forwarding an OAM packet for all OAM functions prior
| to enabling this behavior. The configurable parameter MUST be
| disabled by default.
NEW: NEW:
O bit: Setting this bit indicates an NSH OAM packet. Such a
packet is any NSH-encapsulated packet that exclusively includes
SFC OAM data. SFC OAM data can be included in the Fixed-Length
Context Header, optional Context Headers, and/or the inner
packet.
The O bit is typically set by an OAM controller or a final
destination of an NSH OAM packet that triggers a response
(e.g., a specific SFC-aware SF, the last SFF of an SFP).
The O bit MUST be set for NSH OAM packets and MUST NOT be set | O bit: Setting this bit indicates an NSH OAM packet. Such a
for non-OAM packets. The O bit MUST NOT be modified along the | packet is any NSH-encapsulated packet that exclusively includes
SFP. | SFC OAM data. SFC OAM data can be included in the Fixed-Length
| Context Header, optional Context Headers, and/or the inner
NSH-encapsulated packets that include user data are not | packet.
considered as NSH OAM packets even if some SFC OAM data (e.g., |
record route) is also supplied in the packet. | The O bit is typically set by an OAM controller or a final
| destination of an NSH OAM packet that triggers a response
When SFC OAM data is included in the inner packet, the Next | (e.g., a specific SFC-aware SF or the last SFF of an SFP).
Protocol field is set to reflect the structure of that inner |
OAM packet. The setting and processing of the O bit neither | The O bit MUST be set for NSH OAM packets and MUST NOT be set
assumes nor expects detailed analysis of the content of any | for non-OAM packets. The O bit MUST NOT be modified along the
inner IP packet carried by the NSH. In order to prevent non | SFP.
deterministic behaviors, SFC data plane elements MAY support a |
configuration parameter to filter valid Next Protocol values in | NSH-encapsulated packets that include user data are not
NSH OAM packets. Absent explicit configuration, SFFs, SFC- | considered NSH OAM packets even if some SFC OAM data (e.g.,
aware SFs, and SFC Proxies SHOULD discard any NSH packets with | record route) is also supplied in the packet.
the O bit set and Next Protocol set to something that is not |
itself an OAM protocol. This includes discarding the packet | When SFC OAM data is included in the inner packet, the Next
when the O bit is set and the Next Protocol is set to 0x01 | Protocol field is set to reflect the structure of that inner
(IPv4), 0x02 (IPv6), 0x03 (MPLS), or 0x05 (Ethernet). | OAM packet. The setting and processing of the O bit neither
| assumes nor expects detailed analysis of the content of any
An NSH OAM packet MAY include optional Context Headers (e.g., a | inner IP packet carried by the NSH. In order to prevent non-
subscriber identifier [RFC8979] or a flow identifier [RFC9263]) | deterministic behaviors, SFC data plane elements MAY support a
that are used to influence the processing of the packet by SFC | configuration parameter to filter valid Next Protocol values in
data plane elements. | NSH OAM packets. Absent explicit configuration, SFFs, SFC-
| aware SFs, and SFC Proxies SHOULD discard any NSH packets with
An NSH OAM packet MAY include SFC OAM data in both Context | the O bit set and Next Protocol set to something that is not
Headers and the inner packet. The processing (including the | itself an OAM protocol. This includes discarding the packet
order) of the SFC OAM data SHOULD be specified in the relevant | when the O bit is set and the Next Protocol is set to 0x01
OAM or Context Header specification. | (IPv4), 0x02 (IPv6), 0x03 (MPLS), or 0x05 (Ethernet).
|
SFC-aware SF/SFF/SFC Proxy/Classifier implementations that do | An NSH OAM packet MAY include optional Context Headers (e.g., a
not support SFC OAM procedures SHOULD discard packets with the | subscriber identifier [RFC8979] or a flow identifier [RFC9263])
O bit set, but MAY support a configurable parameter to enable | that are used to influence the processing of the packet by SFC
forwarding received NSH OAM packets unmodified to the next | data plane elements.
element in the chain. Forwarding NSH OAM packets unmodified by |
SFC data plane elements that do not support SFC OAM procedures | An NSH OAM packet MAY include SFC OAM data in both Context
may be acceptable for a subset of OAM functions, but it can | Headers and the inner packet. The processing of the SFC OAM
result in unexpected outcomes for others; thus, it is | data (including the order) SHOULD be specified in the relevant
recommended to analyze the impact of forwarding an NSH OAM | OAM or Context Header specification.
packet for all OAM functions prior to enabling this behavior. |
The configurable parameter MUST be disabled by default. | SFC-aware implementations of SF, SFF, SFC Proxy, and Classifier
| that do not support SFC OAM procedures SHOULD discard packets
The actual format and additional processing of NSH OAM packets | with the O bit set but MAY support a configurable parameter to
is outside the scope of this specification. | enable forwarding received NSH OAM packets unmodified to the
| next element in the chain. Forwarding NSH OAM packets
| unmodified by SFC data plane elements that do not support SFC
| OAM procedures may be acceptable for a subset of OAM functions,
| but it can result in unexpected outcomes for others. Thus, it
| is recommended to analyze the impact of forwarding an NSH OAM
| packet for all OAM functions prior to enabling this behavior.
| The configurable parameter MUST be disabled by default.
|
| The actual format and additional processing of NSH OAM packets
| is outside the scope of this specification.
4. IANA Considerations 4. IANA Considerations
This document does not make any request to IANA. This document has no IANA actions.
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 NSH OAM packet SHOULD be integrity-protected Any data included in an NSH OAM packet SHOULD be integrity protected
[RFC9145]. [RFC9145].
6. Acknowledgments 6. References
Thanks to Jim Guichard, Greg Mirsky, Joel Halpern, Christian
Jacquenet, Dirk von-Hugo, Carlos Pignataro, and Frank Brockners for
the comments.
Thanks to Barry Leiba for the art directorate review and Russ Housley
for the security directorate review.
Thanks to Alvaro Retana and Robert Wilton for the IESG review.
7. References
7.1. Normative References 6.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 5, line 50 skipping to change at line 223
"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>.
[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 6.2. Informative References
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
D., and S. Mansfield, "Guidelines for the Use of the "OAM" D., and S. Mansfield, "Guidelines for the Use of the "OAM"
Acronym in the IETF", BCP 161, RFC 6291, Acronym in the IETF", BCP 161, RFC 6291,
DOI 10.17487/RFC6291, June 2011, DOI 10.17487/RFC6291, June 2011,
<https://www.rfc-editor.org/info/rfc6291>. <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,
skipping to change at page 6, line 40 skipping to change at line 260
Network Service Header (NSH)", RFC 8979, Network Service Header (NSH)", RFC 8979,
DOI 10.17487/RFC8979, February 2021, DOI 10.17487/RFC8979, February 2021,
<https://www.rfc-editor.org/info/rfc8979>. <https://www.rfc-editor.org/info/rfc8979>.
[RFC9263] Wei, Y., Ed., Elzur, U., Majee, S., Pignataro, C., and D. [RFC9263] Wei, Y., Ed., Elzur, U., Majee, S., Pignataro, C., and D.
Eastlake 3rd, "Network Service Header (NSH) Metadata Type Eastlake 3rd, "Network Service Header (NSH) Metadata Type
2 Variable-Length Context Headers", RFC 9263, 2 Variable-Length Context Headers", RFC 9263,
DOI 10.17487/RFC9263, August 2022, DOI 10.17487/RFC9263, August 2022,
<https://www.rfc-editor.org/info/rfc9263>. <https://www.rfc-editor.org/info/rfc9263>.
Acknowledgments
Thanks to Jim Guichard, Greg Mirsky, Joel Halpern, Christian
Jacquenet, Dirk von-Hugo, Carlos Pignataro, and Frank Brockners for
the comments.
Thanks to Barry Leiba for the art directorate review and Russ Housley
for the security directorate review.
Thanks to Alvaro Retana and Robert Wilton for their IESG reviews.
Author's Address Author's Address
Mohamed Boucadair Mohamed Boucadair
Orange Orange
35000 Rennes 35000 Rennes
France France
Email: mohamed.boucadair@orange.com Email: mohamed.boucadair@orange.com
 End of changes. 22 change blocks. 
134 lines changed or deleted 134 lines changed or added

This html diff was produced by rfcdiff 1.48.