Skip to main content

In Situ OAM Profiles
draft-mizrahi-ippm-ioam-profile-01

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".
Authors Tal Mizrahi , Frank Brockners , Shwetha Bhandari , Ramesh Sivakolundu , Carlos Pignataro , Aviv Kfir , Barak Gafni , Mickey Spiegel , Tianran Zhou , John Lemon
Last updated 2019-09-11 (Latest revision 2019-03-11)
RFC stream (None)
Formats
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-mizrahi-ippm-ioam-profile-01
Network Working Group                                         T. Mizrahi
Internet-Draft                          Huawei Network.IO Innovation Lab
Intended status: Informational                              F. Brockners
Expires: March 14, 2020                                      S. Bhandari
                                                          R. Sivakolundu
                                                            C. Pignataro
                                                                   Cisco
                                                                 A. Kfir
                                                                B. Gafni
                                             Mellanox Technologies, Inc.
                                                              M. Spiegel
                                                       Barefoot Networks
                                                                 T. Zhou
                                                                  Huawei
                                                                J. Lemon
                                                                Broadcom
                                                      September 11, 2019

                          In Situ OAM Profiles
                   draft-mizrahi-ippm-ioam-profile-01

Abstract

   In Situ Operations, Administration and Maintenance (IOAM) is used for
   monitoring network performance and for detecting traffic bottlenecks
   and anomalies.  This is achieved by incorporating IOAM data into in-
   flight data packets.  This document introduces the concept of use
   case-driven IOAM profiles.  An IOAM profile defines a use case or a
   set of use cases for IOAM, and an associated set of rules that
   restrict the scope and features of the IOAM specification, thereby
   limiting it to a subset of the full functionality.  The motivation
   for defining profiles is to limit the scope of IOAM features,
   allowing simpler implementation, verification, and interoperability
   testing in the context of specific use cases that do not require the
   full functionality of IOAM.

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

Mizrahi, et al.          Expires March 14, 2020                 [Page 1]
Internet-Draft                IOAM Profiles               September 2019

   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 March 14, 2020.

Copyright Notice

   Copyright (c) 2019 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Specifying an IOAM Profile  . . . . . . . . . . . . . . . . .   3
     2.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.3.  IOAM Options  . . . . . . . . . . . . . . . . . . . . . .   4
     2.4.  IOAM Option Header Field Values . . . . . . . . . . . . .   4
     2.5.  Opaque State Snapshot . . . . . . . . . . . . . . . . . .   4
     2.6.  Timestamp Format  . . . . . . . . . . . . . . . . . . . .   4
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   5.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Appendix A.  An IOAM Profile Example  . . . . . . . . . . . . . .   5
     A.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   5
     A.2.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . .   6
     A.3.  IOAM Options  . . . . . . . . . . . . . . . . . . . . . .   6
     A.4.  IOAM Option Header Field Values . . . . . . . . . . . . .   6
     A.5.  Opaque State Snapshot . . . . . . . . . . . . . . . . . .   6
     A.6.  Profile Coexistence . . . . . . . . . . . . . . . . . . .   6
     A.7.  Validity  . . . . . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

Mizrahi, et al.          Expires March 14, 2020                 [Page 2]
Internet-Draft                IOAM Profiles               September 2019

1.  Introduction

   IOAM [I-D.ietf-ippm-ioam-data] is used for monitoring traffic in the
   network by incorporating IOAM data fields into in-flight data
   packets.

   This document introduces the concept of use case driven IOAM
   profiles.  The motivation for defining profiles is to limit the scope
   of IOAM features, allowing simpler implementation, verification, and
   interoperability testing in the context of specific use cases that do
   not require the full functionality of IOAM.

   An IOAM profile defines a use case or a set of use cases for IOAM,
   and an associated set of rules that restrict the scope and features
   of the IOAM specification, thereby limiting it to a subset of the
   full functionality.  Based on the guidelines in this document, future
   documents may define one or more IOAM profiles.  The current document
   does not specify any IOAM profiles.

   This document does not require any changes to the Data Fields for In-
   situ OAM [I-D.ietf-ippm-ioam-data].  Furthermore, it is expected that
   future IOAM profile specifications will not require changes to IOAM,
   since a profile, by definition, derives a subset of the existing
   functionality.

2.  Specifying an IOAM Profile

