Internet DRAFT - draft-mirsky-rtgwg-oam-identify
draft-mirsky-rtgwg-oam-identify
RTGWG Working Group G. Mirsky
Internet-Draft ZTE Corp.
Intended status: Informational February 26, 2020
Expires: August 29, 2020
Identification of Overlay Operations, Administration, and Maintenance
(OAM)
draft-mirsky-rtgwg-oam-identify-04
Abstract
This document analyzes how the presence of Operations,
Administration, and Maintenance (OAM) control command and/or special
data is identified in some overlay networks and an impact on the
choice of identification may have on OAM functionality.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 29, 2020.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Mirsky Expires August 29, 2020 [Page 1]
Internet-Draft Overlay OAM Identification February 2020
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 2
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
2.2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 3
3. A Control Channel in an Overlay Network . . . . . . . . . . . 3
4. Overlay Network Encapsulations . . . . . . . . . . . . . . . 4
4.1. Encapsulations with Meta-data . . . . . . . . . . . . . . 4
4.1.1. Available Solutions . . . . . . . . . . . . . . . . . 6
4.2. Fixed-size Encapsulations . . . . . . . . . . . . . . . . 6
4.3. Source Information Availability . . . . . . . . . . . . . 7
4.4. On-path OAM . . . . . . . . . . . . . . . . . . . . . . . 7
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informational References . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
Operations, Administration, and Maintenance (OAM) protocols are used
to detect, localize defects in the network, and monitor network
performance. Some OAM functions, e.g., failure detection, work in
the network proactively, while others, e.g., defect localization,
usually performed on-demand. These tasks achieved by a combination
of active, passive, and hybrid OAM methods, as defined in [RFC7799].
This document analyzes how the presence of Operations,
Administration, and Maintenance (OAM) control command and/or special
data, i.e., OAM packet, is identified in some overlay networks, and
an impact the choice of identification may have on OAM functionality
of active and hybrid OAM methods for the respective overlay network
encapsulation.
2. Conventions used in this document
2.1. Terminology
AMM Alternate Marking method
BIER Bit Indexed Explicit Replication
DetNet Deterministic Networks
Mirsky Expires August 29, 2020 [Page 2]
Internet-Draft Overlay OAM Identification February 2020
GUE Generic UDP Encapsulation
HTS Hybrid Two-step
NSH Network Service Header
NVO3 Network Virtualization Overlays
OAM Operations, Administration and Maintenance
SFC Service Function Chaining
TLV Type-Length-Value
VXLAN-GPE Generic Protocol Extension for VXLAN
ACH Associated Channed Header
Underlay Network or Underlay Layer: The network that provides
connectivity between the DetNet nodes. MPLS network that provides
LSP connectivity between DetNet nodes is an example of an underlay
layer.
2.2. Keywords
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. A Control Channel in an Overlay Network
There's a need for a general control channel between the endpoints of
an overlay network for OAM protocols that can be used for fault
detection, diagnostics, maintenance, and other functions. Such a
control tunnel is dedicated to carrying only control and management
data between tunnel endpoints. In other words, the control channel
of an overlay network SHOULD NOT carry the client's data. And the
endpoint node SHOULD NOT forward a packet received over the control
channel. The identification of the control channel might be using
different methods. For example, Virtual Network Identifier might be
used to identify the control channel in VXLAN and Geneve.
Mirsky Expires August 29, 2020 [Page 3]
Internet-Draft Overlay OAM Identification February 2020
4. Overlay Network Encapsulations
New overlay network encapsulations analyzed in two groups:
o encapsulations that support optional meta-data;
o fixed-size encapsulations.
4.1. Encapsulations with Meta-data
Number of the new encapsulation protocols (e.g., Geneve
[I-D.ietf-nvo3-geneve], GUE [I-D.ietf-intarea-gue], and SFC NSH
[RFC8300]) support use of Type-Length-Value (TLV) encoding to include
optional information into the header. The identification of OAM in
these protocols is as the following:
Geneve:
O (1 bit): after the WGLC discussion, the interpretation of the
O field has changed. The O field now identifies a control
packet. This packet contains a control message. Control
messages are sent between tunnel endpoints. Tunnel Endpoints
MUST NOT forward the payload and transit devices MUST NOT
attempt to interpret it. Since these are infrequent control
messages, it is RECOMMENDED that tunnel endpoints direct these
packets to a high priority control queue (for example, to
direct the packet to a general purpose CPU from a forwarding
ASIC or to separate out control traffic on a NIC). Transit
devices MUST NOT alter forwarding behavior on the basis of this
bit, such as ECMP link selection.
[I-D.mmbb-nvo3-geneve-oam] defines the Geneve encapsulation for
active OAM. Initially, four options have been presented:
+ with IP/UDP header demultiplexing active OAM protocols,
e.g., Fault Management and Performance Monitoring, can be
done using the destination UDP port number.
+ demultiplex active OAM protocols by the value of the
Protocol Type field in the Geneve header.
+ with using MPLS Generic Associated Channel Label [RFC5586]
and Associated Channel Header (ACH) [RFC4385]. Active OAM
protocols are demultiplexed using the value of the Channel
Type field.
Mirsky Expires August 29, 2020 [Page 4]
Internet-Draft Overlay OAM Identification February 2020
+ using the new EtherType to identify Geneve OAM and the ACH.
Active OAM protocols will be demultiplexed based on the
Channel Type field's value.
GUE:
C-bit provides the separate namespace to carry formatted data
that are implicitly addressed to the decapsulator to monitor or
control the state or behavior of a tunnel. The payload is
interpreted as a control message with the type specified in the
proto/ctype field. The format and contents of the control
message are indicated by the type and can be variable length.
SFC NSH:
O bit: Setting this bit indicates an OAM packet.
Common between Geneve and NSH is the use of the dedicated flag to
identify the OAM packet and, at the same time, the presence of the
field that identifies the protocol of the payload that immediately
follows after the encapsulation header. [RFC8393] points out that if
the value of that field interpreted as none, i.e., no payload follows
the header, then OAM may be included in TLVs, thus creating an active
OAM packet. The problem with this mechanism to support active OAM
methods may be a limitation of the size of data that can be included
in a TLV. For example, the maximum size of data in an NSH Meta-data
Type 2, as defined in section 2.5.1 [RFC8300], is 512 octets. The
maximum length of data in Geneve Option, per section 3.5
[I-D.ietf-nvo3-geneve], is 128 octets. Thus, using one TLV as active
OAM packet, would not allow creating test packets of larger size,
which is useful when measuring packet loss and latency with synthetic
traffic as part of the service activation procedure.
[I-D.ietf-sfc-oam-framework] suggests that the O bit used to identify
OAM packet and the Next Protocol field identifies the OAM function:
While the presence of OAM marker in the overlay header (e.g., O
bit in the NSH header) indicates it as OAM packet, it is not
sufficient to signal for which OAM function the packet is
intended.
At the same time, some of in-situ OAM proposals, e.g.,
[I-D.ietf-sfc-ioam-nsh], suggest using TLV to communicate hybrid OAM
commands and data. The proposed resolution of using the combination
of O bit and the Next Protocol field:
Mirsky Expires August 29, 2020 [Page 5]
Internet-Draft Overlay OAM Identification February 2020
... the O bit MUST NOT be set for regular customer traffic which
also carries IOAM data and the O bit MUST be set for OAM packets
which carry only IOAM data without any regular data payload.
implies that the O bit only identifies the active OAM packet and not
set when hybrid OAM methods used.
4.1.1. Available Solutions
One of the possible solutions for encapsulations with meta-data has
been specified in [I-D.ietf-sfc-multi-layer-oam]:
To identify the active OAM message the value on the Next Protocol
field MUST be set to Active SFC OAM. The rules of interpreting the
values of O bit and the Next Protocol field are as follows:
o O bit set and the Next Protocol value is not one of identifying
active or hybrid OAM protocol (per [RFC7799] definitions), e.g.,
defined in this specification Active SFC OAM - a Fixed-Length
Context Header or Variable-Length Context Header(s) contain OAM
command or data and the type of payload determined by the Next
Protocol field;
o O bit set and the Next Protocol value is one of identifying active
or hybrid OAM protocol - the payload that immediately follows SFC
NSH contains OAM command or data;
o O bit is clear - no OAM in a Fixed-Length Context Header or
Variable-Length Context Header(s) and the payload determined by
the value of the Next Protocol field;
o O bit is clear, and the Next Protocol value is one of identifying
active or hybrid OAM protocol MUST be identified and reported as
the erroneous combination. An implementation MAY have control to
enable processing of the OAM payload.
From the above-listed rules follows the recommendation to avoid the
combination of OAM in a Fixed-Length Context Header or Variable-
Length Context Header(s) and in the payload immediately following the
SFC NSH because there is no unambiguous way to identify such
combination using the O bit and the Next Protocol field.
4.2. Fixed-size Encapsulations
Number of the new encapsulation protocols (e.g., VXLAN-GPE
[I-D.ietf-nvo3-vxlan-gpe], BIER [RFC8296]) suse fixed-size header.
The identification of OAM in these protocols is as the following:
Mirsky Expires August 29, 2020 [Page 6]
Internet-Draft Overlay OAM Identification February 2020
VXLAN-GPE:
OAM Flag Bit (O bit): The O bit is set to indicate that the
packet is an OAM packet.
BIER:
OAM packet identified by the value of the Next Protocol field.
IANA BIER Next Protocol Identifiers registry includes the
identifier for OAM (5).
The use of a combination of OAM Flag Bit and the Next Protocol field
in VXLAN-GPE requires clarification of the header interpretation when
the OAM Flag Bit is set, and the value of the Next Protocol field is
one of defined in section 3.2 of [I-D.ietf-nvo3-vxlan-gpe].
BIER encapsulation, defined in [RFC8296], identifies OAM message
immediately following the BIER header by the value of the Next
Protocol field.
4.3. Source Information Availability
Availability of the packet originator's source information is
required for active two-way OAM, e.g., echo request/reply. In cases
when the underlay network is IPv4/IPv6 the source information will be
derived from the underlay. But when using MPLS underlay network
encapsulation of an active OAM packet have to follow specific rules:
o if available, use Sender ID in the overlay domain (example BFIR ID
in BIER [RFC8296];
o use IP/UDP encapsulation of an OAM packet in the overlay (similar
to Section 4.3 [RFC8029]).
4.4. On-path OAM
In addition to active methods, OAM toolset may include methods that
don't use specially constructed and injected in the network test
packets. [RFC7799] defines OAM methods that are neither entirely
active nor passive but are a combination of both as hybrid methods.
One of the examples of the hybrid OAM methods, in-situ OAM, mentioned
in Section 4.1. Another example, Alternate Marking method (AMM)
[RFC8321], enables on-path OAM functions, e.g., delay and loss
measurements, using the data traffic. Because AMM impact on the
network can be minimized, measured metrics can be correlated to the
network conditions experienced by the specific service. Of all
listed in Section 4, BIER allocated the field that may be used for
Mirsky Expires August 29, 2020 [Page 7]
Internet-Draft Overlay OAM Identification February 2020
AMM, as discussed in [I-D.ietf-bier-pmmm-oam]. Applicability of AMM
to other overlay protocols, i.e., SFC NSH discussed in
[I-D.mirsky-sfc-pmamm], Geneve [I-D.fmm-nvo3-pm-alt-mark], and in
IPv6 networks [I-D.fioccola-v6ops-ipv6-alt-mark], been actively
discussed.
Hybrid Two-step (HTS), defined in [I-D.mirsky-ippm-hybrid-two-step],
provides on-path collection and transport of the telemetry
information. HTS enables accurate and consistent measurements by
separating the measurement action from the transporting data while
ensuring that the follow-up packet that carries the telemetry
information does follow the data packet that had triggered the
measurement.
5. Conclusions
OAM control commands and data may be present as part of the overlay
encapsulation header or as a payload that follows the overlay network
header. The recommendations:
o OAM in the overlay header, if supported by the overlay network,
identified by the dedicated flag. Use of this method as active
OAM is possible, but functionality is limited.
o OAM that follows the overlay header identified as payload type,
e.g., by the value of the Next Protocol field.
6. IANA Considerations
This document does not propose any IANA consideration. This section
may be removed.
7. Security Considerations
This document lists the OAM requirements for a DetNet domain and does
not raise any security concerns or issues in addition to ones common
to networking.
8. Acknowledgment
TBD
9. References
Mirsky Expires August 29, 2020 [Page 8]
Internet-Draft Overlay OAM Identification February 2020
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informational References
[I-D.fioccola-v6ops-ipv6-alt-mark]
Fioccola, G., Velde, G., Cociglio, M., and P. Muley, "IPv6
Performance Measurement with Alternate Marking Method",
draft-fioccola-v6ops-ipv6-alt-mark-01 (work in progress),
June 2018.
[I-D.fmm-nvo3-pm-alt-mark]
Fioccola, G., Mirsky, G., and T. Mizrahi, "Performance
Measurement (PM) with Alternate Marking in Network
Virtualization Overlays (NVO3)", draft-fmm-nvo3-pm-alt-
mark-03 (work in progress), October 2018.
[I-D.ietf-bier-pmmm-oam]
Mirsky, G., Zheng, L., Chen, M., and G. Fioccola,
"Performance Measurement (PM) with Marking Method in Bit
Index Explicit Replication (BIER) Layer", draft-ietf-bier-
pmmm-oam-07 (work in progress), January 2020.
[I-D.ietf-intarea-gue]
Herbert, T., Yong, L., and O. Zia, "Generic UDP
Encapsulation", draft-ietf-intarea-gue-09 (work in
progress), October 2019.
[I-D.ietf-nvo3-geneve]
Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic
Network Virtualization Encapsulation", draft-ietf-
nvo3-geneve-14 (work in progress), September 2019.
[I-D.ietf-nvo3-vxlan-gpe]
Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-09 (work
in progress), December 2019.
Mirsky Expires August 29, 2020 [Page 9]
Internet-Draft Overlay OAM Identification February 2020
[I-D.ietf-sfc-ioam-nsh]
Brockners, F. and S. Bhandari, "Network Service Header
(NSH) Encapsulation for In-situ OAM (IOAM) Data", draft-
ietf-sfc-ioam-nsh-02 (work in progress), September 2019.
[I-D.ietf-sfc-multi-layer-oam]
Mirsky, G., Meng, W., Khasnabish, B., and C. Wang, "Active
OAM for Service Function Chains in Networks", draft-ietf-
sfc-multi-layer-oam-04 (work in progress), November 2019.
[I-D.ietf-sfc-oam-framework]
Aldrin, S., Pignataro, C., Kumar, N., Krishnan, R., and A.
Ghanwani, "Service Function Chaining (SFC) Operations,
Administration and Maintenance (OAM) Framework", draft-
ietf-sfc-oam-framework-11 (work in progress), September
2019.
[I-D.mirsky-ippm-hybrid-two-step]
Mirsky, G., Lingqiang, W., and G. Zhui, "Hybrid Two-Step
Performance Measurement Method", draft-mirsky-ippm-hybrid-
two-step-04 (work in progress), October 2019.
[I-D.mirsky-sfc-pmamm]
Mirsky, G., Fioccola, G., and T. Mizrahi, "Performance
Measurement (PM) with Alternate Marking Method in Service
Function Chaining (SFC) Domain", draft-mirsky-sfc-pmamm-09
(work in progress), December 2019.
[I-D.mmbb-nvo3-geneve-oam]
Mirsky, G., Xiao, M., Boutros, S., and D. Black, "OAM for
use in GENEVE", draft-mmbb-nvo3-geneve-oam-01 (work in
progress), January 2020.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
February 2006, <https://www.rfc-editor.org/info/rfc4385>.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", RFC 5586,
DOI 10.17487/RFC5586, June 2009,
<https://www.rfc-editor.org/info/rfc5586>.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <https://www.rfc-editor.org/info/rfc7799>.
Mirsky Expires August 29, 2020 [Page 10]
Internet-Draft Overlay OAM Identification February 2020
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures", RFC 8029,
DOI 10.17487/RFC8029, March 2017,
<https://www.rfc-editor.org/info/rfc8029>.
[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
for Bit Index Explicit Replication (BIER) in MPLS and Non-
MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
2018, <https://www.rfc-editor.org/info/rfc8296>.
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>.
[RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli,
L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
"Alternate-Marking Method for Passive and Hybrid
Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,
January 2018, <https://www.rfc-editor.org/info/rfc8321>.
[RFC8393] Farrel, A. and J. Drake, "Operating the Network Service
Header (NSH) with Next Protocol "None"", RFC 8393,
DOI 10.17487/RFC8393, May 2018,
<https://www.rfc-editor.org/info/rfc8393>.
Author's Address
Greg Mirsky
ZTE Corp.
Email: gregimirsky@gmail.com
Mirsky Expires August 29, 2020 [Page 11]
