idnits 2.17.1 draft-zhou-ippm-enhanced-alternate-marking-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 : ---------------------------------------------------------------------------- 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 22, 2018) is 2013 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-04 == Outdated reference: A later version (-16) exists of draft-song-ippm-postcard-based-telemetry-00 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 H. Song 4 Intended status: Standards Track ZB. Li 5 Expires: April 25, 2019 Huawei 6 ZQ. Li 7 China Mobile 8 October 22, 2018 10 Enhanced Alternate Marking Method 11 draft-zhou-ippm-enhanced-alternate-marking-00 13 Abstract 15 This document proposes several ways to encapsulate the alternate 16 marking field with enough space. More information can be considered 17 within the alternate marking field to facilitate the efficiency and 18 ease the deployment. 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 April 25, 2019. 43 Copyright Notice 45 Copyright (c) 2018 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. Encapsulating Alternate Marking Field . . . . . . . . . . . . 3 62 2.1. Use the IOAM Data . . . . . . . . . . . . . . . . . . . . 3 63 2.2. Use the PostCard based Telemetry Header . . . . . . . . . 3 64 2.3. Encapsulate within the Transport Directly . . . . . . . . 3 65 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3.1. Encapsulate with the End to End IOAM . . . . . . . . . . 4 67 3.2. Encapsulate with the PostCard Base Telemetry . . . . . . 4 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 73 7.2. Informative References . . . . . . . . . . . . . . . . . 5 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 76 1. Introduction 78 The Alternate Marking [RFC8321] technique is an hybrid performance 79 measurement method, per [RFC7799] classification of measurement 80 methods. It can be used to measure packet loss, latency, and jitter 81 on live traffic. Because this method is based on marking consecutive 82 batches of packets. 84 For the basic Alternate Marking method, bits are needed to record the 85 mark. However, in some protocols, no additional bit can be used, 86 which blocks the wide deployment of the alternate marking technique. 87 And the basic Alternate Marking method is limited with the 88 scalability for further extension. 90 This document proposes several ways to encapsulate the alternate 91 marking field with enough space. More information can be considered 92 within the alternate marking field to facilitate the efficiency and 93 ease the deployment. 95 2. Encapsulating Alternate Marking Field 97 2.1. Use the IOAM Data 99 In-situ Operations, Administration, and Maintenance (IOAM 100 [I-D.ietf-ippm-ioam-data]) defines a generic meta data structure to 101 records OAM information within user packets while the packets 102 traverse a network. The data types and data formats for IOAM data 103 records have been defined in [I-D.ietf-ippm-ioam-data]. The IOAM 104 data can be embedded in many protocol encapsulations such as Network 105 Services Header, Segment Routing, and IPv6 106 [I-D.brockners-inband-oam-transport]. 108 The IOAM edge-to-edge option is to carry data that is added by the 109 IOAM encapsulating node and interpreted by IOAM decapsulating node. 110 It provide a bit map to indicate what is present in the data, so that 111 alternate marking filed can be included in the IOAM edge-to-edge 112 option. This provides a way for an end to end deployment for the 113 alternate marking method. 115 Since the IOAM edge-to-edge option data is not able to be interpreted 116 by the intermediate node, alternate marking method cannot be applied 117 within the path hop by hop with this encapsulation way. 119 2.2. Use the PostCard based Telemetry Header 121 The PostCard Base Telemetry (PBT) 122 [I-D.song-ippm-postcard-based-telemetry] is proposed to directly 123 exports the telemetry data to a collector through separated OAM 124 packets called postcards, while not require inserting telemetry data 125 into user packets. The alternate making data can also be 126 encapsulated in this option header. Different from the IOAM edge-to- 127 edge option, the PostCard based Telemetry facilitates the hop by hop 128 deployment of alternate marking method. 130 2.3. Encapsulate within the Transport Directly 132 In addition to the previous ways which carry the alternate marking 133 filed within the existing generic OAM header. The alternate marking 134 field can also be encapsulate within the transport protocol directly 135 as an extension header or so. This may vary according to the 136 transport protocol. 138 3. Examples 139 3.1. Encapsulate with the End to End IOAM 141 The IOAM-E2E-Type filed within the IOAM edge-to-edge option header is 142 a 16-bit identifier which specifies which data types are used in the 143 E2E option data. The IOAM-E2E-Type value is a bit field, in which 144 bit 0-3 are currently defined by [I-D.ietf-ippm-ioam-data]. So one 145 bit from bit 4-15 can be used to indicate the presence of data used 146 for alternate marking. 148 The alternate marking data is a 8-octet field defined as follows: 150 0 1 2 3 151 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 152 +-+-+---------------------------+-------------------------------+ 153 |L|D| Reserved | FlowID | 154 +-+-+---------------------------+-------------------------------+ 155 | FlowID(contd) | 156 +---------------------------------------------------------------+ 158 where: 160 o L - Loss flag; 162 o D - Delay flag; 164 o FlowID - 6-octet unsigned integer. Flow identifier field is to 165 uniquely identify a monitored flow within the in-situ OAM domain. 167 3.2. Encapsulate with the PostCard Base Telemetry 169 The following figures shows a proposed change to the Telemetry 170 Information Header (TIH) [I-D.song-ippm-postcard-based-telemetry]. 172 0 1 2 3 173 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 174 +---------------+---------------+-----------+-+-+---------------+ 175 | Next Header | TIH Length | Reserved |L|D| Hop Count | 176 +---------------+---------------+-----------+-+-+---------------+ 178 This proposes to use the two bits from the Reserved field from the 179 Telemetry Information Header. 181 Where: 183 o L - Loss flag; 185 o D - Delay flag. 187 The Data Element Bitmap defined in the TIH is an 31-bit bitmap 188 indicating the list of required data elements. One not used bit from 189 the Data Element Bitmap can be used to indicate the presence of the 190 marking bits, and trigger the statistic process. 192 4. Security Considerations 194 TBD 196 5. IANA Considerations 198 TBD 200 6. Acknowledgements 202 TBD 204 7. References 206 7.1. Normative References 208 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 209 Requirement Levels", BCP 14, RFC 2119, 210 DOI 10.17487/RFC2119, March 1997, 211 . 213 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 214 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 215 May 2016, . 217 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 218 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 219 "Alternate-Marking Method for Passive and Hybrid 220 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 221 January 2018, . 223 7.2. Informative References 225 [I-D.brockners-inband-oam-transport] 226 Brockners, F., Bhandari, S., Govindan, V., Pignataro, C., 227 Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes, 228 D., Lapukhov, P., and R. Chang, "Encapsulations for In- 229 situ OAM Data", draft-brockners-inband-oam-transport-05 230 (work in progress), July 2017. 232 [I-D.ietf-ippm-ioam-data] 233 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 234 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 235 P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, 236 "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- 237 data-04 (work in progress), October 2018. 239 [I-D.song-ippm-postcard-based-telemetry] 240 Song, H., Zhou, T., and Z. Li, "Export User Flow Telemetry 241 Data by Postcard Packets", draft-song-ippm-postcard-based- 242 telemetry-00 (work in progress), October 2018. 244 Authors' Addresses 246 Tianran Zhou 247 Huawei 248 156 Beiqing Rd. 249 Beijing 100095 250 China 252 Email: zhoutianran@huawei.com 254 Haoyu Song 255 Huawei 256 2330 Central Expressway 257 Santa Clara 258 United States of America 260 Email: haoyu.song@huawei.com 262 Zhenbin Li 263 Huawei 264 156 Beiqing Rd. 265 Beijing 100095 266 China 268 Email: lizhenbin@huawei.com 270 Zhenqiang Li 271 China Mobile 272 Beijing 273 China 275 Email: lizhenqiang@chinamobile.com