2.1.  Overview

   A profile defines a set of rules that limit the scope or
   functionality of IOAM.  By default, any detail in IOAM that is not
   specifically addressed or limited by the profile is as defined in
   IOAM [I-D.ietf-ippm-ioam-data].  The rest of this section presents a
   set of topics that may be addressed in a profile specification.  A
   profile may include some or all of these topics, and optionally other
   topics.

   A profile may in part be defined using a specific assignment to the
   IOAM YANG model [I-D.zhou-ippm-ioam-yang].  It should be noted that
   while the YANG model assists in the definition of a profile, it does
   not replace the profile definition.  Specifically, a profile
   definition includes the use case(s) for using the profile, and
   possibly some properties that cannot be defined by an assignment to
   the YANG model, such as the semantics of the Opaque State Snapshot
   field.

Mizrahi, et al.          Expires March 14, 2020                 [Page 3]
Internet-Draft                IOAM Profiles               September 2019

2.2.  Use Cases

   An IOAM profile should define the use case(s) for using the profile.
   The use case may describe deployment scenarios or specific
   applications that make use of IOAM data.  The use case should
   typically define the required functionality from IOAM.  For example,
   an IOAM profile may be defined such that it requires transit delay
   monitoring, but does not require path tracing.  These requirements
   then affect which IOAM data fields are used in the profile.

2.3.  IOAM Options

   IOAM data may be represented in one of four possible IOAM options:
   Pre-allocated Trace Option, Incremental Trace Option, Proof Of
   Transit (POT) Option, and Edge-to-Edge Option.  An IOAM profile may
   specify a subset of allowed options.  A profile may define some
   options as mandatory in the current profile, or some options as
   forbidden in the current profile.  Moreover, in cases where IOAM
   defines several possible modes of operation, a profile may choose one
   of these modes of operation as the only allowed mode.

   For each IOAM option, a profile specification may limit the scope of
   the profile to certain features.  For example, a profile may be
   defined to use the Incremental Trace Option such that only specific
   data types are used in the profile, while others are not.

2.4.  IOAM Option Header Field Values

   An IOAM profile may define specific values or specific value range
   for some of the fields in the IOAM option headers.  For example, a
   profile may define a specific value that is allowed to be used in the
   Flags field of the trace option header.

2.5.  Opaque State Snapshot

   The Opaque State Snapshot, as defined in [I-D.ietf-ippm-ioam-data],
   is a variable length field that may be used in IOAM trace options.
   The Opaque State Snapshot is defined in a flexible Type/Length/Value
   manner.  An IOAM profile may define a specific format for the Opaque
   State Snapshot including for example a specific length and a specific
   interpretation of the opaque data.  In this case, the IOAM profile
   ought to also specify a Schema ID value.

2.6.  Timestamp Format

   A profile may specify a specific timestamp format to be used in IOAM
   data fields.

Mizrahi, et al.          Expires March 14, 2020                 [Page 4]
Internet-Draft                IOAM Profiles               September 2019

3.  IANA Considerations

   This document does not include any requests from IANA.

   [RFC-Editor Note: feel free to remove this Section.]

4.  Security Considerations

   The security considerations of IOAM in general are discussed in
   [I-D.ietf-ippm-ioam-data].  This document presents the concept of
   IOAM profiles; since an IOAM profile is a specific use case of IOAM,
   any security threat that is relevant to the profile is also relevant
   to the full-blown IOAM, as defined in [I-D.ietf-ippm-ioam-data].
   Therefore, the current document does not present any new security
   considerations beyond [I-D.ietf-ippm-ioam-data].

   Moreover, in some cases a profile may limit the set of features of
   IOAM in a way that reduces the set of potential threats compared to a
   full implementation of IOAM.  In fact, a particular IOAM profile can
   optimize a particular security posture or requirement.

5.  Normative References

   [I-D.ietf-ippm-ioam-data]
              Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,
              Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov,
              P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon,
              "Data Fields for In-situ OAM", draft-ietf-ippm-ioam-
              data-07 (work in progress), September 2019.

   [I-D.zhou-ippm-ioam-yang]
              Zhou, T., Guichard, J., Brockners, F., and S. Raghavan, "A
              YANG Data Model for In-Situ OAM", draft-zhou-ippm-ioam-
              yang-04 (work in progress), June 2019.

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

