idnits 2.17.1 draft-fz-6man-ipv6-alt-mark-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 : ---------------------------------------------------------------------------- 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 date (December 4, 2019) is 1604 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-03 == 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-08 == Outdated reference: A later version (-14) exists of draft-zhou-ippm-enhanced-alternate-marking-04 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) Summary: 0 errors (**), 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: June 6, 2020 M. Cociglio 6 Telecom Italia 7 December 4, 2019 9 IPv6 Application of the Alternate Marking Method 10 draft-fz-6man-ipv6-alt-mark-02 12 Abstract 14 This document describes how the Alternate Marking Method can be used 15 as the passive performance measurement tool in an IPv6 domain and 16 reports implementation considerations. It proposes how to define a 17 new Extension Header Option to encode alternate marking technique and 18 also considers the Segment Routing Header TLV alternative. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on June 6, 2020. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. IPv6 application of the Alternate Marking . . . . . . . . . . 3 62 3. Definition of the AltMark Option/TLV . . . . . . . . . . . . 4 63 3.1. Data Fields Format . . . . . . . . . . . . . . . . . . . 4 64 4. AltMark: EH Option or SRH TLV . . . . . . . . . . . . . . . . 5 65 5. Alternate Marking Method Operation . . . . . . . . . . . . . 6 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 71 9.2. Informative References . . . . . . . . . . . . . . . . . 6 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 [RFC8321] and [I-D.ietf-ippm-multipoint-alt-mark] describe passive 77 performance measurement method, which can be used to measure packet 78 loss, latency and jitter on live traffic. Since this method is based 79 on marking consecutive batches of packets, the method often referred 80 as Alternate Marking Method. 82 This document defines how the alternate marking method can be used to 83 measure packet loss and delay metrics of IPv6. Consequently, the 84 SRv6 (Segment Routing over IPv6 data plane) application is also 85 discussed. Both Extension Header (EH) Option and Segment Routing 86 Header (SRH) TLV are considered here. 88 The format of the IPv6 addresses is defined in [RFC4291]. [RFC8200] 89 introduces the IPv6 Header Format, including the Extension Headers in 90 the base IPv6 Header and the availability of a 20-bit flow label. In 91 this respect, [I-D.fioccola-v6ops-ipv6-alt-mark] reported a summary 92 on the possible implementation options for the application of the 93 alternate marking method in an IPv6 domain. This document, starting 94 from the outcome of [I-D.fioccola-v6ops-ipv6-alt-mark], introduces a 95 new Option/TLV that can be encoded as EH Option or as SRH TLV. 97 [I-D.zhou-ippm-enhanced-alternate-marking] defines the data fields 98 for the alternate marking in order to generalize its application. 99 More information can be considered within the alternate marking field 100 to facilitate the efficiency and ease the deployment. 102 [I-D.song-opsawg-ifit-framework] introduces the telemetry 103 architecture and [I-D.song-ippm-postcard-based-telemetry] defines the 104 Postcard-Based Telemetry with Packet Marking (PBT-M). PBT-M marks 105 the user packets (set one bit) or configure the flow filter to invoke 106 the data collection. At each PBT-aware node, if the mark is 107 detected, a postcard is generated and sent to a collector. 109 2. IPv6 application of the Alternate Marking 111 The application of the alternate marking requires a marking field. 112 As mentioned, several alternatives have been analysed in 113 [I-D.fioccola-v6ops-ipv6-alt-mark] (Extension Header, IPv6 Address, 114 Flow Label). Anyway the best choice would be the use of an Extension 115 Header(EH) Option or TLV. 117 A new Option/TLV can be defined for this scope. This approach 118 follows [RFC8200] that strongly recommended against creating new EHs 119 especially with hop by hop behaviour. 121 The document aims to be general for IPv6 data plane. A possibility 122 can be to use a Destination or a Hop-By-Hop(HBH) Extension 123 Header(EH). The assumption is that an EH with an alternate marking 124 measurement option can be defined. The router processing can be 125 easily optimized to handle this use case. For SRv6, SRH TLV (as 126 described in [I-D.ietf-6man-segment-routing-header]) can be a good 127 choice to encode the Data fields. 129 The main objective is to ensure enough space to implement and 130 optimize the deployment of the Alternate Marking method and the 131 introduction of a monitored flow identification field (FlowMonID), as 132 described in the next Section goes in this direction. FlowMonID is 133 also introduced in [I-D.zhou-ippm-enhanced-alternate-marking]. 135 Note that FlowMonID is different from the Flow Label field of the 136 IPv6 Header ([RFC8200]). Flow Label is used for application service, 137 like LB/ECMP and QoS. Instead, FlowMonID is only used to identify 138 the monitored flow. The reuse of flow label field for monitored flow 139 identification is not considered since it may change the application 140 intent and forwarding behaviour, so that the measurement does not 141 align with the original traffic. Furthermore the flow label may be 142 changed en route and this may also violate the measurement task. 143 That is to explain the reason why we need to introduce FlowMonID for 144 IPv6. Flow Label and FlowMonID within the same packet have different 145 scope, identify different flows, different usage. 147 3. Definition of the AltMark Option/TLV 149 The desired choice is to define a new Extension Header Option/TLV. 150 [I-D.zhou-ippm-enhanced-alternate-marking] generalizes the data 151 fields for the alternate marking method and inspired the layout. 153 3.1. Data Fields Format 155 The following figure shows the data fields format for enhanced 156 alternate marking EH Option/TLV. This AltMark data is expected to be 157 encapsulated to specific encapsulation, e.g. the IPv6 Option or SRH 158 TLV. 160 0 1 2 3 161 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 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Type | Length | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | FlowMonID |L|D|M| Reserved | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 where: 170 o Type/Option Type: 8 bit identifier of the type of Option/TLV that 171 needs to be allocated. Unrecognised Types MUST be ignored on 172 receipt. 174 o Length/Opt Data Len: The length of the length Data Fields of this 175 Option/TLV in bytes. 177 o FlowMonID: 20 bits unsigned integer. The FlowMon identifier field 178 is to uniquely identify a monitored flow within the measurement 179 domain. The field is set at the ingress node. The FlowMonID can 180 be uniformly assigned by the central controller or algorithmically 181 generated by the ingress node. The latter approach cannot 182 guarantee the uniqueness of FlowMonID but it may be preferred for 183 local or private network, where the conflict probability is small 184 due to the large FlowMonID space. 186 o L: Loss flag as defined in [RFC8321]; 188 o D: Delay flag as defined in [RFC8321]; 190 o M: Marking bit as defined in PBT-M 191 [I-D.song-ippm-postcard-based-telemetry]; 193 o Reserved: is reserved for further use. These bits MUST be set to 194 zero. 196 4. AltMark: EH Option or SRH TLV 198 Using a new EH Option assumes that all routers in the domain support 199 this type of headers, but, beyond backward compatibility, the new 200 AltMark Option Layout seems the best way to implement the Alternate 201 Marking method. 203 It is important to highlight that the Option Layout can be used both 204 as Destination Option and as Hop-By-Hop Option depending on the Use 205 Cases. In general, it is needed to perform end-to-end or hop-by-hop 206 measurements, and the alternate marking methodology in [RFC8321] 207 allows, by definition, both end-to-end and hop-by-hop performance 208 measurements. 210 So, Hop-By-Hop Options Header or Destination Options Header can be 211 used based on the chosen type of performance measurement. 213 SRv6 is a subset of IPv6 and it is one type of routing header. Like 214 any other use case of IPv6, HBH and Destination options are useable 215 when SRv6 header is present. Because SRv6 is a routing header, 216 destination options before the routing header are processed by each 217 destination in the route list. 219 SRH TLV can also be used to encode the AltMark Data Fields for SRv6. 220 Furthermore the intermediated nodes that are not in the SID list may 221 consider the SRH as a green field, therefore they cannot support and 222 bypass or support and dig into the SRH TLV. 224 In summary, it is possible to list the alternative options: 226 Destination Option => measurement only by node in Destination 227 Address. 229 Hop-By-Hop Option => every router on the path with feature 230 enabled. 232 SRH TLV => every node along the SR path. 234 Destination Option + SRH => every node along the SR path. 236 Note that the SRH TLV and Destination Option + SRH can be considered 237 equivalent; so in this case it may be preferred the use of SRH TLV. 239 In addition to the previous alternatives, for legacy network it is 240 possible to mention a non-conventional application of SRH TLV and 241 Destination Option for the hop-by-hop usage. [RFC8200] defines that 242 the nodes along a path examine and process the Hop-by-Hop Options 243 header only if HBH processing is explicitly configured. But, on the 244 other hand, using SRH TLV or Destination Option for hop-by-hop action 245 would cause worse performance than Hop-By-Hop. The only motivation 246 for hiding the hop-by-hop options inside of destination options can 247 be for compatibility reasons. Anyway this is not recommended. 249 5. Alternate Marking Method Operation 251 [RFC8321] and [I-D.ietf-ippm-multipoint-alt-mark] describe in detail 252 the methodology. 254 6. Security Considerations 256 tbc 258 7. IANA Considerations 260 The option type should be assigned in IANA's "Destination Options and 261 Hop-by-Hop Options" registry. Also, the TLV type should be assigned 262 from Segment Routing Header TLVs Registry. 264 8. Acknowledgements 266 The authors would like to thank Bob Hinden, Ole Troan, Tom Herbert, 267 Stefano Previdi for the precious comments and suggestions. 269 9. References 271 9.1. Normative References 273 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 274 Requirement Levels", BCP 14, RFC 2119, 275 DOI 10.17487/RFC2119, March 1997, 276 . 278 9.2. Informative References 280 [I-D.fioccola-v6ops-ipv6-alt-mark] 281 Fioccola, G., Velde, G., Cociglio, M., and P. Muley, "IPv6 282 Performance Measurement with Alternate Marking Method", 283 draft-fioccola-v6ops-ipv6-alt-mark-01 (work in progress), 284 June 2018. 286 [I-D.ietf-6man-segment-routing-header] 287 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 288 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 289 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 290 progress), October 2019. 292 [I-D.ietf-ippm-multipoint-alt-mark] 293 Fioccola, G., Cociglio, M., Sapio, A., and R. Sisto, 294 "Multipoint Alternate Marking method for passive and 295 hybrid performance monitoring", draft-ietf-ippm- 296 multipoint-alt-mark-03 (work in progress), November 2019. 298 [I-D.song-ippm-postcard-based-telemetry] 299 Song, H., Zhou, T., Li, Z., Shin, J., and K. Lee, 300 "Postcard-based On-Path Flow Data Telemetry", draft-song- 301 ippm-postcard-based-telemetry-06 (work in progress), 302 October 2019. 304 [I-D.song-opsawg-ifit-framework] 305 Song, H., Qin, F., Chen, H., Jin, J., and J. Shin, "In- 306 situ Flow Information Telemetry", draft-song-opsawg-ifit- 307 framework-08 (work in progress), November 2019. 309 [I-D.zhou-ippm-enhanced-alternate-marking] 310 Zhou, T., Fioccola, G., Li, Z., Lee, S., and M. Cociglio, 311 "Enhanced Alternate Marking Method", draft-zhou-ippm- 312 enhanced-alternate-marking-04 (work in progress), October 313 2019. 315 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 316 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 317 2006, . 319 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 320 (IPv6) Specification", STD 86, RFC 8200, 321 DOI 10.17487/RFC8200, July 2017, 322 . 324 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 325 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 326 "Alternate-Marking Method for Passive and Hybrid 327 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 328 January 2018, . 330 Authors' Addresses 332 Giuseppe Fioccola 333 Huawei 334 Riesstrasse, 25 335 Munich 80992 336 Germany 338 Email: giuseppe.fioccola@huawei.com 340 Tianran Zhou 341 Huawei 342 156 Beiqing Rd. 343 Beijing 100095 344 China 346 Email: zhoutianran@huawei.com 348 Mauro Cociglio 349 Telecom Italia 350 Via Reiss Romoli, 274 351 Torino 10148 352 Italy 354 Email: mauro.cociglio@telecomitalia.it