idnits 2.17.00 (12 Aug 2021) /tmp/idnits20735/draft-song-ippm-ioam-ipv6-support-02.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 (January 4, 2021) is 495 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 (-05) exists of draft-ali-spring-ioam-srv6-03 == Outdated reference: draft-ietf-6man-segment-routing-header has been published as RFC 8754 == Outdated reference: A later version (-13) exists of draft-ietf-6man-spring-srv6-oam-08 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-11 == Outdated reference: A later version (-07) exists of draft-ietf-ippm-ioam-ipv6-options-04 ** 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 (-12) exists of draft-song-ippm-postcard-based-telemetry-08 ** Downref: Normative reference to an Informational draft: draft-song-ippm-postcard-based-telemetry (ref. 'I-D.song-ippm-postcard-based-telemetry') == Outdated reference: A later version (-03) exists of draft-song-spring-siam-00 Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPPM H. Song 3 Internet-Draft Futurewei 4 Intended status: Standards Track Z. Li 5 Expires: July 8, 2021 S. Peng 6 Huawei Technologies 7 J. Guichard 8 Futurewei 9 January 4, 2021 11 Approaches on Supporting IOAM in IPv6 12 draft-song-ippm-ioam-ipv6-support-02 14 Abstract 16 It has been proposed to encapsulate IOAM tracing option data fields 17 in IPv6 HbH options header. However, due to size of the trace data 18 and the extension header location in the IPv6 packets, the proposal 19 creates practical challenges for implementation, especially when 20 other extension headers, such as a routing header, also exist and 21 require in-network processing. We propose several alternative 22 approaches to address this challenge, including separating the IOAM 23 trace data to a different extension header, using the postcard-based 24 telemetry (e.g., IOAM DEX) instead, and applying the segment IOAM 25 trace export scheme, based on the network scenario and application 26 requirements. We discuss the pros and cons of each approach and hope 27 to foster standard convergence and industry adoption. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on July 8, 2021. 51 Copyright Notice 53 Copyright (c) 2021 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. IOAM Data Separate and Postpose . . . . . . . . . . . . . . . 4 70 2.1. IOAM Trace Data Encapsulation . . . . . . . . . . . . . . 5 71 3. Segment IOAM Data Export . . . . . . . . . . . . . . . . . . 5 72 3.1. Independent of SRv6 . . . . . . . . . . . . . . . . . . . 5 73 3.2. Export at SRv6 node . . . . . . . . . . . . . . . . . . . 6 74 4. Direct Export Option . . . . . . . . . . . . . . . . . . . . 7 75 5. Comparison . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 77 7. Normative References . . . . . . . . . . . . . . . . . . . . 8 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 80 1. Introduction 82 In-situ OAM (IOAM) [I-D.ietf-ippm-ioam-data] defines two tracing 83 options, pre-allocated tracing option and incremental tracing option, 84 which record hop-by-hop data along a packet's forwarding path. The 85 draft [I-D.ietf-ippm-ioam-ipv6-options] proposes the method to 86 encapsulate IOAM trace option data fields in IPv6. Because the 87 tracing options requires per hop processing, such options can only be 88 encapsulated in IPv6 Hop-by-Hop (HbH) options header. The draft 89 [I-D.ioametal-ippm-6man-ioam-ipv6-deployment] further describes some 90 deployment approaches. 92 [RFC8200] mandates that the HbH options header, if exists, must be 93 the first extension header following the IPv6 header. However, the 94 IOAM trace data can be large, which easily amount to tens to hundreds 95 of bytes, making accessing other headers after it difficult or even 96 impossible. There are practical limitations on how far the hardware 97 can reach into a packet in forwarding hardware. The IOAM tracing 98 option cannot be applied if it makes other extension headers 99 inaccessible. Even if the other headers can be reached, the deeper 100 they are, the higher the cost to access and process them, and the 101 lower the forwarding performance. A potentially more detrimental 102 issue is that the incremental tracing option will expand the HbH 103 header at each hop and push back all other headers, which keeps 104 shifting the locations of the other extension headers, further 105 complicating the hardware implementation and impeding the forwarding. 107 The issue becomes more severe when SRv6 and IOAM coexist. The 108 Segment Routing Extension Header (SRH) 109 [I-D.ietf-6man-segment-routing-header] is encapsulated in a routing 110 header which is after the HbH options header. SRH itself can be 111 large. It requires read and write operations at each SRv6 node. If 112 it is deeply embedded in a packet and its location keeps shifting, 113 either it is beyond the reach of hardware or the forwarding 114 performance degrades. 116 We can avoid the problem by simply not using both at the same time, 117 but apparently this is not ideal, because IOAM is an important OAM 118 tool and it is even more wanted when SRv6 brings more operational 119 complexity into IPv6 networks. 121 Our second recourse is to limit the IOAM to SRv6 nodes only. That 122 is, consider SRv6 as an overlay tunnel over IPv6 and apply the IOAM 123 pipe mode as discussed in [I-D.song-ippm-ioam-tunnel-mode], which 124 only collects data at each SRv6 nodes. To realize this, 125 [I-D.ali-spring-ioam-srv6] describes an approach that encapsulates 126 the IOAM option data fields in an SRH TLV. [I-D.song-6man-srv6-pbt] 127 and [I-D.ietf-6man-spring-srv6-oam] describe another approach to 128 enable postcard-based telemetry for SRv6 without needing IOAM option 129 encapsulation. In either case, the SRH is close to the packet front 130 and its location is fixed. [I-D.song-spring-siam] proposes to 131 support IOAM in the payload of the dedicated SRv6 probing packets 132 only. While these approaches are useful for use cases that only need 133 to monitor the segment end points, it fails to cover all the IPv6 134 nodes in a network. 136 So the proposition of this draft is, suppose we need to apply IOAM on 137 all nodes in an SRv6 network, how we can amend the approach in 138 [I-D.ietf-ippm-ioam-ipv6-options] or use alternative approaches to 139 circumvent the aforementioned issues. In this draft, we propose 140 three such approaches: (1) separating the IOAM trace data to a 141 different extension header, (2) using the postcard-based telemetry 142 (e.g., IOAM DEX) instead, and (3) applying the segment IOAM trace 143 export scheme. We discuss the pros and cons of each approach and 144 hope to foster standard convergence and industry adoption. 146 2. IOAM Data Separate and Postpose 148 An IOAM trace type data fields contain two parts: instruction and 149 trace data. Although by convention the trace data part immediately 150 follow the instruction part, there is not fundamental reason why 151 these two parts must stick together. This observation provides us an 152 optimization opportunity to amend the original proposal in 153 [I-D.ietf-ippm-ioam-ipv6-options]. 155 We separate the IOAM trace type data fields into the instruction part 156 and the trace data part. We encapsulate only the instruction part in 157 the HbH options header, and encapsulate the trace data part in 158 another metadata extension header after all the IPv6 extension 159 headers and before upper layer protocol headers. This arrangement 160 allows high performance hardware implementation. When using the 161 incremental data trace, even if the data trace size increases at each 162 node, all IPv6 extension headers remain intact and new data is 163 inserted at a fixed location. 165 Figure 1 shows the HbH option format for IOAM trace type instruction. 166 The field specification is identical to that in [RFC8200] and 167 [I-D.ietf-ippm-ioam-data]. 169 0 1 2 3 170 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 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Option Type | Opt Data Len | Reserved | IOAM Type | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<------+ 174 | Namespace-ID |NodeLen | Flags | RemainingLen| IOAM 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Trace 176 | IOAM-Trace-Type | Reserved | Type 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+. 427 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 428 (IPv6) Specification", STD 86, RFC 8200, 429 DOI 10.17487/RFC8200, July 2017, 430 . 432 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 433 "Network Service Header (NSH)", RFC 8300, 434 DOI 10.17487/RFC8300, January 2018, 435 . 437 Authors' Addresses 439 Haoyu Song 440 Futurewei 441 USA 443 Email: haoyu.song@futurewei.com 445 Zhenbin Li 446 Huawei Technologies 447 China 449 Email: lizhenbin@huawei.com 451 Shuping Peng 452 Huawei Technologies 453 China 455 Email: pengshuping@huawei.com 456 James Guichard 457 Futurewei 458 USA 460 Email: james.n.guichard@futurewei.com