idnits 2.17.1 draft-zhou-ippm-enhanced-alternate-marking-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 (October 31, 2019) is 1640 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) ** Downref: Normative reference to an Informational RFC: RFC 7799 ** Obsolete normative reference: RFC 8321 (Obsoleted by RFC 9341) == Outdated reference: A later version (-09) exists of draft-fz-6man-ipv6-alt-mark-00 == Outdated reference: A later version (-15) exists of draft-ietf-bier-pmmm-oam-06 == Outdated reference: A later version (-09) exists of draft-ietf-ippm-multipoint-alt-mark-02 == Outdated reference: A later version (-10) exists of draft-ietf-mpls-rfc6374-sfl-04 == Outdated reference: A later version (-14) exists of draft-mirsky-sfc-pmamm-08 == 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-06 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPPM T. Zhou, Ed. 3 Internet-Draft G. Fioccola, Ed. 4 Intended status: Standards Track ZB. Li 5 Expires: May 3, 2020 Huawei 6 S. Lee 7 LG U+ 8 M. Cociglio 9 Telecom Italia 10 October 31, 2019 12 Enhanced Alternate Marking Method 13 draft-zhou-ippm-enhanced-alternate-marking-04 15 Abstract 17 This document defines data fields for the alternate marking with 18 enough space. The main idea is that more information can be 19 considered within the alternate marking field to facilitate the 20 efficiency and ease the deployment. The definition aims to be 21 general, even if for some protocols there can be dedicated solutions. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on May 3, 2020. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Data Fields Format . . . . . . . . . . . . . . . . . . . . . 3 65 3. Deployment Considerations . . . . . . . . . . . . . . . . . . 4 66 4. Implementing Multipoint Alternate Marking . . . . . . . . . . 5 67 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 5 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 70 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 71 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 74 10.2. Informative References . . . . . . . . . . . . . . . . . 7 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 77 1. Introduction 79 The Alternate Marking [RFC8321] technique is an hybrid performance 80 measurement method, per [RFC7799] classification of measurement 81 methods. Because this method is based on marking consecutive batches 82 of packets. It can be used to measure packet loss, latency, and 83 jitter on live traffic. 85 For the basic Alternate Marking method, bits are needed to record the 86 mark. For some protocols (e.g. MPLS, BIER, SFC, NVO3) dedicated 87 solutions have been presented ([I-D.ietf-mpls-rfc6374-sfl], 88 [I-D.ietf-bier-pmmm-oam], [I-D.mirsky-sfc-pmamm], 89 [I-D.fmm-nvo3-pm-alt-mark]), but there are ongoing discussions on 90 this matter. 92 However, in most of the protocols, no additional bit can be used or 93 proposed, and that blocks the wide deployment of the alternate 94 marking technique. In addition, the basic Alternate Marking method 95 is limited with the scalability issue for further extension, i.e, 96 more measurements in addition to existing use. 98 This document defines data fields for the alternate marking with 99 enough space, in particular for PBT (Postcard-based Telemetry). More 100 information can be considered within the alternate marking field to 101 facilitate the efficiency and ease the deployment. 103 Specifically, the flow identifier is applied as an enhancement for 104 the basic Alternate Marking when determining packet loss and packet 105 delay measurement. The flow identifier helps the data plane to 106 identify the specific flow, hence to do the processing with respect 107 to the Alternate Marking. It also simplifies the export by directly 108 being encapsulated as the index for the associated metrics. 110 PBT-M [I-D.song-ippm-postcard-based-telemetry] is an variation of PBT 111 with packet Marking. One marking bit is set in the user packet at 112 the path head node, if its path-associated data need to be collected. 113 At each PBT-aware node, if the mark is detected, a postcard (i.e., 114 the dedicated telemetry packet triggered by a marked user packet) is 115 generated and sent to a collector. The postcard contains the data 116 requested by the management plane. As an example, the requested data 117 can be configured by the management plane through data set templates 118 (as in IPFIX [RFC7011]). This alternate marking bit can choose user 119 packet on demand, e.g., periodically or triggered by condition meet, 120 for telemetry. 122 2. Data Fields Format 124 The following figure shows the data fields format for enhanced 125 alternate marking. This data is expected to be encapsulated to 126 specific transports. 128 0 1 2 3 129 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 130 +---------------------------------------+-+-+-+-----------------+ 131 | FlowMonID |L|D|M| Reserved | 132 +---------------------------------------+-+-+-+-----------------+ 134 where: 136 o FlowMonID - 20 bits unsigned integer. The FlowMon identifier 137 field is to uniquely identify a monitored flow within the 138 measurement domain. The field is set at the ingress node. The 139 FlowMonID can be uniformly assigned by the central controller or 140 algorithmically generated by the ingress node. The latter 141 approach cannot guarantee the uniqueness of FlowMonID but it may 142 be preferred for local or private network, where the conflict 143 probability is small due to the large FlowMonID space. 145 o L - Loss flag as defined in [RFC8321]; 147 o D - Delay flag as defined in [RFC8321]; 149 o M - Marking bit as defined in PBT-M 150 [I-D.song-ippm-postcard-based-telemetry]; 152 o Reserved - is reserved for further use. These bits MUST be set to 153 zero. 155 3. Deployment Considerations 157 The previous section introduces the AltMark Data Fields, based on the 158 deployment experience and gives a practice to apply alternate 159 marking. 161 The introduction of the flow identification is important for some 162 reasons: 164 Firstly, it helps to reduce the per node configuration. 165 Otherwise, each node needs to configure the ACLs for all the 166 monitored flows. And, with Flow ID, there may be different 167 granularity for flow definition. 169 Secondly, it simplifies the counters handling, because hardware is 170 hard to pull out and match the flow tuples defined by ACLs, 171 especially in tunnels. 173 Thirdly, it eases the data export encapsulation and correlation 174 for the collectors. 176 The deployment practice gives the motivation for this document. It 177 aims to do general deployment considerations and tries to avoid the 178 relation to specific protocols. Anyway it is important to mention 179 that, even for specific protocols where a dedicated solution exits, 180 the considerations of this document are always valid. 182 In some circumstances, the conclusion is to build a separate header 183 that is light-weighted but can address the existing requirement in 184 carrier network performance measurement. 186 While the AltMark Data Fields can take more information than the only 187 marking bits, it is important to consider how to carry it in the 188 encapsulation protocol. This enhanced proposal supports more 189 interesting and powerful use cases and address the in-band 190 performance measurement approach. 192 In IPv6 ([I-D.fz-6man-ipv6-alt-mark]), the way to mitigate the 193 compatibility with non-capable devices is considered. AltMark Data 194 Fields could be encapsulated in the DOH or SRH, so that the 195 intermediate node will not drop packets. 197 4. Implementing Multipoint Alternate Marking 199 There are some considerations to do on how to manage the general 200 Multipoint Alternate Marking application in order to get more 201 adaptable performance measurement. 203 [I-D.ietf-ippm-multipoint-alt-mark] introduces the network clustering 204 approach for Alternate Marking: the network clusters partition can be 205 done at different levels to perform the needed degree of detail. The 206 Network Management can use an intelligent strategy: it can start 207 without examining in depth, and, in case of problems (i.e. measured 208 packet loss or too high delay), various filtering criteria can be 209 specified in order to perform a detailed analysis by using different 210 combination of clusters or, at the limit, a per-flow measurement. 212 So, the more general implementation of Multipoint Alternate Marking 213 needs an intelligent and flexible Alternate Marking algorithm. For 214 this purpose, [I-D.song-opsawg-ifit-framework] introduces a telemetry 215 framework and describes the closed loop between Nodes, Telemetry Data 216 Collector and Network Management. 218 5. Implementation Status 220 [Note: This entire section should be removed by RFC Editor before the 221 RFC publication.] 223 This section records the status of known implementations of the 224 protocol defined by this specification at the time of posting of this 225 Internet-Draft, and is based on a proposal described in [RFC7942]. 226 The description of implementations in this section is intended to 227 assist the IETF in its decision processes in progressing drafts to 228 RFCs. Please note that the listing of any individual implementation 229 here does not imply endorsement by the IETF. Furthermore, no effort 230 has been spent to verify the information presented here that was 231 supplied by IETF contributors. This is not intended as, and must not 232 be construed to be, a catalog of available implementations or their 233 features. Readers are advised to note that other implementations may 234 exist. According to RFC 7942, "this will allow reviewers and working 235 groups to assign due consideration to documents that have the benefit 236 of running code, which may serve as evidence of valuable 237 experimentation and feedback that have made the implemented protocols 238 more mature. It is up to the individual working groups to use this 239 information as they see fit". 241 Huawei implemented the proposal described in this document based on 242 the NE40E router. The device can process the data fields in the 243 network processor in the fast path. Together with Huawei NCE 244 controller, the solution can provide very high precision per hop 245 packet loss detection and delay measurement. The product is ready 246 for MPLS based network and tested with LG U+, China Mobile and China 247 Unicom in mobile backhaul. The IPv6 and SRv6 based demonstration is 248 also implemented. Please contact Tianran Zhou 249 (zhoutianran@huawei.com) for the details. 251 6. Security Considerations 253 TBD 255 7. IANA Considerations 257 This document has no request to IANA. 259 8. Contributors 261 List of Contributors: 263 Zhenqiang Li, China Mobile, lizhenqiang@chinamobile.com 265 9. Acknowledgements 267 The authors of this document would like to thank Haoyu Song for the 268 PBT-M contribution. 270 10. References 272 10.1. Normative References 274 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 275 Requirement Levels", BCP 14, RFC 2119, 276 DOI 10.17487/RFC2119, March 1997, 277 . 279 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 280 "Specification of the IP Flow Information Export (IPFIX) 281 Protocol for the Exchange of Flow Information", STD 77, 282 RFC 7011, DOI 10.17487/RFC7011, September 2013, 283 . 285 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 286 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 287 May 2016, . 289 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 290 Code: The Implementation Status Section", BCP 205, 291 RFC 7942, DOI 10.17487/RFC7942, July 2016, 292 . 294 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 295 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 296 "Alternate-Marking Method for Passive and Hybrid 297 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 298 January 2018, . 300 10.2. Informative References 302 [I-D.fmm-nvo3-pm-alt-mark] 303 Fioccola, G., Mirsky, G., and T. Mizrahi, "Performance 304 Measurement (PM) with Alternate Marking in Network 305 Virtualization Overlays (NVO3)", draft-fmm-nvo3-pm-alt- 306 mark-03 (work in progress), October 2018. 308 [I-D.fz-6man-ipv6-alt-mark] 309 Fioccola, G., Zhou, T., and M. Cociglio, "IPv6 Application 310 of the Alternate Marking Method", draft-fz-6man-ipv6-alt- 311 mark-00 (work in progress), July 2019. 313 [I-D.ietf-bier-pmmm-oam] 314 Mirsky, G., Zheng, L., Chen, M., and G. Fioccola, 315 "Performance Measurement (PM) with Marking Method in Bit 316 Index Explicit Replication (BIER) Layer", draft-ietf-bier- 317 pmmm-oam-06 (work in progress), July 2019. 319 [I-D.ietf-ippm-multipoint-alt-mark] 320 Fioccola, G., Cociglio, M., Sapio, A., and R. Sisto, 321 "Multipoint Alternate Marking method for passive and 322 hybrid performance monitoring", draft-ietf-ippm- 323 multipoint-alt-mark-02 (work in progress), July 2019. 325 [I-D.ietf-mpls-rfc6374-sfl] 326 Bryant, S., Chen, M., Li, Z., Swallow, G., Sivabalan, S., 327 Mirsky, G., and G. Fioccola, "RFC6374 Synonymous Flow 328 Labels", draft-ietf-mpls-rfc6374-sfl-04 (work in 329 progress), July 2019. 331 [I-D.mirsky-sfc-pmamm] 332 Mirsky, G., Fioccola, G., and T. Mizrahi, "Performance 333 Measurement (PM) with Alternate Marking Method in Service 334 Function Chaining (SFC) Domain", draft-mirsky-sfc-pmamm-08 335 (work in progress), June 2019. 337 [I-D.song-ippm-postcard-based-telemetry] 338 Song, H., Zhou, T., Li, Z., Shin, J., and K. Lee, 339 "Postcard-based On-Path Flow Data Telemetry", draft-song- 340 ippm-postcard-based-telemetry-06 (work in progress), 341 October 2019. 343 [I-D.song-opsawg-ifit-framework] 344 Song, H., Li, Z., Zhou, T., Qin, F., Chen, H., Jin, J., 345 and J. Shin, "In-situ Flow Information Telemetry", draft- 346 song-opsawg-ifit-framework-06 (work in progress), October 347 2019. 349 Authors' Addresses 351 Tianran Zhou (editor) 352 Huawei 353 156 Beiqing Rd. 354 Beijing 100095 355 China 357 Email: zhoutianran@huawei.com 359 Giuseppe Fioccola (editor) 360 Huawei 361 Riesstrasse, 25 362 Munich 80992 363 Germany 365 Email: giuseppe.fioccola@huawei.com 367 Zhenbin Li 368 Huawei 369 156 Beiqing Rd. 370 Beijing 100095 371 China 373 Email: lizhenbin@huawei.com 374 Shinyoung Lee 375 LG U+ 376 71, Magokjungang 8-ro, Gangseo-gu 377 Seoul 378 Republic of Korea 380 Email: leesy@lguplus.co.kr 382 Mauro Cociglio 383 Telecom Italia 384 Via Reiss Romoli, 274 385 Torino 10148 386 Italy 388 Email: mauro.cociglio@telecomitalia.it