draft-ietf-ippm-ioam-direct-export-01.txt   draft-ietf-ippm-ioam-direct-export-02.txt 
IPPM H. Song IPPM H. Song
Internet-Draft Futurewei Internet-Draft Futurewei
Intended status: Standards Track B. Gafni Intended status: Standards Track B. Gafni
Expires: February 6, 2021 Mellanox Technologies, Inc. Expires: May 5, 2021 Mellanox Technologies, Inc.
T. Zhou T. Zhou
Z. Li Z. Li
Huawei Huawei
F. Brockners F. Brockners
S. Bhandari S. Bhandari
R. Sivakolundu R. Sivakolundu
Cisco Cisco
T. Mizrahi, Ed. T. Mizrahi, Ed.
Huawei Smart Platforms iLab Huawei Smart Platforms iLab
August 5, 2020 November 1, 2020
In-situ OAM Direct Exporting In-situ OAM Direct Exporting
draft-ietf-ippm-ioam-direct-export-01 draft-ietf-ippm-ioam-direct-export-02
Abstract Abstract
In-situ Operations, Administration, and Maintenance (IOAM) is used In-situ Operations, Administration, and Maintenance (IOAM) is used
for recording and collecting operational and telemetry information. for recording and collecting operational and telemetry information.
Specifically, IOAM allows telemetry data to be pushed into data Specifically, IOAM allows telemetry data to be pushed into data
packets while they traverse the network. This document introduces a packets while they traverse the network. This document introduces a
new IOAM option type called the Direct Export (DEX) option, which is new IOAM option type called the Direct Export (DEX) option, which is
used as a trigger for IOAM data to be directly exported without being used as a trigger for IOAM data to be directly exported without being
pushed into in-flight data packets. pushed into in-flight data packets.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 6, 2021. This Internet-Draft will expire on May 5, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 34
2.1. Requirement Language . . . . . . . . . . . . . . . . . . 3 2.1. Requirement Language . . . . . . . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Direct Exporting (DEX) IOAM Option Type . . . . . . . . . 3 3. The Direct Exporting (DEX) IOAM Option Type . . . . . . . . . 3
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. The DEX Option Format . . . . . . . . . . . . . . . . . . 5 3.2. The DEX Option Format . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
4.1. IOAM Type . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. IOAM Type . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. IOAM DEX Flags . . . . . . . . . . . . . . . . . . . . . 6 4.2. IOAM DEX Flags . . . . . . . . . . . . . . . . . . . . . 6
5. Performance Considerations . . . . . . . . . . . . . . . . . 6 5. Performance Considerations . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Topics for Further Discussion . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8 Appendix A. Hop Limit and Hop Count in Direct Exporting . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
IOAM [I-D.ietf-ippm-ioam-data] is used for monitoring traffic in the IOAM [I-D.ietf-ippm-ioam-data] is used for monitoring traffic in the
network, and for incorporating IOAM data fields into in-flight data network, and for incorporating IOAM data fields into in-flight data
packets. packets.
IOAM makes use of four possible IOAM options, defined in IOAM makes use of four possible IOAM options, defined in
[I-D.ietf-ippm-ioam-data]: Pre-allocated Trace Option, Incremental [I-D.ietf-ippm-ioam-data]: Pre-allocated Trace Option, Incremental
skipping to change at page 7, line 37 skipping to change at page 7, line 37
In order to mitigate the attacks described above, it should be In order to mitigate the attacks described above, it should be
possible for IOAM-enabled devices to limit the exported IOAM data to possible for IOAM-enabled devices to limit the exported IOAM data to
a configurable rate. a configurable rate.
IOAM is assumed to be deployed in a restricted administrative domain, IOAM is assumed to be deployed in a restricted administrative domain,
thus limiting the scope of the threats above and their affect. This thus limiting the scope of the threats above and their affect. This
is a fundamental assumption with respect to the security aspects of is a fundamental assumption with respect to the security aspects of
IOAM, as further discussed in [I-D.ietf-ippm-ioam-data]. IOAM, as further discussed in [I-D.ietf-ippm-ioam-data].
7. Topics for Further Discussion 7. References
o Hop Limit / Hop Count: in order to help correlate and order the
exported packets, it is possible to include a 1-octet Hop Count
field in the DEX header (presumably by claiming some space from
the Flags field). Its value starts from 0 at the encapsulating
node and is incremented by each IOAM transit node that supports
the DEX option. The Hop Count field value is also included in the
exported packet. An alternative approach is to use the Hop_Lim/
Node_ID data field; if the IOAM-Trace-Type
[I-D.ietf-ippm-ioam-data] has the Hop_Lim/Node_ID bit set, then
exported packets include the Hop_Lim/Node_ID data field, which
contains the TTL/Hop Limit value from a lower layer protocol. The
main advantage of the Hop_Lim/Node_ID approach is that it provides
information about the current hop count without requiring each
transit node to modify the DEX option, thus simplifying the data
plane functionality of Direct Exporting. The main advantage of
the Hop Count approach is that it counts the number of IOAM-
capable nodes without relying on the lower layer TTL, especially
when the lower layer cannot prvide the accurate TTL information,
e.g., Layer 2 Ethernet or hierarchical VPN. It also explicitly
allows to detect a case where an IOAM-capable node fails to export
packets. In order to facilitate the Hop Count approach it is
possible to use a flag to indicate an optional Hop Count field,
which enables to control the tradeoff. On one hand it addresses
the use cases that the Hop_Lim/Node_ID cannot cover, and on the
other hand it does not require transit switches to update the
option if it is not supported or disabled. Further discussion is
required about the tradeoff between the two alternatives.
8. References
8.1. Normative References 7.1. Normative References
[I-D.ietf-ippm-ioam-data] [I-D.ietf-ippm-ioam-data]
Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields
for In-situ OAM", draft-ietf-ippm-ioam-data-10 (work in for In-situ OAM", draft-ietf-ippm-ioam-data-10 (work in
progress), July 2020. progress), July 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
8.2. Informative References 7.2. Informative References
[I-D.ietf-ippm-ioam-flags] [I-D.ietf-ippm-ioam-flags]
Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R., Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R.,
Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., and J. Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., and J.
Lemon, "In-situ OAM Flags", draft-ietf-ippm-ioam-flags-02 Lemon, "In-situ OAM Flags", draft-ietf-ippm-ioam-flags-03
(work in progress), July 2020. (work in progress), October 2020.
[I-D.song-ippm-postcard-based-telemetry] [I-D.song-ippm-postcard-based-telemetry]
Song, H., Zhou, T., Li, Z., Shin, J., and K. Lee, Song, H., Zhou, T., Li, Z., Mirsky, G., Shin, J., and K.
"Postcard-based On-Path Flow Data Telemetry", draft-song- Lee, "Postcard-based On-Path Flow Data Telemetry using
ippm-postcard-based-telemetry-07 (work in progress), April Packet Marking", draft-song-ippm-postcard-based-
2020. telemetry-08 (work in progress), October 2020.
[I-D.spiegel-ippm-ioam-rawexport] [I-D.spiegel-ippm-ioam-rawexport]
Spiegel, M., Brockners, F., Bhandari, S., and R. Spiegel, M., Brockners, F., Bhandari, S., and R.
Sivakolundu, "In-situ OAM raw data export with IPFIX", Sivakolundu, "In-situ OAM raw data export with IPFIX",
draft-spiegel-ippm-ioam-rawexport-03 (work in progress), draft-spiegel-ippm-ioam-rawexport-03 (work in progress),
March 2020. March 2020.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
Appendix A. Hop Limit and Hop Count in Direct Exporting
In order to help correlate and order the exported packets, it is
possible to include the Hop_Lim/Node_ID data field in exported
packets; if the IOAM-Trace-Type [I-D.ietf-ippm-ioam-data] has the
Hop_Lim/Node_ID bit set, then exported packets include the Hop_Lim/
Node_ID data field, which contains the TTL/Hop Limit value from a
lower layer protocol.
An alternative approach was considered during the design of this
document, according to which a 1-octet Hop Count field would be
included in the DEX header (presumably by claiming some space from
the Flags field). The Hop Limit would starts from 0 at the
encapsulating node and be incremented by each IOAM transit node that
supports the DEX option. In this approach the Hop Count field value
would also be included in the exported packet.
The main advantage of the Hop_Lim/Node_ID approach is that it
provides information about the current hop count without requiring
each transit node to modify the DEX option, thus simplifying the data
plane functionality of Direct Exporting. The main advantage of the
Hop Count approach that was considered is that it counts the number
of IOAM-capable nodes without relying on the lower layer TTL,
especially when the lower layer cannot prvide the accurate TTL
information, e.g., Layer 2 Ethernet or hierarchical VPN. The Hop
Count approach would also explicitly allow to detect a case where an
IOAM-capable node fails to export packets. It would also be possible
to use a flag to indicate an optional Hop Count field, which enables
to control the tradeoff. On one hand it would address the use cases
that the Hop_Lim/Node_ID cannot cover, and on the other hand it would
not require transit switches to update the option if it was not
supported or disabled. For the sake of simplicity the Hop Count
approach was not pursued, and this field is not incorporated in the
DEX header.
Authors' Addresses Authors' Addresses
Haoyu Song Haoyu Song
Futurewei Futurewei
2330 Central Expressway 2330 Central Expressway
Santa Clara 95050 Santa Clara 95050
USA USA
Email: haoyu.song@huawei.com Email: haoyu.song@huawei.com
 End of changes. 11 change blocks. 
47 lines changed or deleted 52 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/