idnits 2.17.1 draft-zhou-ippm-enhanced-alternate-marking-08.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 (January 04, 2022) is 836 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-01 ** 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-12 ** 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: July 8, 2022 Y. Liu 6 China Mobile 7 S. Lee 8 LG U+ 9 M. Cociglio 10 Telecom Italia 11 W. Li 12 Huawei 13 January 04, 2022 15 Enhanced Alternate Marking Method 16 draft-zhou-ippm-enhanced-alternate-marking-08 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 July 8, 2022. 47 Copyright Notice 49 Copyright (c) 2022 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. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 5.1. Normative References . . . . . . . . . . . . . . . . . . 6 70 5.2. Informative References . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Introduction 75 The Alternate Marking [RFC8321] and Multipoint Alternate Marking 76 [RFC8889] define the Alternate Marking technique that is an hybrid 77 performance measurement method, per [RFC7799] classification of 78 measurement methods. This method is based on marking consecutive 79 batches of packets and it can be used to measure packet loss, 80 latency, and jitter on live traffic. 82 IPv6 AltMark Option [I-D.ietf-6man-ipv6-alt-mark] applies the 83 Alternate Marking Method to the IPv6 protocol, and defines Extension 84 Header Option to encode Alternate Marking Method for both Hop-by-Hop 85 Options Header and Destination Options Header. Similarly, SRv6 86 AltMark [I-D.fz-spring-srv6-alt-mark] defines how Alternate Marking 87 data is carried as SRH TLV. 89 While the AltMark Option implements the basic alternate marking 90 method, this document defines the extended data fields for the 91 AltMark Option and provides the enhanced capabilities. 93 It is worth mentioning that the enhanced capabilities are intended 94 for further use and are optional. 96 2. Data Fields Format 98 The Data Fields format is represented in the next figure. An 8 bits 99 NextHeader field is allocated from the Reserved field of IPv6 AltMark 100 Option [I-D.ietf-6man-ipv6-alt-mark]. 102 0 1 2 3 103 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 104 +---------------------------------------+-+-+---+---------------+ 105 | FlowMonID |L|D| R | NextHeader | 106 +---------------------------------------+-+-+---+---------------+ 108 Fig. 1: Data fields indicator for enhanced capabilities 110 The NextHeader field is used to indicate the extended data fields 111 which are used for enhanced capabilities. When the NextHeader is 112 0x00, there is no extended data field attached. Value 1-8 are 113 reserved for private use. 115 The following figure shows the extended data fields format when the 116 NextHeader value is 0x09. 118 0 1 2 3 119 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 120 +---------------------------------------+-------+-------+-------+ 121 | FlowMonID Ext | Flag | Len | R | 122 +---------------------------------------+-------+-------+-------+ 123 | MetaInfo | Padding | 124 +---------------------------------------------------------------+ 126 Fig. 2: Data fields extension for enhanced alternate marking 128 where: 130 o FlowMonID Ext - 20 bits unsigned integer. This is used to extend 131 the FlowMonID to reduce the conflict when random allocation is 132 applied. The disambiguation of the FlowMonID field is discussed 133 in IPv6 AltMark Option [I-D.ietf-6man-ipv6-alt-mark]. 135 o Flag - A 4 bits flag to indicate the special purpose usage. 137 o Len - Length. It indicates the length of extension headers. 139 o MetaInfo - A 16 bits Bitmap to indicate more meta data attached 140 for the enhanced function. 142 o R - Reserved for further use. These bits MUST be set to zero. 144 o Padding - These bits MUST be set to zero when not being used. 146 The Flag is defined as follows: 148 o bit 0 - Measurement mode, M bit. M=0, indicates that it is for 149 hop-by-hop monitoring. M=1, indicates that it is for end-to-end 150 monitoring. 152 o bit 2 - Flow direction identification, F bit. This flag is used 153 in the case backward direction flow monitoring is requested to set 154 up automatically. F=1, indicates that the flow direction is 155 forward. F=0, indicates the flow direction is backward. 157 o others - Reserved. 159 0 1 2 3 160 +-------+ 161 |M|R|F|R| 162 +-------+ 164 Fig. 3: Flag data field 166 The MetaInfo is defined as a bit map as follows: 168 0 1 2 3 4 5 6 7 169 +---------------+ 170 | MetaInfo | 171 +---------------+ 173 Fig. 4: MetaInfo data field 175 o bit 0: indicates a 6 bytes Timestamp is attached after the 176 MetaInfo. Timestamp(s) stands for the second part. It will 177 overwrite the Padding after MetaInfo. Timestamp(ns) stands for 178 the subsecond part with the unit of nano second. This Timestamp 179 is filled by the encapsulation node, and is taken all the way to 180 the decapsulation node. So that all the intermediate nodes could 181 compare it with its local time, and measure the one way delay. 183 0 1 2 3 184 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 185 +-------------------------------+ 186 | Timestamp(s) | 187 +-------------------------------+-------------------------------+ 188 | Timestamp(ns) | 189 +---------------------------------------------------------------+ 191 Fig. 5: Timestamp data field 193 o bit 1: indicates the control information with the following data 194 format is attached 196 0 1 2 3 197 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 198 +---------------+---------------+-----------+-------------------+ 199 | DIP Mask | SIP Mask | Control | Period | 200 +---------------+---------------+-----------+-------------------+ 202 Fig. 6: Control words for backward direction flow monitoring 204 This is used to set up the backward direction flow monitoring. 205 Where: 207 * DIP Mask: is the length of the destination IP prefix. 209 * SIP Mask: is the length of the source IP prefix. 211 * Control: indicates more match fields to set up the backward 212 direction flow monitoring. 214 * Period: indicates the alternate marking period with the unit of 215 second. 217 o bit 2: indicates a 4 bytes Sequence number with the following data 218 format is attached after the MetaInfo 220 0 1 2 3 221 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 222 +---------------------------------------------------------------+ 223 | Sequence | 224 +---------------------------------------------------------------+ 226 Fig. 7: Sequence number data field 228 3. Security Considerations 230 IPv6 AltMark Option [I-D.ietf-6man-ipv6-alt-mark] analyzes different 231 security concerns and related solutions. These aspects are valid and 232 applicable also to this document. In particular the fundamental 233 security requirement is that Alternate Marking MUST be applied in a 234 specific limited domain, as also mentioned in [RFC8799]. 236 4. IANA Considerations 238 This document has no request to IANA. 240 5. References 242 5.1. Normative References 244 [I-D.fz-spring-srv6-alt-mark] 245 Fioccola, G., Zhou, T., and M. Cociglio, "Segment Routing 246 Header encapsulation for Alternate Marking Method", draft- 247 fz-spring-srv6-alt-mark-01 (work in progress), July 2021. 249 [I-D.ietf-6man-ipv6-alt-mark] 250 Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. 251 Pang, "IPv6 Application of the Alternate Marking Method", 252 draft-ietf-6man-ipv6-alt-mark-12 (work in progress), 253 October 2021. 255 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 256 Requirement Levels", BCP 14, RFC 2119, 257 DOI 10.17487/RFC2119, March 1997, 258 . 260 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 261 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 262 May 2016, . 264 5.2. Informative References 266 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 267 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 268 "Alternate-Marking Method for Passive and Hybrid 269 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 270 January 2018, . 272 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 273 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 274 . 276 [RFC8889] Fioccola, G., Ed., Cociglio, M., Sapio, A., and R. Sisto, 277 "Multipoint Alternate-Marking Method for Passive and 278 Hybrid Performance Monitoring", RFC 8889, 279 DOI 10.17487/RFC8889, August 2020, 280 . 282 Authors' Addresses 284 Tianran Zhou 285 Huawei 286 156 Beiqing Rd. 287 Beijing 100095 288 China 290 Email: zhoutianran@huawei.com 292 Giuseppe Fioccola 293 Huawei 294 Riesstrasse, 25 295 Munich 80992 296 Germany 298 Email: giuseppe.fioccola@huawei.com 300 Yisong Liu 301 China Mobile 302 Beijing 303 China 305 Email: liuyisong@chinamobile.com 307 Shinyoung Lee 308 LG U+ 309 71, Magokjungang 8-ro, Gangseo-gu 310 Seoul 311 Republic of Korea 313 Email: leesy@lguplus.co.kr 314 Mauro Cociglio 315 Telecom Italia 316 Via Reiss Romoli, 274 317 Torino 10148 318 Italy 320 Email: mauro.cociglio@telecomitalia.it 322 Weidong Li 323 Huawei 324 156 Beiqing Rd. 325 Beijing 100095 326 China 328 Email: poly.li@huawei.com