idnits 2.17.1 draft-zhou-ippm-enhanced-alternate-marking-03.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 (July 2, 2019) is 1753 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 (-17) exists of draft-ietf-ippm-ioam-data-05 == 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 Summary: 2 errors (**), 0 flaws (~~), 4 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 4 Intended status: Standards Track ZB. Li 5 Expires: January 3, 2020 Huawei 6 S. Lee 7 LG U+ 8 M. Cociglio 9 Telecom Italia 10 ZQ. Li 11 China Mobile 12 July 2, 2019 14 Enhanced Alternate Marking Method 15 draft-zhou-ippm-enhanced-alternate-marking-03 17 Abstract 19 This document defines data fields for the alternate marking with 20 enough space. More information can be considered within the 21 alternate marking field to facilitate the efficiency and ease the 22 deployment. 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 3, 2020. 47 Copyright Notice 49 Copyright (c) 2019 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. Implementing Multipoint Alternate Marking . . . . . . . . . . 4 67 3.1. PBT vs IOAM . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 4 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 74 8.2. Informative References . . . . . . . . . . . . . . . . . 6 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 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. However, in some protocols, no additional bit can be used, 87 which blocks the wide deployment of the alternate marking technique. 88 And the basic Alternate Marking method is limited with the 89 scalability for further extension, i.e, more measurements in addition 90 to existing use. 92 This document defines data fields for the alternate marking with 93 enough space. More information can be considered within the 94 alternate marking field to facilitate the efficiency and ease the 95 deployment. 97 Specifically, the flow identifier is applied as an enhancement for 98 the basic Alternate Marking when determining packet loss and packet 99 delay measurement. The flow identifier helps the data plane to 100 identify the specific flow, hence to do the processing with respect 101 to the Alternate Marking. It also simplifies the export by directly 102 being encapsulated as the index for the associated metrics. 104 PBT-M [I-D.song-ippm-postcard-based-telemetry] is an variation of 105 Postcard-based Telemetry (PBT) with packet Marking. One marking bit 106 is set in the user packet at the path head node, if its path- 107 associated data need to be collected. At each PBT-aware node, if the 108 mark is detected, a postcard (i.e., the dedicated telemetry packet 109 triggered by a marked user packet) is generated and sent to a 110 collector. The postcard contains the data requested by the 111 management plane. As an example, the requested data can be 112 configured by the management plane through data set templates (as in 113 IPFIX [RFC7011]). This alternate marking bit can choose user packet 114 on demand, e.g., periodically or triggered by condition meet, for 115 telemetry. 117 2. Data Fields Format 119 The following figure shows the data fields format for enhanced 120 alternate marking. This data is expected to be encapuslated to 121 specific transports. 123 0 1 2 3 124 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 125 +---------------------------------------+-+-+-+-----------------+ 126 | FlowID |L|D|M| Reserved | 127 +---------------------------------------+-+-+-+-----------------+ 129 where: 131 o FlowID - 20 bits unsigned integer. Flow identifier field is to 132 uniquely identify a monitored flow within the measurement domain. 133 The field is set at the engress node. The FlowID can be uniformly 134 assigned by the central controller or algorithmically generated by 135 the engress node. The latter approach cannot guarantee the 136 uniqueness of FlowID, yet the conflict probability is small due to 137 the large FlowID space. 139 o L - Loss flag as defined in [RFC8321]; 141 o D - Delay flag as defined in [RFC8321]; 142 o M - Marking bit as defined in PBT-M 143 [I-D.song-ippm-postcard-based-telemetry]; 145 o Reserved - is reserved for further use. These bits MUST be set to 146 zero. 148 3. Implementing Multipoint Alternate Marking 150 There are some considerations to do on how to manage the general 151 Multipoint Alternate Marking application in order to get more 152 adaptable performance measurement. 154 [I-D.ietf-ippm-multipoint-alt-mark] introduces the network clustering 155 approach for Alternate Marking: the network clusters partition can be 156 done at different levels to perform the needed degree of detail. The 157 Network Management can use an intelligent strategy: it can start 158 without examining in depth, and, in case of problems (i.e. measured 159 packet loss or too high delay), various filtering criteria can be 160 specified in order to perform a detailed analysis by using different 161 combination of clusters or, at the limit, a per-flow measurement. 163 3.1. PBT vs IOAM 165 In theory, both IOAM ([I-D.ietf-ippm-ioam-data]) and PBT 166 ([I-D.song-ippm-postcard-based-telemetry]) could include the base 167 Alternate Marking method. In practice, PBT-M supports one bit to 168 encode the alternate marking method. But the more general 169 implementation of Multipoint Alternate Marking, described in 170 [I-D.ietf-ippm-multipoint-alt-mark], needs a centralized Data 171 Collector and Network Management to allow the intelligent and 172 flexible Alternate Marking algorithm. For this purpose, the PostCard 173 based Telemetry Header can really be useful. 175 [I-D.song-ippm-postcard-based-telemetry] introduces the architecture 176 to directly export the telemetry data from network nodes to a 177 collector through separated OAM packets called postcards. 179 The overall architecture of PBT and the closed loop between Nodes, 180 Telemetry Data Collector and Network Management enables exactly the 181 application of the network clustering approach for Alternate Marking. 183 4. Implementation Status 185 [Note: This entire section should be removed by RFC Editor before the 186 RFC publication.] 188 This section records the status of known implementations of the 189 protocol defined by this specification at the time of posting of this 190 Internet-Draft, and is based on a proposal described in [RFC7942]. 191 The description of implementations in this section is intended to 192 assist the IETF in its decision processes in progressing drafts to 193 RFCs. Please note that the listing of any individual implementation 194 here does not imply endorsement by the IETF. Furthermore, no effort 195 has been spent to verify the information presented here that was 196 supplied by IETF contributors. This is not intended as, and must not 197 be construed to be, a catalog of available implementations or their 198 features. Readers are advised to note that other implementations may 199 exist. According to RFC 7942, "this will allow reviewers and working 200 groups to assign due consideration to documents that have the benefit 201 of running code, which may serve as evidence of valuable 202 experimentation and feedback that have made the implemented protocols 203 more mature. It is up to the individual working groups to use this 204 information as they see fit". 206 Huawei implemented the proposal described in this document based on 207 the NE40E router. The device can process the data fields in the 208 network processor in the fast path. Together with Huawei NCE 209 controller, the solution can provide very high precision per hop 210 packet loss detection and delay measurement. The product is ready 211 for MPLS based network and tested with LG U+, China Mobile and China 212 Unicom in mobile backhaul. The IPv6 and SRv6 based demonstration is 213 also implemented. Please contact Tianran Zhou 214 (zhoutianran@huawei.com) for the details. 216 5. Security Considerations 218 TBD 220 6. IANA Considerations 222 This document has no request to IANA. 224 7. Acknowledgements 226 The authors of this document would like to thank Haoyu Song for the 227 PBT-M contribution. 229 8. References 231 8.1. Normative References 233 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 234 Requirement Levels", BCP 14, RFC 2119, 235 DOI 10.17487/RFC2119, March 1997, 236 . 238 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 239 "Specification of the IP Flow Information Export (IPFIX) 240 Protocol for the Exchange of Flow Information", STD 77, 241 RFC 7011, DOI 10.17487/RFC7011, September 2013, 242 . 244 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 245 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 246 May 2016, . 248 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 249 Code: The Implementation Status Section", BCP 205, 250 RFC 7942, DOI 10.17487/RFC7942, July 2016, 251 . 253 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 254 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 255 "Alternate-Marking Method for Passive and Hybrid 256 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 257 January 2018, . 259 8.2. Informative References 261 [I-D.ietf-ippm-ioam-data] 262 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 263 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 264 P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, 265 "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- 266 data-05 (work in progress), March 2019. 268 [I-D.ietf-ippm-multipoint-alt-mark] 269 Fioccola, G., Cociglio, M., Sapio, A., and R. Sisto, 270 "Multipoint Alternate Marking method for passive and 271 hybrid performance monitoring", draft-ietf-ippm- 272 multipoint-alt-mark-02 (work in progress), July 2019. 274 [I-D.song-ippm-postcard-based-telemetry] 275 Song, H., Zhou, T., Li, Z., Shin, J., and K. Lee, 276 "Postcard-based On-Path Flow Data Telemetry", draft-song- 277 ippm-postcard-based-telemetry-04 (work in progress), June 278 2019. 280 Authors' Addresses 281 Tianran Zhou 282 Huawei 283 156 Beiqing Rd. 284 Beijing 100095 285 China 287 Email: zhoutianran@huawei.com 289 Giuseppe Fioccola 290 Huawei 291 Riesstrasse, 25 292 Munich 80992 293 Germany 295 Email: giuseppe.fioccola@huawei.com 297 Zhenbin Li 298 Huawei 299 156 Beiqing Rd. 300 Beijing 100095 301 China 303 Email: lizhenbin@huawei.com 305 Shinyoung Lee 306 LG U+ 307 71, Magokjungang 8-ro, Gangseo-gu 308 Seoul 309 Republic of Korea 311 Email: leesy@lguplus.co.kr 313 Mauro Cociglio 314 Telecom Italia 315 Via Reiss Romoli, 274 316 Torino 10148 317 Italy 319 Email: mauro.cociglio@telecomitalia.it 320 Zhenqiang Li 321 China Mobile 322 Beijing 323 China 325 Email: lizhenqiang@chinamobile.com