idnits 2.17.1 draft-song-6man-srv6-pbt-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 : ---------------------------------------------------------------------------- No issues found here. 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 1, 2019) is 1760 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) == Unused Reference: 'RFC8126' is defined on line 190, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-21 == Outdated reference: A later version (-02) exists of draft-li-6man-ipv6-sfc-ifit-00 == Outdated reference: A later version (-16) exists of draft-song-ippm-postcard-based-telemetry-04 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man H. Song, Ed. 3 Internet-Draft Futurewei Technologies 4 Intended status: Standards Track July 1, 2019 5 Expires: January 2, 2020 7 Support Postcard-Based Telemetry for SRv6 OAM 8 draft-song-6man-srv6-pbt-00 10 Abstract 12 This document describes a method based on Postcard-based Telemetry 13 with Marking for SRv6 on-path OAM, which avoids the extra overhead 14 for encapsulating telemetry-related instruction and metadata in SRv6 15 packets. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 21 "OPTIONAL" in this document are to be interpreted as described in BCP 22 14 [RFC2119][RFC8174] when, and only when, they appear in all 23 capitals, as shown here. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 2, 2020. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. PBT Triggered by Marking for SRv6 . . . . . . . . . . . . . . 3 61 2.1. Data Template . . . . . . . . . . . . . . . . . . . . . . 3 62 2.2. Postcard Correlation . . . . . . . . . . . . . . . . . . 3 63 2.3. Operational Considerations . . . . . . . . . . . . . . . 4 64 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 66 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 4 67 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 70 7.2. Informative References . . . . . . . . . . . . . . . . . 5 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 73 1. Introduction 75 The ability to collect the on-path data about SRv6 packets at each 76 segment is important for SRv6 OAM, especially for monitoring the 77 application-aware services. The In-situ OAM (IOAM) 78 [I-D.brockners-inband-oam-data] trace option can be used for such 79 purpose. However, SRv6's SRH can be large due to the long segment 80 list. The IOAM trace option introduces significant additional 81 overhead to the SRv6 packets with its instruction and data trace. 82 The large header overhead complicates the packet processing and may 83 exceed the forwarding hardware's header processing capability. 85 The extra IOAM trace option header also brings some encapsulation 86 challenges as documented in [I-D.li-6man-ipv6-sfc-ifit]. Here we 87 restate a subtle issue about the IOAM scope: if IOAM header is 88 encapsulated as another IPv6 extension header, the juxtaposition of 89 IOAM and SRH makes it ambiguous to determine the coverage of IOAM: 90 should it be applied to the entire forwarding path or just to the 91 segment nodes? 93 The PBT-I scheme introduced in 94 [I-D.song-ippm-postcard-based-telemetry] partially relieves the 95 packet overhead pressure but the encapsulation issues remain. In 96 this draft, we propose to apply the PBT-M scheme from the same 97 document for on-path SRv6 telemetry. 99 2. PBT Triggered by Marking for SRv6 101 PBT-M requires marking a packet as a trigger to collect on-path data 102 about the packet. The collected data are exported by an independent 103 "postcard" packet. Therefore, there is no new header encapsulation 104 requirement. 106 Eight flag bits are currently reserved in SRH. One of those bits can 107 be used as the marking flag, as shown in the following figure. If 108 the "T"-bit is set to 1, the segment node which process the SRH needs 109 to export the on-path data about this packet as configured. 111 0 1 2 3 112 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 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | Last Entry |T| Flags | Tag | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | | 119 | | 120 ~ Segment List[] & TLV ~ 121 | | 122 | | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 Figure 1: SRH with PBT Mark Flag 127 2.1. Data Template 129 Although it is possible to configure the segment nodes about the data 130 set to collect, different flows may require different data collection 131 profiles. It would be more flexible to have multiple different data 132 templates supported by the segment nodes and each packet can 133 designate one template that best suits its interests to use. The 134 template ID can be carried as a TLV in SRH. 136 2.2. Postcard Correlation 138 As discussed in [I-D.song-ippm-postcard-based-telemetry], PBT-M has 139 some issues to correlate the postcards from the different segment 140 nodes for the same user packet. While several solutions are given to 141 mitigate the problem, it is ideal to be able to correlate the 142 postcards without any constraint and precondition. 144 A flow ID and a sequence number can be included as TLVs in SRH. The 145 specification and usage of the flow ID and the sequence number are 146 the same as those in PBT-I in 147 [I-D.song-ippm-postcard-based-telemetry]. Further, the exported 148 postcard may include the SRH or the current SID which provides a 149 trace to order the postcards. 151 2.3. Operational Considerations 153 The SR source node is responsible to determine the policy for setting 154 or resetting the "T"-bit. 156 The segment node can decide independently whether or not to react on 157 the "T"-bit. 159 3. Security Considerations 161 Since PBT incurs some extra packet processing and transport cost, "T" 162 flag is usually selectively set on a subset of packets by the source 163 node. A potential DoS attack may set the "T" flag for all the packet 164 with the intention to overwhelm the segment nodes. Therefore, the 165 postcards should be generated on the basis of the best effort. 167 4. IANA Considerations 169 [I-D.ietf-6man-segment-routing-header] defines a new registry named 170 "Segment Routing Header Flags". This document requests the 171 allocation of a new flag bit "T" for the telemetry trigger mark. 173 5. Contributors 175 TBD. 177 6. Acknowledgments 179 TBD. 181 7. References 183 7.1. Normative References 185 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 186 Requirement Levels", BCP 14, RFC 2119, 187 DOI 10.17487/RFC2119, March 1997, 188 . 190 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 191 Writing an IANA Considerations Section in RFCs", BCP 26, 192 RFC 8126, DOI 10.17487/RFC8126, June 2017, 193 . 195 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 196 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 197 May 2017, . 199 7.2. Informative References 201 [I-D.brockners-inband-oam-data] 202 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 203 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 204 P., Chang, R., and d. daniel.bernier@bell.ca, "Data Fields 205 for In-situ OAM", draft-brockners-inband-oam-data-07 (work 206 in progress), July 2017. 208 [I-D.ietf-6man-segment-routing-header] 209 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 210 Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment 211 Routing Header (SRH)", draft-ietf-6man-segment-routing- 212 header-21 (work in progress), June 2019. 214 [I-D.li-6man-ipv6-sfc-ifit] 215 Li, Z. and S. Peng, "Consideration of IPv6 Encapsulation 216 for SFC and IFIT", draft-li-6man-ipv6-sfc-ifit-00 (work in 217 progress), March 2019. 219 [I-D.song-ippm-postcard-based-telemetry] 220 Song, H., Zhou, T., Li, Z., Shin, J., and K. Lee, 221 "Postcard-based On-Path Flow Data Telemetry", draft-song- 222 ippm-postcard-based-telemetry-04 (work in progress), June 223 2019. 225 Author's Address 227 Haoyu Song (editor) 228 Futurewei Technologies 229 2330 Central Expressway 230 Santa Clara 231 USA 233 Email: hsong@futurewei.com