Appendix A.  An IOAM Profile Example

A.1.  Overview

   This section presents an example of an IOAM profile specification.
   The profile makes use of the Hop limit, Node ID and Transit delay
   data fields, and is thus called the HNT profile for short.

Mizrahi, et al.          Expires March 14, 2020                 [Page 5]
Internet-Draft                IOAM Profiles               September 2019

A.2.  Use Cases

   This profile is intended for path tracing and transit delay
   monitoring, while using compact data with just two data fields per
   packet.  The profile can be useful in networks with a large number of
   hops.

A.3.  IOAM Options

   The HNT profile makes use of the Incremental Trace Option.  A packet
   that includes IOAM data according to the current profile includes a
   single IOAM option - the Incremental Trace Option.  Specifically, two
   data fields are used in this profile: the Hop_Lim and node_id field,
   and the transit delay field.

A.4.  IOAM Option Header Field Values

   The IOAM-Trace-Type field in the header of the Incremental Trace
   Option in this profile has a fixed value; Bit 0 (the most significant
   bit) and Bit 4 are set, while the rest of the bits are zero,
   indicating the two data fields that are used in the option.

A.5.  Opaque State Snapshot

   The opaque state snapshot is never used in this profile.  Note that
   the NodeLen field, as defined in [I-D.ietf-ippm-ioam-data],
   represents the length of the data excluding the opaque state
   snapshot.  Since this field is not used in the current profile, the
   NodeLen represents the actual length of the data.

A.6.  Profile Coexistence

   It is assumed that the current profile is used in a confined
   administrative domain in which no other IOAM profiles are used.
   Therefore, it is assumed that the current profile does not coexist
   with other profiles.

A.7.  Validity

   An IOAM transit/decapsulating node that receives a packet with IOAM
   options that do not comply to the current profile should forward/
   decapsulate the packet without IOAM processing, if it is able to do
   so.  If a decapsulating node is not able to decapsulate an IOAM
   option that is not compliant to the current profile, the packet is
   discarded.

Mizrahi, et al.          Expires March 14, 2020                 [Page 6]
Internet-Draft                IOAM Profiles               September 2019

Authors' Addresses

   Tal Mizrahi
   Huawei Network.IO Innovation Lab
   Israel

   Email: tal.mizrahi.phd@gmail.com

   Frank Brockners
   Cisco Systems, Inc.
   Hansaallee 249, 3rd Floor
   DUESSELDORF, NORDRHEIN-WESTFALEN  40549
   Germany

   Email: fbrockne@cisco.com

   Shwetha Bhandari
   Cisco Systems, Inc.
   Cessna Business Park, Sarjapura Marathalli Outer Ring Road
   Bangalore, KARNATAKA 560 087
   India

   Email: shwethab@cisco.com

   Ramesh Sivakolundu
   Cisco Systems, Inc.
   170 West Tasman Dr.
   SAN JOSE, CA 95134
   U.S.A.

   Email: sramesh@cisco.com

   Carlos Pignataro
   Cisco Systems, Inc.
   7200-11 Kit Creek Road
   Research Triangle Park, NC  27709
   United States

   Email: cpignata@cisco.com

Mizrahi, et al.          Expires March 14, 2020                 [Page 7]
Internet-Draft                IOAM Profiles               September 2019

   Aviv Kfir
   Mellanox Technologies, Inc.
   350 Oakmead Parkway, Suite 100
   Sunnyvale, CA  94085
   U.S.A.

   Email: avivk@mellanox.com

   Barak Gafni
   Mellanox Technologies, Inc.
   350 Oakmead Parkway, Suite 100
   Sunnyvale, CA  94085
   U.S.A.

   Email: gbarak@mellanox.com

   Mickey Spiegel
   Barefoot Networks
   4750 Patrick Henry Drive
   Santa Clara, CA  95054
   US

   Email: mspiegel@barefootnetworks.com

   Tianran Zhou
   Huawei
   156 Beiqing Rd.
   Beijing  100095
   China

   Email: zhoutianran@huawei.com

   John Lemon
   Broadcom
   270 Innovation Drive
   San Jose, CA  95134
   US

   Email: john.lemon@broadcom.com

Mizrahi, et al.          Expires March 14, 2020                 [Page 8]