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