Skip to main content

Identification of Overlay Operations, Administration, and Maintenance (OAM)
draft-mirsky-rtgwg-oam-identify-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Greg Mirsky
Last updated 2018-06-28
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-mirsky-rtgwg-oam-identify-00
RTGWG Working Group                                            G. Mirsky
Internet-Draft                                                 ZTE Corp.
Intended status: Informational                             June 28, 2018
Expires: December 30, 2018

 Identification of Overlay Operations, Administration, and Maintenance
                                 (OAM)
                   draft-mirsky-rtgwg-oam-identify-00

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 December 30, 2018.

Copyright Notice

   Copyright (c) 2018 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 December 30, 2018               [Page 1]
Internet-Draft         Overlay OAM Identification              June 2018

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions used in this document . . . . . . . . . . . . . .   2
     2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   2
     2.2.  Keywords  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Overlay Network Encapsulations  . . . . . . . . . . . . . . .   3
     3.1.  Encapsulations with Meta-data . . . . . . . . . . . . . .   3
     3.2.  Fixed-size Encapsulations . . . . . . . . . . . . . . . .   5
     3.3.  Source Information Availability . . . . . . . . . . . . .   5
     3.4.  On-path OAM . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  Acknowledgment  . . . . . . . . . . . . . . . . . . . . . . .   7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     8.2.  Informational References  . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

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

   GUE Generic UDP Encapsulation

Mirsky                  Expires December 30, 2018               [Page 2]
Internet-Draft         Overlay OAM Identification              June 2018

   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

   Underlay Network or Underlay Layer: The network that provides
   connectivity between the DetNet nodes.  MPLS network providing LSP
   connectivity between DetNet nodes is an example of 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.  Overlay Network Encapsulations

   New overlay network encapsulations analyzed in two groups:

   o  encapsulations that support optional meta-data;

   o  fixed-size encapsulations.

3.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): OAM packet.  This packet contains a control message
         instead of a data payload.  Endpoints MUST NOT forward the
         payload and transit devices MUST NOT attempt to interpret or
         process it.  Since these are infrequent control messages, it is

Mirsky                  Expires December 30, 2018               [Page 3]
Internet-Draft         Overlay OAM Identification              June 2018

         RECOMMENDED that 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.

      GUE:

         Undefined.

      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 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 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 indicate what OAM function the packet is intended
      for.

   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:

      ... 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.

Mirsky                  Expires December 30, 2018               [Page 4]
Internet-Draft         Overlay OAM Identification              June 2018

   implies that the O bit only identifies the active OAM packet and not
   set when hybrid OAM methods used.

3.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:

      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).

   VXLAN-GPE use of a combination of OAM Flag Bit and the Next Protocol
   field 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.

3.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
   provided by the encapsulation of the underlay.  But when using MPLS
   underlay network encapsulation of an active OAM packet have to follow
   certain 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 overlay (similar to
      Section 4.3 [RFC8029]).

Mirsky                  Expires December 30, 2018               [Page 5]
Internet-Draft         Overlay OAM Identification              June 2018

3.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 combine both as hybrid methods.

   One of the examples of the hybrid OAM method, in-situ OAM, mentioned
   in Section 3.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 3, BIER allocated the field that may be used for
   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] and Geneve [I-D.fmm-nvo3-pm-alt-mark], been
   actively discussed.

   Hybrid Two-step (HTS), defined in [I-D.mirsky-ippm-hybrid-two-step],
   is provides on-path collection and transport of the telemetry
   information.  HTS enables accurate and consistent measurements by
   separating the measurement action from the transport while ensuring
   that the follow-up packet that carries the telemetry information does
   follow the data packet that had triggered the measurement.

4.  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.

5.  IANA Considerations

   This document does not propose any IANA consideration.  This section
   may be removed.

Mirsky                  Expires December 30, 2018               [Page 6]
Internet-Draft         Overlay OAM Identification              June 2018

6.  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.

7.  Acknowledgment

   TBD

8.  References

8.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>.

8.2.  Informational References

   [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-02 (work in progress), June 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-04 (work in progress), June 2018.

   [I-D.ietf-intarea-gue]
              Herbert, T., Yong, L., and O. Zia, "Generic UDP
              Encapsulation", draft-ietf-intarea-gue-05 (work in
              progress), December 2017.

   [I-D.ietf-nvo3-geneve]
              Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic
              Network Virtualization Encapsulation", draft-ietf-
              nvo3-geneve-06 (work in progress), March 2018.

Mirsky                  Expires December 30, 2018               [Page 7]
Internet-Draft         Overlay OAM Identification              June 2018

   [I-D.ietf-nvo3-vxlan-gpe]
              Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
              Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-06 (work
              in progress), April 2018.

   [I-D.ietf-sfc-ioam-nsh]
              Brockners, F., Bhandari, S., Govindan, V., Pignataro, C.,
              Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes,
              D., Lapukhov, P., and R. Chang, "NSH Encapsulation for In-
              situ OAM Data", draft-ietf-sfc-ioam-nsh-00 (work in
              progress), May 2018.

   [I-D.ietf-sfc-oam-framework]
              Aldrin, S., Pignataro, C., Kumar, N., Akiya, N., Krishnan,
              R., and A. Ghanwani, "Service Function Chaining (SFC)
              Operation, Administration and Maintenance (OAM)
              Framework", draft-ietf-sfc-oam-framework-04 (work in
              progress), March 2018.

   [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-00 (work in progress), February 2018.

   [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-03
              (work in progress), June 2018.

   [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>.

   [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>.

Mirsky                  Expires December 30, 2018               [Page 8]
Internet-Draft         Overlay OAM Identification              June 2018

   [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 December 30, 2018               [Page 9]