< draft-ietf-sfc-multi-layer-oam-18.txt   draft-ietf-sfc-multi-layer-oam-19.txt >
SFC WG G. Mirsky SFC WG G. Mirsky
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 8300 (if approved) W. Meng Intended status: Standards Track W. Meng
Intended status: Standards Track ZTE Corporation Expires: 2 October 2022 ZTE Corporation
Expires: 23 June 2022 B. Khasnabish B. Khasnabish
Individual contributor Individual contributor
T. Ao T. Ao
China Mobile China Mobile
K. Leung K. Leung
Cisco System Cisco System
G. Mishra G. Mishra
Verizon Inc. Verizon Inc.
20 December 2021 31 March 2022
Active OAM for Service Function Chaining Active OAM for Service Function Chaining
draft-ietf-sfc-multi-layer-oam-18 draft-ietf-sfc-multi-layer-oam-19
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
definition of O (OAM) bit in the Network Service Header (NSH) (RFC
8300) and defines how an active OAM message is identified in the NSH.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 23 June 2022. This Internet-Draft will expire on 2 October 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 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
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . 5 3. Requirements for Active OAM in SFC . . . . . . . . . . . . . 5
4. Active OAM Identification in the NSH . . . . . . . . . . . . 7 4. Active OAM Identification in the NSH . . . . . . . . . . . . 7
5. Active SFC OAM Header . . . . . . . . . . . . . . . . . . . . 8 5. Active SFC OAM Header . . . . . . . . . . . . . . . . . . . . 7
6. Echo Request/Echo Reply for SFC . . . . . . . . . . . . . . . 9 6. Echo Request/Echo Reply for SFC . . . . . . . . . . . . . . . 8
6.1. Return Codes . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Return Codes . . . . . . . . . . . . . . . . . . . . . . 10
6.2. Authentication in Echo Request/Reply . . . . . . . . . . 12 6.2. Authentication in Echo Request/Reply . . . . . . . . . . 11
6.3. SFC Echo Request Transmission . . . . . . . . . . . . . . 12 6.3. SFC Echo Request Transmission . . . . . . . . . . . . . . 11
6.3.1. Source TLV . . . . . . . . . . . . . . . . . . . . . 13 6.3.1. Source TLV . . . . . . . . . . . . . . . . . . . . . 12
6.4. SFC Echo Request Reception . . . . . . . . . . . . . . . 14 6.4. SFC Echo Request Reception . . . . . . . . . . . . . . . 13
6.4.1. Errored TLVs TLV . . . . . . . . . . . . . . . . . . 15 6.4.1. Errored TLVs TLV . . . . . . . . . . . . . . . . . . 14
6.5. SFC Echo Reply Transmission . . . . . . . . . . . . . . . 16 6.5. SFC Echo Reply Transmission . . . . . . . . . . . . . . . 15
6.5.1. SFC Reply Path TLV . . . . . . . . . . . . . . . . . 16 6.5.1. SFC Reply Path TLV . . . . . . . . . . . . . . . . . 15
6.5.2. Theory of Operation . . . . . . . . . . . . . . . . . 18 6.5.2. Theory of Operation . . . . . . . . . . . . . . . . . 17
6.5.3. SFC Echo Reply Reception . . . . . . . . . . . . . . 19 6.5.3. SFC Echo Reply Reception . . . . . . . . . . . . . . 18
6.5.4. Tracing an SFP . . . . . . . . . . . . . . . . . . . 19 6.5.4. Tracing an SFP . . . . . . . . . . . . . . . . . . . 18
6.6. Verification of the SFP Consistency . . . . . . . . . . . 20 6.6. Verification of the SFP Consistency . . . . . . . . . . . 19
6.6.1. SFP Consistency Verification packet . . . . . . . . . 20 6.6.1. SFP Consistency Verification packet . . . . . . . . . 19
6.6.2. SFF Information Record TLV . . . . . . . . . . . . . 20 6.6.2. SFF Information Record TLV . . . . . . . . . . . . . 19
6.6.3. SF Information Sub-TLV . . . . . . . . . . . . . . . 21 6.6.3. SF Information Sub-TLV . . . . . . . . . . . . . . . 20
6.6.4. SF Information Sub-TLV Construction . . . . . . . . . 23 6.6.4. SF Information Sub-TLV Construction . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
8. Operational Considerations . . . . . . . . . . . . . . . . . 25 8. Operational Considerations . . . . . . . . . . . . . . . . . 24
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
10.1. SFC Active OAM Protocol . . . . . . . . . . . . . . . . 26 10.1. SFC Active OAM Protocol . . . . . . . . . . . . . . . . 25
10.2. SFC Active OAM . . . . . . . . . . . . . . . . . . . . . 26 10.2. SFC Active OAM . . . . . . . . . . . . . . . . . . . . . 25
10.2.1. SFC Active OAM Message Type . . . . . . . . . . . . 26 10.2.1. SFC Active OAM Message Type . . . . . . . . . . . . 25
10.2.2. SFC Active OAM Header Flags . . . . . . . . . . . . 27 10.2.2. SFC Active OAM Header Flags . . . . . . . . . . . . 26
10.3. SFC Echo Request/Echo Reply Parameters . . . . . . . . . 26
10.3.1. SFC Echo Request Flags . . . . . . . . . . . . . . . 27
10.3.2. SFC Echo Request/Echo Reply Message Types . . . . . 27
10.3.3. SFC Echo Reply Modes . . . . . . . . . . . . . . . . 28
10.3.4. SFC Echo Return Codes . . . . . . . . . . . . . . . 29
10.3. SFC Echo Request/Echo Reply Parameters . . . . . . . . . 27 10.4. SFC Active OAM TLV Type . . . . . . . . . . . . . . . . 30
10.3.1. SFC Echo Request Flags . . . . . . . . . . . . . . . 28 10.5. SF Identifier Types . . . . . . . . . . . . . . . . . . 31
10.3.2. SFC Echo Request/Echo Reply Message Types . . . . . 28 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.3.3. SFC Echo Reply Modes . . . . . . . . . . . . . . . . 29 11.1. Normative References . . . . . . . . . . . . . . . . . . 32
10.3.4. SFC Echo Return Codes . . . . . . . . . . . . . . . 30 11.2. Informative References . . . . . . . . . . . . . . . . . 33
10.4. SFC Active OAM TLV Type . . . . . . . . . . . . . . . . 31 Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 34
10.5. SF Identifier Types . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.1. Normative References . . . . . . . . . . . . . . . . . . 33
11.2. Informative References . . . . . . . . . . . . . . . . . 34
Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
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 24 skipping to change at page 4, line 16
because they specifically address the architectural principles of because they specifically address the architectural principles of
NSH. For that purpose, SFC Echo Request and Echo Reply are specified NSH. For that purpose, SFC Echo Request and Echo Reply are specified
in Section 6. This mechanism enables on-demand Continuity Check, in Section 6. This mechanism enables on-demand Continuity Check,
Connectivity Verification, among other operations over SFC in Connectivity Verification, among other operations over SFC in
networks, addresses functionalities discussed in Sections 4.1, 4.2, networks, addresses functionalities discussed in Sections 4.1, 4.2,
and 4.3 of [RFC8924]. SFC Echo Request and Echo Reply, defined in and 4.3 of [RFC8924]. SFC Echo Request and Echo Reply, defined in
this document, can be used with encapsulations other than NSH, for this document, can be used with encapsulations other than NSH, for
example, using MPLS encapsulation, as described in [RFC8595]. The example, using MPLS encapsulation, as described in [RFC8595]. The
applicability of the SFC Echo Request/Reply mechanism in SFC applicability of the SFC Echo Request/Reply mechanism in SFC
encapsulations other than NSH is outside the scope of this document. encapsulations other than NSH is outside the scope of this document.
Also, this document updates Section 2.2 of [RFC8300] in part of the
definition of O bit in the NSH.
2. Terminology and Conventions 2. Terminology and Conventions
The terminology defined in [RFC7665] is used extensively throughout The terminology defined in [RFC7665] is used extensively throughout
this document, and the reader is expected to be familiar with it. this document, and the reader is expected to be familiar with it.
In this document, SFC OAM refers to an active OAM [RFC7799] in an SFC In this document, SFC OAM refers to an active OAM [RFC7799] in an SFC
architecture. In this document, "Echo Request/Reply" and "SFC Echo architecture. In this document, "Echo Request/Reply" and "SFC Echo
Request/Reply" are used interchangeably. Request/Reply" are used interchangeably.
skipping to change at page 7, line 10 skipping to change at page 7, line 7
could be verified. After the reachability of SFFs has already been could be verified. After the reachability of SFFs has already been
verified, SFFs that serve an SF may be used as a test packet source. verified, SFFs that serve an SF may be used as a test packet source.
In such a case, SFF can act as a proxy for another element within the In such a case, SFF can act as a proxy for another element within the
service function chain. service function chain.
REQ#8: SFC OAM MUST be able to trigger on-demand FM with responses REQ#8: SFC OAM MUST be able to trigger on-demand FM with responses
being directed towards the initiator of such proxy request. being directed towards the initiator of such proxy request.
4. Active OAM Identification in the NSH 4. Active OAM Identification in the NSH
The O bit in the NSH is defined in [RFC8300] as follows: Active SFC OAM combines OAM commands and/or data included in a
message that immediately follows the NSH. To identify the active SFC
O bit: Setting this bit indicates an OAM packet. OAM message, the "Next Protocol" field MUST be set to Active SFC OAM
(TBA1) (Section 10.1). The O bit in NSH MUST be set, according to
This document updates that definition as follows: [I-D.ietf-sfc-oam-packet]. A case when the O bit is clear and the
"Next Protocol" field value is set to Active SFC OAM (TBA1) is
O bit: Setting this bit indicates an OAM command and/or data in considered an erroneous combination. An implementation MUST report
the NSH Context Header or packet payload. it. The notification mechanism is outside the scope of this
specification. The packet SHOULD be dropped. An implementation MAY
Active SFC OAM is defined as a combination of OAM commands and/or have control to enable the processing of the OAM payload.
data included in a message that immediately follows the NSH. To
identify the active OAM message, the "Next Protocol" field MUST be
set to Active SFC OAM (TBA1) (Section 10.1). The rules for
interpreting the values of the O bit and the "Next Protocol" field
are as follows:
* O bit set and the "Next Protocol" value does not match the value
Active SFC OAM (TBA1), defined in Section 10.1:
- An SFC NSH Context Header(s) contain an OAM processing
instructions or data.
- The "Next Protocol" field determines the type of the payload.
* O bit set and the "Next Protocol" value matches Active SFC OAM
(TBA1) value:
- The payload that immediately follows the NSH MUST be the
Active OAM Header (Section 5).
* O bit is clear:
- No active OAM in an SFC NSH Context Header(s).
- The payload determined by the "Next Protocol" field MUST be
present.
* O bit is clear, and the "Next Protocol" field is set to Active SFC
OAM (TBA1):
- Erroneous combination. An implementation MUST report it.
The notification mechanism is outside the scope of this
specification. The packet SHOULD be dropped. An
implementation MAY have control to enable processing of the OAM
payload.
One conclusion from the above-listed rules of processing the O bit
and the "Next Protocol" field is to avoid the combination of OAM in
an NSH Context Header (Fixed-Length or Variable-Length) and the
payload immediately following the NSH because there is no unambiguous
way to identify such combination using the O bit and the Next
Protocol field.
5. Active SFC OAM Header 5. Active SFC OAM Header
As demonstrated in Section 4 [RFC8924] and Section 3 of this As demonstrated in Section 4 [RFC8924] and Section 3 of this
document, SFC OAM is required to perform multiple tasks. Several document, SFC OAM is required to perform multiple tasks. Several
active OAM protocols could be used to address all the requirements. active OAM protocols could be used to address all the requirements.
When IP/UDP encapsulation of an SFC OAM control message is used, When IP/UDP encapsulation of an SFC OAM control message is used,
protocols can be demultiplexed using the destination UDP port number. protocols can be demultiplexed using the destination UDP port number.
But extra IP/UDP headers, especially in an IPv6 network, add But extra IP/UDP headers, especially in an IPv6 network, add
noticeable overhead. This document defines Active OAM Header noticeable overhead. This document defines Active OAM Header
skipping to change at page 12, line 22 skipping to change at page 11, line 22
Authentication Code) Context Header is more suitable for the Authentication Code) Context Header is more suitable for the
integrity protection of active SFC OAM, particularly of the defined integrity protection of active SFC OAM, particularly of the defined
in this document SFC Echo Request and Echo Reply. On the other hand, in this document SFC Echo Request and Echo Reply. On the other hand,
using MAC#2 Context Header allows the detection of mishandling of the using MAC#2 Context Header allows the detection of mishandling of the
O-bit by a transient SFC element. O-bit by a transient SFC element.
6.3. SFC Echo Request Transmission 6.3. SFC Echo Request Transmission
SFC Echo Request control packet MUST use the appropriate underlay SFC Echo Request control packet MUST use the appropriate underlay
network encapsulation of the monitored SFP. If the NSH is used, Echo network encapsulation of the monitored SFP. If the NSH is used, Echo
Request MUST set O bit, as defined in [RFC8300]. NSH MUST be Request MUST set O bit, as defined in [I-D.ietf-sfc-oam-packet]. NSH
immediately followed by the SFC Active OAM Header defined in MUST be immediately followed by the SFC Active OAM Header defined in
Section 4. The Message Type field's value in the SFC Active OAM Section 4. The Message Type field's value in the SFC Active OAM
Header MUST be set to SFC Echo Request/Echo Reply value (1) per Header MUST be set to SFC Echo Request/Echo Reply value (1) per
Section 10.2.1. Section 10.2.1.
Value of the Reply Mode field MAY be set to: Value of the Reply Mode field MAY be set to:
* Do Not Reply (1) if one-way monitoring is desired. If the Echo * Do Not Reply (1) 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. Note that ways report loss measurement results to a remote node. Note that ways
of learning the identity of that node are outside the scope of of learning the identity of that node are outside the scope of
skipping to change at page 33, line 39 skipping to change at page 32, line 39
+---------+-------------+---------------+ +---------+-------------+---------------+
| 255 | Reserved | This document | | 255 | Reserved | This document |
+---------+-------------+---------------+ +---------+-------------+---------------+
Table 10: SF Identifier Type Table 10: SF Identifier Type
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-sfc-oam-packet]
Boucadair, M., "OAM Packet and Behavior in the Network
Service Header (NSH)", Work in Progress, Internet-Draft,
draft-ietf-sfc-oam-packet-00, 25 March 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-sfc-oam-
packet-00>.
[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>.
[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>.
11.2. Informative References 11.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 Metadata Type 2
Variable-Length Context Headers", Work in Progress, Variable-Length Context Headers", Work in Progress,
Internet-Draft, draft-ietf-sfc-nsh-tlv-10, 3 December Internet-Draft, draft-ietf-sfc-nsh-tlv-14, 30 March 2022,
2021, <https://datatracker.ietf.org/doc/html/draft-ietf- <https://datatracker.ietf.org/doc/html/draft-ietf-sfc-nsh-
sfc-nsh-tlv-10>. tlv-14>.
[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)",
 End of changes. 13 change blocks. 
109 lines changed or deleted 67 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/