idnits 2.17.1 draft-song-ioam-ipv6-support-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 12 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 2, 2020) is 1515 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-06) exists of draft-ali-spring-ioam-srv6-02 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-08 == Outdated reference: A later version (-12) exists of draft-ietf-ippm-ioam-ipv6-options-00 == Outdated reference: A later version (-03) exists of draft-ioametal-ippm-6man-ioam-ipv6-deployment-02 ** Downref: Normative reference to an Informational draft: draft-song-ippm-ioam-tunnel-mode (ref. 'I-D.song-ippm-ioam-tunnel-mode') == Outdated reference: A later version (-16) exists of draft-song-ippm-postcard-based-telemetry-06 ** Downref: Normative reference to an Informational draft: draft-song-ippm-postcard-based-telemetry (ref. 'I-D.song-ippm-postcard-based-telemetry') Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Song 3 Internet-Draft Futurewei 4 Intended status: Standards Track Z. Li 5 Expires: September 3, 2020 S. Peng 6 Huawei Technologies 7 March 2, 2020 9 Approaches on Supporting IOAM in IPv6 10 draft-song-ioam-ipv6-support-00 12 Abstract 14 It has been proposed to encapsulate IOAM tracing option data fields 15 in IPv6 HbH options header. However, due to size of the trace data 16 and its location in the IPv6 header packets, this arrangement creates 17 practical challenges for implementation, especially when other 18 extension headers, such as routing header, also exist and require in- 19 network processing. We propose several alternative approaches to 20 address this challenge, including separating the IOAM trace data to a 21 different extension header, using the postcard-based telemetry (e.g., 22 IOAM DEX) instead, and applying the segment IOAM trace export scheme, 23 based on the network scenario and application requirements. We 24 discuss the pros and cons of each approach and foster standard 25 convergence and industry adoption. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 3, 2020. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. IOAM Data Separate and Postpose . . . . . . . . . . . . . . . 3 69 2.1. IOAM Trace Data Encapsulation . . . . . . . . . . . . . . 5 70 3. Segment IOAM Data Export . . . . . . . . . . . . . . . . . . 5 71 3.1. Independent of SRv6 . . . . . . . . . . . . . . . . . . . 5 72 3.2. Export at SRv6 node . . . . . . . . . . . . . . . . . . . 6 73 4. Direct Export Option . . . . . . . . . . . . . . . . . . . . 7 74 5. Comparison . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 76 7. Normative References . . . . . . . . . . . . . . . . . . . . 8 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 79 1. Introduction 81 In-situ OAM (IOAM) [I-D.ietf-ippm-ioam-data] defines two options, 82 pre-allocated tracing option and incremental tracing option, which 83 record hop-by-hop data along a packet's forwarding path. The draft 84 [I-D.ietf-ippm-ioam-ipv6-options] proposes the method to encapsulate 85 IOAM trace option data fields in IPv6. Because the tracing options 86 requires per hop processing, such options can only be encapsulated in 87 IPv6 Hop-by-Hop (HbH) options header. The draft 88 [I-D.ioametal-ippm-6man-ioam-ipv6-deployment] further describes some 89 deployment approaches. 91 [RFC8200] mandates that the HbH options header, if exists, must be 92 the first extension header following the IPv6 header. However, the 93 IOAM trace data can be large, which easily amount to tens to hundreds 94 of bytes, making accessing other headers after it difficult. There 95 are practical limitations on how far the hardware can reach into a 96 packet in forwarding hardware. Even if the other headers can be 97 reached, the deeper they are, the higher the cost to access and 98 process them, and the lower the forwarding performance. A 99 potentially more detrimental issue is that the incremental tracing 100 option will expand the HbH header at each hop and push back all other 101 headers, which keeps shifting the locations of the other extension 102 headers, further complicating the hardware implementation and 103 impeding the forwarding. 105 The issue becomes severe when SRv6 and IOAM coexist. The Segment 106 Routing Extension Header (SRH) [I-D.ietf-6man-segment-routing-header] 107 is encapsulated in a routing header which is after the HbH options 108 header. SRH itself can be large. It requires read and write 109 operations at each SRv6 node. If it is deeply embedded in a packet 110 and its location keeps shifting, either it is beyond the reach of 111 hardware or the forwarding performance suffers. 113 We can shun the problem by simply avoiding using both at the same 114 time, but apparently this is not ideal, because IOAM is an important 115 OAM tool and it is even more wanted when SRv6 brings more operational 116 complexity into IPv6 networks. 118 Our second recourse is to limit the IOAM to SRv6 nodes only. That 119 is, consider SRv6 as an overlay tunnel over IPv6 and apply the IOAM 120 pipe mode as discussed in [I-D.song-ippm-ioam-tunnel-mode], which 121 only collects data at each SRv6 nodes. To realize this, 122 [I-D.ali-spring-ioam-srv6] describes an approach that encapsulates 123 the IOAM option data fields in an SRH TLV. [I-D.song-6man-srv6-pbt] 124 describes another approach to enable postcard-based telemetry for 125 SRv6 without needing IOAM option encapsulation. In either case, the 126 SRH is close to the packet front and its location is fixed. While 127 these approaches are useful for use cases that only need to monitor 128 the segment performance, it fails to cover all the IPv6 nodes in a 129 network. 131 So the proposition of this draft is, suppose we need to apply IOAM on 132 all nodes in an SRv6 network, how we can amend the approach in 133 [I-D.ietf-ippm-ioam-ipv6-options] or use alternative approaches to 134 circumvent the aforementioned issues. In this draft, we propose 135 three such approaches: separating the IOAM trace data to a different 136 extension header, using the postcard-based telemetry (e.g., IOAM DEX) 137 instead, and applying the segment IOAM trace export scheme. We 138 discuss the pros and cons of each approach and hope to foster 139 standard convergence and industry adoption. 141 2. IOAM Data Separate and Postpose 143 An IOAM trace type data fields contain two parts: instruction and 144 trace data. Although by convention the trace data part immediately 145 follow the instruction part, there is not fundamental reason why 146 these two parts must stick together. This observation provides us an 147 optimization opportunity to amend the original proposal in 148 [I-D.ietf-ippm-ioam-ipv6-options]. 150 We separate the IOAM trace type data fields into the instruction part 151 and the trace data part. We encapsulate only the instruction part in 152 the HbH options header, and encapsulate the trace data part in 153 another metadata extension header after all the IPv6 extension 154 headers and before upper layer protocol headers. This arrangement 155 allows high performance hardware implementation. When using the 156 incremental data trace, even if the data trace size increases at each 157 node, all IPv6 extension headers remain intact and new data is 158 inserted at a fixed location. 160 Figure 1 shows the HbH option format for IOAM trace type instruction. 161 The field specification is identical to that in [RFC8200] and 162 [I-D.ietf-ippm-ioam-data]. 164 0 1 2 3 165 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Option Type | Opt Data Len | Reserved | IOAM Type | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<------+ 169 | Namespace-ID |NodeLen | Flags | RemainingLen| IOAM 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Trace 171 | IOAM-Trace-Type | Reserved | Type 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+. 412 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 413 (IPv6) Specification", STD 86, RFC 8200, 414 DOI 10.17487/RFC8200, July 2017, 415 . 417 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 418 "Network Service Header (NSH)", RFC 8300, 419 DOI 10.17487/RFC8300, January 2018, 420 . 422 Authors' Addresses 424 Haoyu Song 425 Futurewei 426 Santa Clara 95050 427 USA 429 Email: haoyu.song@futurewei.com 431 Zhenbin Li 432 Huawei Technologies 433 Beijing 100095 434 China 436 Email: lizhenbin@huawei.com 438 Shuping Peng 439 Huawei Technologies 440 Beijing 100095 441 China 443 Email: pengshuping@huawei.com