idnits 2.17.1 draft-song-ippm-ioam-ipv6-support-01.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 (July 9, 2020) is 1380 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-09 == Outdated reference: A later version (-12) exists of draft-ietf-ippm-ioam-ipv6-options-01 ** 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-07 ** 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 (~~), 6 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: January 10, 2021 S. Peng 6 Huawei Technologies 7 J. Guichard 8 Futurewei 9 July 9, 2020 11 Approaches on Supporting IOAM in IPv6 12 draft-song-ippm-ioam-ipv6-support-01 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 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 January 10, 2021. 51 Copyright Notice 53 Copyright (c) 2020 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. There 96 are practical limitations on how far the hardware can reach into a 97 packet in forwarding hardware. The IOAM tracing option cannot be 98 applied if it makes other extension headers inaccessible. Even if 99 the other headers can be reached, the deeper they are, the higher the 100 cost to access and process them, and the lower the forwarding 101 performance. A potentially more detrimental issue is that the 102 incremental tracing option will expand the HbH header at each hop and 103 push back all other headers, which keeps shifting the locations of 104 the other extension headers, further complicating the hardware 105 implementation and impeding the forwarding. 107 The issue becomes severe when SRv6 and IOAM coexist. The Segment 108 Routing Extension Header (SRH) [I-D.ietf-6man-segment-routing-header] 109 is encapsulated in a routing header which is after the HbH options 110 header. SRH itself can be large. It requires read and write 111 operations at each SRv6 node. If it is deeply embedded in a packet 112 and its location keeps shifting, either it is beyond the reach of 113 hardware or the forwarding performance degrades. 115 We can avoid the problem by simply not using both at the same time, 116 but apparently this is not ideal, because IOAM is an important OAM 117 tool and it is even more wanted when SRv6 brings more operational 118 complexity into IPv6 networks. 120 Our second recourse is to limit the IOAM to SRv6 nodes only. That 121 is, consider SRv6 as an overlay tunnel over IPv6 and apply the IOAM 122 pipe mode as discussed in [I-D.song-ippm-ioam-tunnel-mode], which 123 only collects data at each SRv6 nodes. To realize this, 124 [I-D.ali-spring-ioam-srv6] describes an approach that encapsulates 125 the IOAM option data fields in an SRH TLV. [I-D.song-6man-srv6-pbt] 126 describes another approach to enable postcard-based telemetry for 127 SRv6 without needing IOAM option encapsulation. In either case, the 128 SRH is close to the packet front and its location is fixed. While 129 these approaches are useful for use cases that only need to monitor 130 the segment performance, it fails to cover all the IPv6 nodes in a 131 network. 133 So the proposition of this draft is, suppose we need to apply IOAM on 134 all nodes in an SRv6 network, how we can amend the approach in 135 [I-D.ietf-ippm-ioam-ipv6-options] or use alternative approaches to 136 circumvent the aforementioned issues. In this draft, we propose 137 three such approaches: (1) separating the IOAM trace data to a 138 different extension header, (2) using the postcard-based telemetry 139 (e.g., IOAM DEX) instead, and (3) applying the segment IOAM trace 140 export scheme. We discuss the pros and cons of each approach and 141 hope to foster standard convergence and industry adoption. 143 2. IOAM Data Separate and Postpose 145 An IOAM trace type data fields contain two parts: instruction and 146 trace data. Although by convention the trace data part immediately 147 follow the instruction part, there is not fundamental reason why 148 these two parts must stick together. This observation provides us an 149 optimization opportunity to amend the original proposal in 150 [I-D.ietf-ippm-ioam-ipv6-options]. 152 We separate the IOAM trace type data fields into the instruction part 153 and the trace data part. We encapsulate only the instruction part in 154 the HbH options header, and encapsulate the trace data part in 155 another metadata extension header after all the IPv6 extension 156 headers and before upper layer protocol headers. This arrangement 157 allows high performance hardware implementation. When using the 158 incremental data trace, even if the data trace size increases at each 159 node, all IPv6 extension headers remain intact and new data is 160 inserted at a fixed location. 162 Figure 1 shows the HbH option format for IOAM trace type instruction. 163 The field specification is identical to that in [RFC8200] and 164 [I-D.ietf-ippm-ioam-data]. 166 0 1 2 3 167 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 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Option Type | Opt Data Len | Reserved | IOAM Type | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<------+ 171 | Namespace-ID |NodeLen | Flags | RemainingLen| IOAM 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Trace 173 | IOAM-Trace-Type | Reserved | Type 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+. 414 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 415 (IPv6) Specification", STD 86, RFC 8200, 416 DOI 10.17487/RFC8200, July 2017, 417 . 419 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 420 "Network Service Header (NSH)", RFC 8300, 421 DOI 10.17487/RFC8300, January 2018, 422 . 424 Authors' Addresses 426 Haoyu Song 427 Futurewei 428 USA 430 Email: haoyu.song@futurewei.com 432 Zhenbin Li 433 Huawei Technologies 434 China 436 Email: lizhenbin@huawei.com 438 Shuping Peng 439 Huawei Technologies 440 China 442 Email: pengshuping@huawei.com 444 James Guichard 445 Futurewei 446 USA 448 Email: james.n.guichard@futurewei.com