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