[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

ippm                                                        H. Song, Ed.
Internet-Draft                                                     Z. Li
Intended status: Informational                                   T. Zhou
Expires: December 27, 2018                                       Z. Wang
                                                                  Huawei
                                                           June 25, 2018


                   In-situ OAM Processing in Tunnels
                  draft-song-ippm-ioam-tunnel-mode-00

Abstract

   This document describes the In-situ OAM (iOAM) processing behavior in
   a network with tunnels.  Specifically, the iOAM processing in tunnels
   with the uniform model and the pipe model is discussed.  The
   procedure is applicable to different type of tunnel protocols.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

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 27, 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



Song, et al.            Expires December 27, 2018               [Page 1]


Internet-Draft              IOAM Tunnel Mode                   June 2018


   (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.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Uniform Model . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  U1: IOAM Domain Starts and Ends outside of a Tunnel . . .   3
     2.2.  U2: IOAM Domain Starts and Ends within a Tunnel . . . . .   4
     2.3.  U3: IOAM Domain Starts and Ends at any Nodes  . . . . . .   4
     2.4.  Discussion  . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Pipe Model  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  P1: IOAM Domain Starts and Ends outside of a Tunnel . . .   5
     3.2.  P2: IOAM Domain Starts and Ends within a Tunnel . . . . .   5
     3.3.  Discussion  . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   6
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Motivation

   In-situ OAM (iOAM) records OAM data associated with user packets
   while these packets traverse a network
   [I-D.brockners-inband-oam-requirements].  The iOAM instruction and
   data are kept in an iOAM header which is defined in
   [I-D.ietf-ippm-ioam-data].  The iOAM header needs to be encapsulated
   in a packet's transport protocol header in order to be processed by
   the network nodes who are capable of iOAM processing.  So far, the
   iOAM header encapsulation methods have been defined for several
   protocols, including IPv6, VXLAN-GPE, NSH, SRv6
   [I-D.brockners-inband-oam-transport],[I-D.ietf-sfc-ioam-nsh], GENEVE
   [I-D.brockners-ippm-ioam-geneve], GRE [I-D.weis-ippm-ioam-gre], and
   some others.

   While the original scope of iOAM is purposely confined to a single
   network domain for simplicity, the authentic E2E data collection
   capability of iOAM is invaluable to network operators.  In reality,



Song, et al.            Expires December 27, 2018               [Page 2]


Internet-Draft              IOAM Tunnel Mode                   June 2018


   especially in carrier networks, a user packet may traverse several
   network domains and pass through various tunnels for QoS, traffic
   engineering, or public network traversal.  To extend the scope of
   iOAM's applicability and fully realize iOAM's potential, we need to
   consider various network conditions.  In this document, we describe
   how iOAM should be processed in a network with tunnels.

   A tunneling protocol usually needs to add another layer of protocol
   header (i.e., the tunnel header) over the original packet.  Within a
   tunnel, only the outermost tunnel header is supposed to be processed
   by a network node.  Therefore, depending on the locations where the
   iOAM header is encapsulated/decapsulated and the tunnel operation
   mode, the iOAM processing is also different.

   In general, there are two modes of tunnel operations: the Uniform
   Model and the Pipe Model.  The Uniform Model treats the nodes in a
   tunnel uniformly as the nodes outside of the tunnel on an E2E path.
   On the contrary, the Pipe Model abstracts all the nodes between the
   tunnel ingress and egress as a circuit so no nodes in the tunnel is
   visible to the nodes outside of the tunnel.  The iOAM processing
   behavior is discussed for each mode as follows.

2.  Uniform Model

2.1.  U1: IOAM Domain Starts and Ends outside of a Tunnel

   In this case, a tunnel is fully in between the head node and the end
   node of an iOAM path.  This includes the situation that the tunnel
   ingress coincides with the iOAM head node and/or the tunnel egress
   coincides with the iOAM end node.  The iOAM header handling for
   different situation is described as follows:

   o  iOAM head node is outside of the tunnel: The iOAM header is
      encapsulated into the original packet and processed.

   o  iOAM head node is the tunnel ingress: The iOAM header is
      encapsulated into the original packet and processed.  The iOAM
      header is copied from the original packet and encapsulated into
      the underlay protocol header.

   o  iOAM end node is outside of the tunnel: The iOAM header is
      decapsulated from the original packet after iOAM processing.

   o  iOAM end node is the tunnel egress: The iOAM header in the
      underlay protocol header is processed as usual.  After the tunnel
      header is removed and the original packet is exposed, the iOAM
      header is copied to overwrite the original packet's iOAM header.




Song, et al.            Expires December 27, 2018               [Page 3]


Internet-Draft              IOAM Tunnel Mode                   June 2018


      After the iOAM processing is finished, the iOAM header is removed
      from the original packet.

   o  Other nodes in the iOAM domain: If the node is outside or inside
      of the tunnel, the iOAM header encapsulated in the outermost
      protocol header is processed.  If the node is the tunnel ingress,
      the iOAM header in the original packet needs to be copied and
      encapsulated into the underlay protocol header.  If the node is
      the tunnel egress, the iOAM header in the underlay protocol header
      needs to be copied to overwrite the iOAM header in the original
      packet.

2.2.  U2: IOAM Domain Starts and Ends within a Tunnel

   There is nothing special about this case since the transport network
   will not be aware of the tunnel.  In this case, the iOAM is processed
   as usual.

2.3.  U3: IOAM Domain Starts and Ends at any Nodes

   For extra flexibility, the iOAM domain can be configured to start and
   end at any node (e.g., in or out of a tunnel).  The iOAM header
   handling for different situation is described as follows:

   o  iOAM head node is outside of the tunnel: The iOAM header is
      encapsulated in the original packet.

   o  iOAM head node is the tunnel ingress: The iOAM header is
      encapsulated in the original packet first and processed.  Then the
      iOAM header is copied from the original packet and encapsulated
      into the underlay protocol header.  Meanwhile, the iOAM header in
      the original packet must be removed.

   o  iOAM head node is in the tunnel: The iOAM header is encapsulated
      in the underlay protocol header and processed.

   o  iOAM head node is the tunnel egress: The iOAM header is
      encapsulated in the underlay protocol header first and processed.
      When the tunnel header is removed, the iOAM header is copied from
      the underlay protocol header and encapsulated into the original
      packet.

   o  iOAM end node is outside of the tunnel: The iOAM header is
      decapsulated from the original packet.

   o  iOAM end node is the tunnel ingress: The iOAM header is
      decapsulated from the original packet.




Song, et al.            Expires December 27, 2018               [Page 4]


Internet-Draft              IOAM Tunnel Mode                   June 2018


   o  iOAM end node is in the tunnel: The iOAM header is decapsulated
      from the underlay protocol header.

   o  iOAM end node is the tunnel egress: The iOAM header is removed
      with the underlay protocol header.

   o  Tunnel ingress is in the IOAM domain: The iOAM header is
      decapsulated from the original packet and encapsulated in the
      underlay protocol header.

   o  Tunnel egress is in the iOAM domain: The iOAM header in the
      underlay protocol header is encapsulated into the original packet.

2.4.  Discussion

   U1 achieves the best implementation efficiency since it eliminates
   one encapsulation or decapsulation operation while U3 achieves the
   best flexibility and reduces the packet overhead.

   Since a tunnel usually aggregates multiple flows, so U2 (or U3 when
   the iOAM head node is in a tunnel) can only conduct iOAM at the
   tunnel granularity and on aggregated flows.

3.  Pipe Model

3.1.  P1: IOAM Domain Starts and Ends outside of a Tunnel

   This case includes the situation that the tunnel ingress coincides
   with the iOAM head node and/or the tunnel egress coincides with the
   iOAM end node.

   In this mode, the iOAM header only exists in the original packet.  It
   is not copied to the tunnel header.  Within the tunnel, the iOAM
   header is invisible to the underlay network so it is not processed.
   At the tunnel ingress, the iOAM header is processed before the tunnel
   header is applied.  At the tunnel egress, the iOAM header is
   processed after the tunnel header is removed.  To the iOAM header,
   the entire tunnel appears to be just one hop.

3.2.  P2: IOAM Domain Starts and Ends within a Tunnel

   This mode is identical to U2.

3.3.  Discussion

   In P1, the hop-by-hop iOAM data is missing for the tunnel.  However,
   this mode also provides a convenient way to pass through third party




Song, et al.            Expires December 27, 2018               [Page 5]


Internet-Draft              IOAM Tunnel Mode                   June 2018


   tunnels in which either the iOAM is not supported or the tunnel
   operators do not participate in the iOAM service.

   On the other hand, the tunnel operators can support iOAM
   independently to monitor the tunnel performance using the mode of P2.
   In this case, U1 can also be applied without any confliction, so both
   underlay and overlay can be monitored by different entities.

   When iOAM works in the E2E operation mode as described in
   [I-D.ietf-ippm-ioam-data], any tunnel on the path should be
   configured to the Pipe model in order to avoid the unnecessary iOAM
   header encapsulation/decapsulation.

4.  Examples

   Examples will be added in future revisions.

5.  Security Considerations

   TBD

6.  IANA Considerations

   N/A

7.  Contributors

   TBD.

8.  Acknowledgments

   TBD.

9.  References

9.1.  Normative References

   [I-D.brockners-inband-oam-transport]
              Brockners, F., Bhandari, S., Govindan, V., Pignataro, C.,
              Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes,
              D., Lapukhov, P., and R. Chang, "Encapsulations for In-
              situ OAM Data", draft-brockners-inband-oam-transport-05
              (work in progress), July 2017.








Song, et al.            Expires December 27, 2018               [Page 6]


Internet-Draft              IOAM Tunnel Mode                   June 2018


   [I-D.brockners-ippm-ioam-geneve]
              Brockners, F., Bhandari, S., Govindan, V., Pignataro, C.,
              Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes,
              D., Lapukhov, P., and R. Chang, "Geneve encapsulation for
              In-situ OAM Data", draft-brockners-ippm-ioam-geneve-01
              (work in progress), June 2018.

   [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-02 (work in progress), March 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.weis-ippm-ioam-gre]
              Weis, B., Brockners, F., crhill@cisco.com, c., Bhandari,
              S., Govindan, V., Pignataro, C., Gredler, H., Leddy, J.,
              Youell, S., Mizrahi, T., Kfir, A., Gafni, B., Lapukhov,
              P., and M. Spiegel, "GRE Encapsulation for In-situ OAM
              Data", draft-weis-ippm-ioam-gre-00 (work in progress),
              March 2018.

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

9.2.  Informative References

   [I-D.brockners-inband-oam-requirements]
              Brockners, F., Bhandari, S., Dara, S., Pignataro, C.,
              Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi,
              T., <>, P., and r. remy@barefootnetworks.com,
              "Requirements for In-situ OAM", draft-brockners-inband-
              oam-requirements-03 (work in progress), March 2017.

Authors' Addresses







Song, et al.            Expires December 27, 2018               [Page 7]


Internet-Draft              IOAM Tunnel Mode                   June 2018


   Haoyu Song (editor)
   Huawei
   2330 Central Expressway
   Santa Clara
   USA

   Email: haoyu.song@huawei.com


   Zhenbin Li
   Huawei
   156 Beiqing Road
   Beijing, 100095
   P.R. China

   Email: lizhenbin@huawei.com


   Tianran Zhou
   Huawei
   156 Beiqing Road
   Beijing, 100095
   P.R. China

   Email: zhoutianran@huawei.com


   Zhongzhen Wang
   Huawei
   156 Beiqing Road
   Beijing, 100095
   P.R. China

   Email: wangzhongzhen@huawei.com

















Song, et al.            Expires December 27, 2018               [Page 8]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/