idnits 2.17.1 draft-fz-6man-ipv6-alt-mark-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 : ---------------------------------------------------------------------------- ** 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 (July 22, 2019) is 1711 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 (-17) exists of draft-ietf-ippm-ioam-data-06 == 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-04 == 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: January 23, 2020 M. Cociglio 6 Telecom Italia 7 July 22, 2019 9 IPv6 Application of the Alternate Marking Method 10 draft-fz-6man-ipv6-alt-mark-00 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 encapsulation header to encode alternate marking technique. 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 January 23, 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 Alternate Marking . . . . . . . . . . . . 3 62 3. IPv6 Extension Headers as Marking Field . . . . . . . . . . . 3 63 3.1. Definition of the AltMark Extension Header . . . . . . . 3 64 3.1.1. Data Fields Format . . . . . . . . . . . . . . . . . 4 65 3.1.2. AltMark: Destination Option and Hop-by-Hop Option . . 5 66 4. Alternate Marking Method Operation . . . . . . . . . . . . . 5 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 72 8.2. Informative References . . . . . . . . . . . . . . . . . 5 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 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 and SRv6. 86 The IPv6 Header Format defined in [RFC8200] introduces the format of 87 the IPv6 addresses, the Extension Headers in the base IPv6 Header and 88 the availability of a 20-bit flow label, that can be considered for 89 the application of the Alternate Marking methodology. In this 90 respect, [I-D.fioccola-v6ops-ipv6-alt-mark] reported a summary on the 91 possible implementation options for the application of the alternate 92 marking method in an IPv6 domain. 94 [I-D.zhou-ippm-enhanced-alternate-marking] defines the data field for 95 the alternate marking in order to generalize its application. More 96 information can be considered within the alternate marking field to 97 facilitate the efficiency and ease the deployment. 99 For the overall application of the methodology 100 [I-D.song-ippm-postcard-based-telemetry] introduces a new approach 101 named Postcard-Based Telemetry (PBT). It includes alternative ways 102 which can collect the same data of In-band OAM 103 ([I-D.ietf-ippm-ioam-data]) but avoid or mitigate the In-band OAM 104 issues. There are two variations of PBT: PBT-M and PBT-I. PBT-M 105 marks the user packets (set one bit) or configure the flow filter to 106 invoke the data collection. At each PBT-aware node, if the mark is 107 detected, a postcard is generated and sent to a collector. Instead, 108 PBT-I can be seen as a trade-off between IOAM and PBT-M. It needs to 109 add a fixed length instruction header to user packets for OAM data 110 collection, called Per-Hop Postcard (PHP), but, unlike IOAM, data are 111 exported through dedicated postcards. 113 Both PBT-M and PBT-I variations can allow the implementation of 114 [RFC8321] and [I-D.ietf-ippm-multipoint-alt-mark] and this is also 115 discussed in [I-D.zhou-ippm-enhanced-alternate-marking]. 117 2. IPv6 application of Alternate Marking 119 The application of the alternate marking requires a marking field. 120 Several alternatives have been analysed in 121 [I-D.fioccola-v6ops-ipv6-alt-mark] (Extension Header, IPv6 Address, 122 Flow Label). Anyway the best choice would be the use of an Extension 123 Header (EH). 125 3. IPv6 Extension Headers as Marking Field 127 A new type of EH can be defined for this scope. In this way there is 128 enough space to implement and optimize the deployment of the 129 Alternate Marking method. 131 A possibility can be to use a Destination or a Hop-By-Hop(HBH) 132 Extension Header(EH). The assumption is that an EH with an alternate 133 marking measurement option can be defined. The router processing can 134 be easily optimized to handle this use case. 136 3.1. Definition of the AltMark Extension Header 138 The desired choice is to define a new Extension Header. 139 [I-D.zhou-ippm-enhanced-alternate-marking] generalizes the data 140 fields for the alternate marking method and inspired the layout. 142 3.1.1. Data Fields Format 144 The following figure shows the data fields format for enhanced 145 alternate marking. This data is expected to be encapsulated to 146 specific transports, in this case the IPv6 Option Header named 147 AltMark. 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Option Type | Opt Data Len | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | FlowID |L|D|M| Reserved | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 where: 159 o Option Type - 8 bit identifier of the type of option. It needs to 160 be allocated. 162 o Opt Data Len - 8 bit unsigned integer. Length of the Option Data 163 field of this option, in octets. 165 o FlowID - 20 bits unsigned integer. Flow identifier field is to 166 uniquely identify a monitored flow within the measurement domain. 167 The field is set at the ingress node. The FlowID can be uniformly 168 assigned by the central controller or algorithmically generated by 169 the ingress node. The latter approach cannot guarantee the 170 uniqueness of FlowID, yet the conflict probability is small due to 171 the large FlowID space. 173 o L - Loss flag as defined in [RFC8321]; 175 o D - Delay flag as defined in [RFC8321]; 177 o M - Marking bit as defined in PBT-M 178 [I-D.song-ippm-postcard-based-telemetry]; 180 o Reserved - is reserved for further use. These bits MUST be set to 181 zero. 183 Note that PBT-I [I-D.song-ippm-postcard-based-telemetry] can also be 184 used and the marking fields, in this case, are included in the PHP 185 Header Format as described in 186 [I-D.song-ippm-postcard-based-telemetry]. 188 3.1.2. AltMark: Destination Option and Hop-by-Hop Option 190 Using a new EH assumes that all routers in the domain support this 191 type of headers, but, beyond backward compatibility, the new AltMark 192 Option Layout seems the best way to implement the Alternate Marking 193 method. 195 It is important to highlight that the Option Layout can be used both 196 as Destination Option and as Hop-By-Hop Option depending on the Use 197 Cases. In general, it is needed to perform end-to-end or hop-by-hop 198 measurements, and the alternate marking methodology in [RFC8321] 199 allows, by definition, both end-to-end and hop-by-hop performance 200 measurements. 202 4. Alternate Marking Method Operation 204 [RFC8321] and [I-D.ietf-ippm-multipoint-alt-mark] describe in detail 205 the methodology. 207 5. Security Considerations 209 tbc 211 6. IANA Considerations 213 The option type should be assigned in IANA's "Destination Options and 214 Hop-by-Hop Options" registry. 216 7. Acknowledgements 218 tbc 220 8. References 222 8.1. Normative References 224 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 225 Requirement Levels", BCP 14, RFC 2119, 226 DOI 10.17487/RFC2119, March 1997, 227 . 229 8.2. Informative References 231 [I-D.fioccola-v6ops-ipv6-alt-mark] 232 Fioccola, G., Velde, G., Cociglio, M., and P. Muley, "IPv6 233 Performance Measurement with Alternate Marking Method", 234 draft-fioccola-v6ops-ipv6-alt-mark-01 (work in progress), 235 June 2018. 237 [I-D.ietf-ippm-ioam-data] 238 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 239 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 240 P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, 241 "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- 242 data-06 (work in progress), July 2019. 244 [I-D.ietf-ippm-multipoint-alt-mark] 245 Fioccola, G., Cociglio, M., Sapio, A., and R. Sisto, 246 "Multipoint Alternate Marking method for passive and 247 hybrid performance monitoring", draft-ietf-ippm- 248 multipoint-alt-mark-02 (work in progress), July 2019. 250 [I-D.song-ippm-postcard-based-telemetry] 251 Song, H., Zhou, T., Li, Z., Shin, J., and K. Lee, 252 "Postcard-based On-Path Flow Data Telemetry", draft-song- 253 ippm-postcard-based-telemetry-04 (work in progress), June 254 2019. 256 [I-D.zhou-ippm-enhanced-alternate-marking] 257 Zhou, T., Fioccola, G., Li, Z., Lee, S., Cociglio, M., and 258 Z. Li, "Enhanced Alternate Marking Method", draft-zhou- 259 ippm-enhanced-alternate-marking-03 (work in progress), 260 July 2019. 262 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 263 (IPv6) Specification", STD 86, RFC 8200, 264 DOI 10.17487/RFC8200, July 2017, 265 . 267 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 268 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 269 "Alternate-Marking Method for Passive and Hybrid 270 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 271 January 2018, . 273 Authors' Addresses 275 Giuseppe Fioccola 276 Huawei 277 Riesstrasse, 25 278 Munich 80992 279 Germany 281 Email: giuseppe.fioccola@huawei.com 282 Tianran Zhou 283 Huawei 284 156 Beiqing Rd. 285 Beijing 100095 286 China 288 Email: zhoutianran@huawei.com 290 Mauro Cociglio 291 Telecom Italia 292 Via Reiss Romoli, 274 293 Torino 10148 294 Italy 296 Email: mauro.cociglio@telecomitalia.it