idnits 2.17.1 draft-zhou-ippm-enhanced-alternate-marking-07.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 ([I-D.ietf-6man-ipv6-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 11, 2021) is 1010 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 (-08) exists of draft-fz-spring-srv6-alt-mark-00 ** Downref: Normative reference to an Informational draft: draft-fz-spring-srv6-alt-mark (ref. 'I-D.fz-spring-srv6-alt-mark') == Outdated reference: A later version (-17) exists of draft-ietf-6man-ipv6-alt-mark-04 ** Downref: Normative reference to an Informational RFC: RFC 7799 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) -- Obsolete informational reference (is this intentional?): RFC 8889 (Obsoleted by RFC 9342) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPPM T. Zhou, Ed. 3 Internet-Draft G. Fioccola 4 Intended status: Standards Track Huawei 5 Expires: January 12, 2022 Y. Liu 6 China Mobile 7 S. Lee 8 LG U+ 9 M. Cociglio 10 Telecom Italia 11 W. Li 12 Huawei 13 July 11, 2021 15 Enhanced Alternate Marking Method 16 draft-zhou-ippm-enhanced-alternate-marking-07 18 Abstract 20 This document extends the IPv6 Alternate Marking Option, defined in 21 IPv6 AltMark Option [I-D.ietf-6man-ipv6-alt-mark], to provide the 22 enhanced capabilities and allow advanced functionalities. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 12, 2022. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Data Fields Format . . . . . . . . . . . . . . . . . . . . . 3 66 3. Enhanced Alternate Marking capabilities . . . . . . . . . . . 4 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 69 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 71 6.2. Informative References . . . . . . . . . . . . . . . . . 5 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 74 1. Introduction 76 The Alternate Marking [RFC8321] and Multipoint Alternate Marking 77 [RFC8889] define the Alternate Marking technique that is an hybrid 78 performance measurement method, per [RFC7799] classification of 79 measurement methods. This method is based on marking consecutive 80 batches of packets and it can be used to measure packet loss, 81 latency, and jitter on live traffic. 83 IPv6 AltMark Option [I-D.ietf-6man-ipv6-alt-mark] applies the 84 Alternate Marking Method to the IPv6 protocol, and defines Extension 85 Header Option to encode Alternate Marking Method for both Hop-by-Hop 86 Options Header and Destination Options Header. Similarly, SRv6 87 AltMark [I-D.fz-spring-srv6-alt-mark] defines how Alternate Marking 88 data is carried as SRH TLV. 90 While the AltMark Option implements the basic alternate marking 91 method, this document defines the extended data fields for the 92 AltMark Option and provides the enhanced capabilities. 94 It is worth mentioning that the enhanced capabilities are intended 95 for further use and are optional. 97 2. Data Fields Format 99 The Data Fields format is represented in the next figure. An 8 bits 100 NextHeader field is allocated from the Reserved field of IPv6 AltMark 101 Option [I-D.ietf-6man-ipv6-alt-mark]. 103 0 1 2 3 104 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 105 +---------------------------------------+-+-+---+---------------+ 106 | FlowMonID |L|D| R | NextHeader | 107 +---------------------------------------+-+-+---+---------------+ 109 The NextHeader field is used to indicate the extended data fields 110 which are used for enhanced capabilities. When the NextHeader is 0, 111 there is no extended data field attached. Value 1-8 are reserved for 112 private use. 114 The following figure shows the extended data fields format when the 115 NextHeader value is 9. 117 0 1 2 3 118 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 119 +---------------------------------------+-------+-------+-------+ 120 | FlowMonID Ext | Flag | Len | R | 121 +---------------------------------------+-------+-------+-------+ 122 | MetaInfo | R | 123 +---------------------------------------------------------------+ 125 where: 127 o FlowMonID Ext - 20 bits unsigned integer. This is used to extend 128 the FlowMonID to reduce the conflict when random allocation is 129 applied. The disambiguation of the FlowMonID field is discussed 130 in IPv6 AltMark Option [I-D.ietf-6man-ipv6-alt-mark]. 132 o Flag - A 4 bits flag to indicate the special purpose usage. 134 o Len - Length. It indicates the length of extension headers. 136 o MetaInfo - A 16 bits Bitmap to indicate more meta data attached 137 for the enhanced function. 139 o R - Reserved for further use. These bits MUST be set to zero. 141 The Flag is defined as follows: 143 o bit 1 - Flow direction identification, F bit. F=1, indicates that 144 the flow direction is forward. F=0, indicates the flow direction 145 is backward. 147 o bit 3 - Measurement mode, M bit. M=1, indicates that it is for 148 hop-by-hop monitoring. M=0, indicates that it is for end-to-end 149 monitoring. 151 o others - Reserved. 153 3. Enhanced Alternate Marking capabilities 155 The extended data fields presented in the previous section can be 156 used for several uses. Some possible applications can be: 158 1. shortest marking periods of single marking method for thicker 159 packet loss measurements. 161 2. more dense delay measurements than double marking method (down to 162 each packet). 164 3. increase the entropy of flow monitoring identifier by extending 165 the size of FlowMonID. 167 4. automatically set up the backward direction flow monitoring. 169 5. and so on. 171 4. Security Considerations 173 IPv6 AltMark Option [I-D.ietf-6man-ipv6-alt-mark] analyzes different 174 security concerns and related solutions. These aspects are valid and 175 applicable also to this document. In particular the fundamental 176 security requirement is that Alternate Marking MUST be applied in a 177 specific limited domain, as also mentioned in [RFC8799]. 179 5. IANA Considerations 181 This document has no request to IANA. 183 6. References 184 6.1. Normative References 186 [I-D.fz-spring-srv6-alt-mark] 187 Fioccola, G., Zhou, T., and M. Cociglio, "Segment Routing 188 Header encapsulation for Alternate Marking Method", draft- 189 fz-spring-srv6-alt-mark-00 (work in progress), January 190 2021. 192 [I-D.ietf-6man-ipv6-alt-mark] 193 Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. 194 Pang, "IPv6 Application of the Alternate Marking Method", 195 draft-ietf-6man-ipv6-alt-mark-04 (work in progress), March 196 2021. 198 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 199 Requirement Levels", BCP 14, RFC 2119, 200 DOI 10.17487/RFC2119, March 1997, 201 . 203 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 204 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 205 May 2016, . 207 6.2. Informative References 209 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 210 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 211 "Alternate-Marking Method for Passive and Hybrid 212 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 213 January 2018, . 215 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 216 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 217 . 219 [RFC8889] Fioccola, G., Ed., Cociglio, M., Sapio, A., and R. Sisto, 220 "Multipoint Alternate-Marking Method for Passive and 221 Hybrid Performance Monitoring", RFC 8889, 222 DOI 10.17487/RFC8889, August 2020, 223 . 225 Authors' Addresses 226 Tianran Zhou 227 Huawei 228 156 Beiqing Rd. 229 Beijing 100095 230 China 232 Email: zhoutianran@huawei.com 234 Giuseppe Fioccola 235 Huawei 236 Riesstrasse, 25 237 Munich 80992 238 Germany 240 Email: giuseppe.fioccola@huawei.com 242 Yisong Liu 243 China Mobile 244 Beijing 245 China 247 Email: liuyisong@chinamobile.com 249 Shinyoung Lee 250 LG U+ 251 71, Magokjungang 8-ro, Gangseo-gu 252 Seoul 253 Republic of Korea 255 Email: leesy@lguplus.co.kr 257 Mauro Cociglio 258 Telecom Italia 259 Via Reiss Romoli, 274 260 Torino 10148 261 Italy 263 Email: mauro.cociglio@telecomitalia.it 264 Weidong Li 265 Huawei 266 156 Beiqing Rd. 267 Beijing 100095 268 China 270 Email: poly.li@huawei.com