idnits 2.17.1 draft-fz-6man-ipv6-alt-mark-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 abstract seems to contain references ([RFC8321], [I-D.ietf-ippm-multipoint-alt-mark]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2019) is 1638 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 (-09) exists of draft-ietf-ippm-multipoint-alt-mark-02 == Outdated reference: A later version (-16) exists of draft-song-ippm-postcard-based-telemetry-06 == Outdated reference: A later version (-21) exists of draft-song-opsawg-ifit-framework-06 == Outdated reference: A later version (-14) exists of draft-zhou-ippm-enhanced-alternate-marking-03 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6MAN Working Group G. Fioccola 3 Internet-Draft T. Zhou 4 Intended status: Standards Track Huawei 5 Expires: May 3, 2020 M. Cociglio 6 Telecom Italia 7 October 31, 2019 9 IPv6 Application of the Alternate Marking Method 10 draft-fz-6man-ipv6-alt-mark-01 12 Abstract 14 This document describes how the alternate marking method in [RFC8321] 15 and [I-D.ietf-ippm-multipoint-alt-mark] can be used as the passive 16 performance measurement method in an IPv6 domain and reports 17 implementation considerations. It proposes how to define a new 18 Extension Header Option to encode alternate marking technique and 19 also considers the Segment Routing Header TLV alternative. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 3, 2020. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. IPv6 application of the Alternate Marking . . . . . . . . . . 3 63 3. Definition of the AltMark Option/TLV . . . . . . . . . . . . 4 64 3.1. Data Fields Format . . . . . . . . . . . . . . . . . . . 4 65 4. AltMark: EH Option or SRH TLV . . . . . . . . . . . . . . . . 5 66 5. Alternate Marking Method Operation . . . . . . . . . . . . . 5 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 72 9.2. Informative References . . . . . . . . . . . . . . . . . 6 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 [RFC8321] and [I-D.ietf-ippm-multipoint-alt-mark] describe passive 78 performance measurement method, which can be used to measure packet 79 loss, latency and jitter on live traffic. Since this method is based 80 on marking consecutive batches of packets, the method often referred 81 as Alternate Marking Method. 83 This document defines how the alternate marking method can be used to 84 measure packet loss and delay metrics of IPv6. Consequently, the 85 SRv6 (Segment Routing over IPv6 data plane) application is also 86 discussed. Both Extension Header (EH) Option and Segment Routing 87 Header (SRH) TLV are considered here. 89 The format of the IPv6 addresses is defined in [RFC4291]. [RFC8200] 90 introduces the IPv6 Header Format, including the Extension Headers in 91 the base IPv6 Header and the availability of a 20-bit flow label. In 92 this respect, [I-D.fioccola-v6ops-ipv6-alt-mark] reported a summary 93 on the possible implementation options for the application of the 94 alternate marking method in an IPv6 domain. This document, starting 95 from the outcome of [I-D.fioccola-v6ops-ipv6-alt-mark], introduces a 96 new Option/TLV that can be encoded as EH Option or as SRH TLV. 98 [I-D.zhou-ippm-enhanced-alternate-marking] defines the data fields 99 for the alternate marking in order to generalize its application. 100 More information can be considered within the alternate marking field 101 to facilitate the efficiency and ease the deployment. 103 [I-D.song-opsawg-ifit-framework] introduces the telemetry 104 architecture and [I-D.song-ippm-postcard-based-telemetry] defines the 105 Postcard-Based Telemetry with Packet Marking (PBT-M). PBT-M marks 106 the user packets (set one bit) or configure the flow filter to invoke 107 the data collection. At each PBT-aware node, if the mark is 108 detected, a postcard is generated and sent to a collector. 110 2. IPv6 application of the Alternate Marking 112 The application of the alternate marking requires a marking field. 113 As mentioned, several alternatives have been analysed in 114 [I-D.fioccola-v6ops-ipv6-alt-mark] (Extension Header, IPv6 Address, 115 Flow Label). Anyway the best choice would be the use of an Extension 116 Header(EH) Option or TLV. 118 A new Option/TLV can be defined for this scope. This approach 119 follows [RFC8200] that strongly recommended against creating new EHs 120 especially with hop by hop behaviour. 122 The document aims to be general for IPv6 data plane. A possibility 123 can be to use a Destination or a Hop-By-Hop(HBH) Extension 124 Header(EH). The assumption is that an EH with an alternate marking 125 measurement option can be defined. The router processing can be 126 easily optimized to handle this use case. For SRv6, SRH TLV (as 127 described in [I-D.ietf-6man-segment-routing-header]) can be a good 128 choice to encode the Data fields. 130 The main objective is to ensure enough space to implement and 131 optimize the deployment of the Alternate Marking method and the 132 introduction of a monitored flow identification field (FlowMonID), as 133 described in the next Section goes in this direction. FlowMonID is 134 also introduced in [I-D.zhou-ippm-enhanced-alternate-marking]. 136 Note that FlowMonID is different from the Flow Label field of the 137 IPv6 Header ([RFC8200]). Flow Label is used for application service, 138 like LB/ECMP and QoS. Instead, FlowMonID is only used to identify 139 the monitored flow. The reuse of flow label field for monitored flow 140 identification is not considered since it may change the application 141 intent and forwarding behaviour, so that the measurement does not 142 align with the original traffic. Furthermore the flow label may be 143 changed en route and this may also violate the measurement task. 144 That is to explain the reason why we need to introduce FlowMonID for 145 IPv6. Flow Label and FlowMonID within the same packet have different 146 scope, identify different flows, different usage. 148 3. Definition of the AltMark Option/TLV 150 The desired choice is to define a new Extension Header Option/TLV. 151 [I-D.zhou-ippm-enhanced-alternate-marking] generalizes the data 152 fields for the alternate marking method and inspired the layout. 154 3.1. Data Fields Format 156 The following figure shows the data fields format for enhanced 157 alternate marking EH Option/TLV. This AltMark data is expected to be 158 encapsulated to specific encapsulation, e.g. the IPv6 Option or SRH 159 TLV. 161 0 1 2 3 162 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 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Type | Length | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | FlowMonID |L|D|M| Reserved | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 where: 171 o Type/Option Type: 8 bit identifier of the type of Option/TLV that 172 needs to be allocated. Unrecognised Types MUST be ignored on 173 receipt. 175 o Length/Opt Data Len: The length of the length Data Fields of this 176 Option/TLV in bytes. 178 o FlowMonID: 20 bits unsigned integer. The FlowMon identifier field 179 is to uniquely identify a monitored flow within the measurement 180 domain. The field is set at the ingress node. The FlowMonID can 181 be uniformly assigned by the central controller or algorithmically 182 generated by the ingress node. The latter approach cannot 183 guarantee the uniqueness of FlowMonID but it may be preferred for 184 local or private network, where the conflict probability is small 185 due to the large FlowMonID space. 187 o L: Loss flag as defined in [RFC8321]; 189 o D: Delay flag as defined in [RFC8321]; 191 o M: Marking bit as defined in PBT-M 192 [I-D.song-ippm-postcard-based-telemetry]; 194 o Reserved: is reserved for further use. These bits MUST be set to 195 zero. 197 4. AltMark: EH Option or SRH TLV 199 Using a new EH Option assumes that all routers in the domain support 200 this type of headers, but, beyond backward compatibility, the new 201 AltMark Option Layout seems the best way to implement the Alternate 202 Marking method. 204 It is important to highlight that the Option Layout can be used both 205 as Destination Option and as Hop-By-Hop Option depending on the Use 206 Cases. In general, it is needed to perform end-to-end or hop-by-hop 207 measurements, and the alternate marking methodology in [RFC8321] 208 allows, by definition, both end-to-end and hop-by-hop performance 209 measurements. 211 Regarding Hop-By-Hop Options Header, if we consider its real 212 deployment, it is sometimes dropped by legacy devices and not so used 213 by intermediate nodes. Destination Options Header is preferred. 215 SRv6 is a subset of IPv6 and it is one type of routing header. Like 216 any other use case of IPv6, HBH and Destination options are useable 217 when SRv6 header is present. Because SRv6 is a routing header, 218 destination options before the routing header are processed by each 219 destination in the route list. 221 SRH TLV can also be a good choice from this point of view. The 222 intermediated nodes that are not in the SID list can consider the SRH 223 as a green field, they cannot support and bypass or support and dig 224 into the SRH TLV. 226 5. Alternate Marking Method Operation 228 [RFC8321] and [I-D.ietf-ippm-multipoint-alt-mark] describe in detail 229 the methodology. 231 6. Security Considerations 233 tbc 235 7. IANA Considerations 237 The option type should be assigned in IANA's "Destination Options and 238 Hop-by-Hop Options" registry. Also, the TLV type should be assigned 239 from Segment Routing Header TLVs Registry. 241 8. Acknowledgements 243 tbc 245 9. References 247 9.1. Normative References 249 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 250 Requirement Levels", BCP 14, RFC 2119, 251 DOI 10.17487/RFC2119, March 1997, 252 . 254 9.2. Informative References 256 [I-D.fioccola-v6ops-ipv6-alt-mark] 257 Fioccola, G., Velde, G., Cociglio, M., and P. Muley, "IPv6 258 Performance Measurement with Alternate Marking Method", 259 draft-fioccola-v6ops-ipv6-alt-mark-01 (work in progress), 260 June 2018. 262 [I-D.ietf-6man-segment-routing-header] 263 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 264 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 265 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 266 progress), October 2019. 268 [I-D.ietf-ippm-multipoint-alt-mark] 269 Fioccola, G., Cociglio, M., Sapio, A., and R. Sisto, 270 "Multipoint Alternate Marking method for passive and 271 hybrid performance monitoring", draft-ietf-ippm- 272 multipoint-alt-mark-02 (work in progress), July 2019. 274 [I-D.song-ippm-postcard-based-telemetry] 275 Song, H., Zhou, T., Li, Z., Shin, J., and K. Lee, 276 "Postcard-based On-Path Flow Data Telemetry", draft-song- 277 ippm-postcard-based-telemetry-06 (work in progress), 278 October 2019. 280 [I-D.song-opsawg-ifit-framework] 281 Song, H., Li, Z., Zhou, T., Qin, F., Chen, H., Jin, J., 282 and J. Shin, "In-situ Flow Information Telemetry", draft- 283 song-opsawg-ifit-framework-06 (work in progress), October 284 2019. 286 [I-D.zhou-ippm-enhanced-alternate-marking] 287 Zhou, T., Fioccola, G., Li, Z., Lee, S., Cociglio, M., and 288 Z. Li, "Enhanced Alternate Marking Method", draft-zhou- 289 ippm-enhanced-alternate-marking-03 (work in progress), 290 July 2019. 292 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 293 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 294 2006, . 296 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 297 (IPv6) Specification", STD 86, RFC 8200, 298 DOI 10.17487/RFC8200, July 2017, 299 . 301 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 302 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 303 "Alternate-Marking Method for Passive and Hybrid 304 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 305 January 2018, . 307 Authors' Addresses 309 Giuseppe Fioccola 310 Huawei 311 Riesstrasse, 25 312 Munich 80992 313 Germany 315 Email: giuseppe.fioccola@huawei.com 317 Tianran Zhou 318 Huawei 319 156 Beiqing Rd. 320 Beijing 100095 321 China 323 Email: zhoutianran@huawei.com 325 Mauro Cociglio 326 Telecom Italia 327 Via Reiss Romoli, 274 328 Torino 10148 329 Italy 331 Email: mauro.cociglio@telecomitalia.it