idnits 2.17.1 draft-fmm-nvo3-pm-alt-mark-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-nvo3-encap]), 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 (October 23, 2018) is 2010 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 (-12) exists of draft-ietf-nvo3-encap-02 ** Downref: Normative reference to an Informational draft: draft-ietf-nvo3-encap (ref. 'I-D.ietf-nvo3-encap') == Outdated reference: A later version (-16) exists of draft-ietf-nvo3-geneve-08 == Outdated reference: A later version (-13) exists of draft-ietf-nvo3-vxlan-gpe-06 ** Downref: Normative reference to an Informational draft: draft-ietf-nvo3-vxlan-gpe (ref. 'I-D.ietf-nvo3-vxlan-gpe') == Outdated reference: A later version (-05) exists of draft-mizrahi-ippm-compact-alternate-marking-03 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NVO3 Working Group G. Fioccola 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track G. Mirsky 5 Expires: April 26, 2019 ZTE Corp. 6 T. Mizrahi 7 Huawei Network.IO Innovation Lab 8 October 23, 2018 10 Performance Measurement (PM) with Alternate Marking in Network 11 Virtualization Overlays (NVO3) 12 draft-fmm-nvo3-pm-alt-mark-03 14 Abstract 16 This document describes how the alternate marking method can be used 17 for performance measurement method in a Network Virtualization 18 Overlays (NVO3) Domain. The description aims to be general for NVO3 19 encapsulations, but is focused to Geneve, recommended by the NVO3 20 design team [I-D.ietf-nvo3-encap]. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 26, 2019. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions used in this document . . . . . . . . . . . . . . 2 58 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 3. OAM Performance Measurement in a NVO3 Domain . . . . . . . . 3 61 4. The Mark Field in the NVO3 Header . . . . . . . . . . . . . . 5 62 5. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 6 63 5.1. Single Mark Enabled Measurement . . . . . . . . . . . . . 6 64 5.2. Double Mark Enabled Measurement . . . . . . . . . . . . . 7 65 5.3. Multiplexed Mark Enabled Measurement . . . . . . . . . . 8 66 6. Multipoint Measurement Considerations . . . . . . . . . . . . 8 67 7. The Mark Field in Geneve . . . . . . . . . . . . . . . . . . 8 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 8.1. Mark Field in Geneve Header . . . . . . . . . . . . . . . 9 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 11.2. Informative References . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. Introduction 79 [RFC7365] provides a framework for Data Center (DC) Network 80 Virtualization over Layer 3 (NVO3) tunnels. It is intended to aid in 81 standardizing protocols and mechanisms to support large-scale network 82 virtualization for data centers. 84 [RFC8321] describes a performance measurement method, which can be 85 used to measure packet loss, latency, and jitter on live traffic. 86 Since this method is based on marking consecutive batches of packets 87 the method often referred to as the Alternate Marking Method (AMM). 89 This document defines how the alternate marking method can be used to 90 measure packet loss and delay metrics of an NVO3 Domain. 92 2. Conventions used in this document 93 2.1. Terminology 95 AMM: Alternate Marking Method 97 OAM: Operations, Administration and Maintenance 99 NVO3: Network Virtualization Overlays 101 NVE: Network Virtualization Edge 103 VNI: Virtual Network Instance 105 DC: Data Center 107 NVA: Network Virtualization Authority 109 Geneve: Generic Network Virtualization Encapsulation 111 VXLAN: Virtual Extensible LAN 113 GUE: Generic UDP Encapsulation 115 2.2. Requirements Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in BCP 120 14 [RFC2119] [RFC8174] when, and only when, they appear in all 121 capitals, as shown here. 123 3. OAM Performance Measurement in a NVO3 Domain 125 Figure 1 shows the generic reference model for a DC network 126 virtualization over an L3 infrastructure while Figure 2 shows the 127 generic reference model for the Network Virtualization Edge (NVE). 128 Both Figures are taken from [RFC7365] and [RFC8014]. 130 +--------+ +--------+ 131 | Tenant +--+ +----| Tenant | 132 | System | | (') | System | 133 +--------+ | ................. ( ) +--------+ 134 | +---+ +---+ (_) 135 +--|NVE|---+ +---|NVE|-----+ 136 +---+ | | +---+ 137 / . +-----+ . 138 / . +--| NVA |--+ . 139 / . | +-----+ \ . 140 | . | \ . 141 | . | Overlay +--+--++--------+ 142 +--------+ | . | Network | NVE || Tenant | 143 | Tenant +--+ . | | || System | 144 | System | . \ +---+ +--+--++--------+ 145 +--------+ .....|NVE|......... 146 +---+ 147 | 148 | 149 ===================== 150 | | 151 +--------+ +--------+ 152 | Tenant | | Tenant | 153 | System | | System | 154 +--------+ +--------+ 156 Figure 1: Generic Reference Model for DC Network Virtualization 157 Overlays (RFC7365) 159 +-------- L3 Network -------+ 160 | | 161 | Tunnel Overlay | 162 +------------+---------+ +---------+------------+ 163 | +----------+-------+ | | +---------+--------+ | 164 | | Overlay Module | | | | Overlay Module | | 165 | +---------+--------+ | | +---------+--------+ | 166 | |VN Context| | VN Context| | 167 | | | | | | 168 | +--------+-------+ | | +--------+-------+ | 169 | | |VNI| . |VNI| | | | |VNI| . |VNI| | 170 NVE1 | +-+------------+-+ | | +-+-----------+--+ | NVE2 171 | | VAPs | | | | VAPs | | 172 +----+------------+----+ +----+-----------+-----+ 173 | | | | 174 | | | | 175 Tenant Systems Tenant Systems 177 Figure 2: Generic NVE Reference Model (RFC7365) 179 L3 networks provide transport for an emulated Layer 2 created by NVE 180 devices. The connectivity between the NVE devices is achieved with 181 unicast and multicast tunneling methods. Then, the NVE devices 182 present an emulated Layer 2 network to the Tenant End Systems at a 183 Virtual Network Instance (VNI) through Virtual Access Points (VAPs). 184 The NVE devices map Layer 2 unicast to Layer 3 unicast point-to-point 185 tunnels and may either map Layer 2 multicast to Layer 3 multicast 186 tunnels or may replicate packets onto multiple Layer 3 unicast 187 tunnels. 189 The emulated Layer 2 network is provided by the NVE devices to which 190 the Tenant End Systems are connected. This network of NVE can be 191 operated by a single service provider or can span across multiple 192 administrative domains. Likewise, the L3 Overlay Network can be 193 operated by a single service provider or span across multiple 194 administrative domains. 196 Each of the layers is responsible for its own OAM. Complex OAM 197 relationships exist as a result of the hierarchical layering, but 198 this is out of scope here. 200 When we refer to an OAM domain considered in this document we refer 201 to a set of NVEs and the tunnels which interconnect them. 203 It is commonly agreed that NVO3 OAM Performance Management supports 204 measurements (packet loss, latency, and jitter) per VNI between two 205 NVE devices that support the same VNI within a given NVO3 domain. 207 4. The Mark Field in the NVO3 Header 209 This document defines a two-bit long field, referred to as Mark field 210 (M), as part of the NVO3 Header and designated for the alternate 211 marking performance measurement method [RFC8321]. The Mark field 212 MUST NOT be used in defining forwarding and/or quality of service 213 treatment of an NVO3 packet. The Mark field MUST be used only for 214 the performance measurement of data traffic in the NVO3 layer. Since 215 the field does not affect forwarding and/or quality of service 216 treatment of packets, the alternate marking method in the NVO3 layer 217 can be viewed as nearly-passive performance measurement method. 219 Figure 3 displays the format of the Mark field. 221 0 222 0 1 223 +-+-+-+-+ 224 | L | D | 225 +-+-+-+-+ 227 Figure 3: Mark field (M) format 229 where: 231 o L - Loss bit; 233 o D - Delay bit. 235 5. Theory of Operation 237 The marking method can be used in NVO3. For example, one can 238 consider the NVO3 reference model presented in Figure 1. AMM can be 239 applied at either ingress or egress NVE to detect performance 240 degradation defect and localize it efficiently. 242 Using AMM, NVE1 creates distinct sub-flows. Each sub-flow consists 243 of consecutive blocks that are unambiguously recognizable by a 244 monitoring point at any component of the NVO3, e.g. NVE2 or NVE3, 245 and can be measured to calculate packet loss and/or packet delay 246 metrics. 248 Every NVO3 Header [I-D.ietf-nvo3-geneve], [I-D.ietf-nvo3-vxlan-gpe] 249 and [I-D.ietf-nvo3-gue] can be considered for the application of AMM. 251 5.1. Single Mark Enabled Measurement 253 As explained in the [RFC8321], marking can be applied to delineate 254 blocks of packets based either on the equal number of packets in a 255 block or based on equal time interval. The latter method offers 256 better control as it allows better account for capabilities of 257 downstream nodes to report statistics related to batches of packets 258 and, at the same time, time resolution that affects defect detection 259 interval. 261 If the Single Mark measurement used, then the D flag MUST be set to 262 zero on transmit and ignored by monitoring point. 264 The L flag is used to create alternate flows to measure the packet 265 loss by switching the value of the L flag every N-th packet or at 266 certain time intervals. Delay metrics MAY be calculated with the 267 alternate flow using any of the following methods: 269 o First/Last Packet Delay calculation: whenever the marking, i.e. 270 the value of L flag, changes a component of the NVO3 can store the 271 timestamp of the first/last packet of the block. The timestamp 272 can be compared with the timestamp of the packet that arrived in 273 the same order through a monitoring point at a downstream 274 component of the NVO3 to compute packet delay. Because timestamps 275 collected based on order of arrival this method is sensitive to 276 packet loss and re-ordering of packets 278 o Average Packet Delay calculation: an average delay is calculated 279 by considering the average arrival time of the packets within a 280 single block. A component of the NVO3 may collect timestamps for 281 each packet received within a single block. Average of the 282 timestamp is the sum of all the timestamps divided by the total 283 number of packets received. Then the difference between averages 284 calculated at two monitoring points is the average packet delay on 285 that segment. This method is robust to out of order packets and 286 also to packet loss (only a small error is introduced). This 287 method only provides a single metric for the duration of the block 288 and it doesn't give the minimum and maximum delay values. This 289 limitation could be overcome by reducing the duration of the block 290 by means of a highly optimized implementation of the method. 292 5.2. Double Mark Enabled Measurement 294 Double Mark method allows measurement of minimum and maximum delays 295 for the monitored flow but it requires more nodal and network 296 resources. If the Double Mark method used, then the L flag MUST be 297 used to create the alternate flow, i.e. mark larger batches of 298 packets. The D flag MUST be used to mark single packets to measure 299 delay jitter. 301 The first marking (L flag alternation) is needed for packet loss and 302 also for average delay measurement. The second marking (D flag is 303 put to one) creates a new set of marked packets that are fully 304 identified over NVO3, so that a component can store the timestamps of 305 these packets; these timestamps can be compared with the timestamps 306 of the same packets on another component of the NVO3 to compute 307 packet delay values for each packet. The number of measurements can 308 be easily increased by changing the frequency of the second marking. 309 But the frequency of the second marking must be not too high in order 310 to avoid out of order issues. This method is suitable to have not 311 only the average delay but also the minimum and maximum delay values 312 and, in wider terms, to know more about the statistic distribution of 313 delay values. 315 5.3. Multiplexed Mark Enabled Measurement 317 There is also a scheme that provides the benefits of Double Mark 318 method, but uses only one bit like Single Mark. This methodology is 319 described in [I-D.mizrahi-ippm-compact-alternate-marking]. The 320 concept is that in the middle of each block of packets with a certain 321 value of the L flag, a single packet has the L flag inverted. So, by 322 examining the stream, the packets with the inverted bit can be easily 323 identified and employed for delay measurement. This Alternate 324 Marking variation is advantageous because it requires only one bit 325 from each packet, and such bits are always in short supply. 327 6. Multipoint Measurement Considerations 329 The Multipoint characteristics of the traffic within a given NVO3 330 Domain could be considered a valuable Use Case of 331 [I-D.fioccola-ippm-multipoint-alt-mark]. 333 7. The Mark Field in Geneve 335 [I-D.ietf-nvo3-geneve] defines the format of the Geneve Header. 337 The design team recommendations in [I-D.ietf-nvo3-encap] section 7 338 concluded that Geneve is most suitable as a starting point for the 339 proposed standard for network virtualization. 341 In addition, the design team recommended addressing requirements for 342 OAM considerations for alternate marking and for performance 343 measurements that need 2 bits in the header. This document clarifies 344 the need for the current OAM bit in the Geneve Header. 346 Geneve Header: 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 |Ver| Opt Len |O|C| M | Rsvd. | Protocol Type | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Virtual Network Identifier (VNI) | Reserved | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Variable Length Options | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 Figure 4: Geneve Header 357 This document defines a two-bit long field, referred to as the Mark 358 field (M in Figure 4, as part of Geneve and designated for the 359 alternate marking performance measurement method [RFC8321]. The Mark 360 field MUST NOT be used in defining forwarding and/or quality of 361 service treatment of a NVO3 packet. The Mark field MUST be used only 362 for the performance measurement of data traffic in the NVO3 layer. 364 Since the field does not affect forwarding and/or quality of service 365 treatment of packets, the alternate marking method in the NVO3 layer 366 can be viewed as nearly-passive performance measurement method. 368 8. IANA Considerations 370 8.1. Mark Field in Geneve Header 372 This document requests IANA to allocate Mark field as two bits-long 373 field from Geneve Header Reserved Bits [I-D.ietf-nvo3-geneve]. 375 This document requests IANA to register values of the Mark field of 376 Geneve as the following: 378 +--------------+---------+--------------------------+---------------+ 379 | Bit Position | Marking | Description | Reference | 380 +--------------+---------+--------------------------+---------------+ 381 | 0 | L | Single Mark Measurement | This document | 382 | 1 | D | Double Mark Measurement | This document | 383 +--------------+---------+--------------------------+---------------+ 385 Table 1: Mark field of Geneve 387 9. Security Considerations 389 This document lists the OAM requirement for the NVO3 domain and does 390 not raise any security concerns or issues in addition to ones common 391 to networking and NVO3. 393 10. Acknowledgement 395 The authors would like to thank Dale R. Worley for the contribution. 397 11. References 399 11.1. Normative References 401 [I-D.ietf-nvo3-encap] 402 Boutros, S., "NVO3 Encapsulation Considerations", draft- 403 ietf-nvo3-encap-02 (work in progress), September 2018. 405 [I-D.ietf-nvo3-geneve] 406 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 407 Network Virtualization Encapsulation", draft-ietf- 408 nvo3-geneve-08 (work in progress), October 2018. 410 [I-D.ietf-nvo3-gue] 411 Herbert, T., Yong, L., and O. Zia, "Generic UDP 412 Encapsulation", draft-ietf-nvo3-gue-05 (work in progress), 413 October 2016. 415 [I-D.ietf-nvo3-vxlan-gpe] 416 Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol 417 Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-06 (work 418 in progress), April 2018. 420 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 421 Requirement Levels", BCP 14, RFC 2119, 422 DOI 10.17487/RFC2119, March 1997, 423 . 425 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 426 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 427 May 2017, . 429 11.2. Informative References 431 [I-D.fioccola-ippm-multipoint-alt-mark] 432 Fioccola, G., Cociglio, M., Sapio, A., and R. Sisto, 433 "Multipoint Alternate Marking method for passive and 434 hybrid performance monitoring", draft-fioccola-ippm- 435 multipoint-alt-mark-04 (work in progress), June 2018. 437 [I-D.mizrahi-ippm-compact-alternate-marking] 438 Mizrahi, T., Arad, C., Fioccola, G., Cociglio, M., Chen, 439 M., Zheng, L., and G. Mirsky, "Compact Alternate Marking 440 Methods for Passive and Hybrid Performance Monitoring", 441 draft-mizrahi-ippm-compact-alternate-marking-03 (work in 442 progress), October 2018. 444 [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. 445 Rekhter, "Framework for Data Center (DC) Network 446 Virtualization", RFC 7365, DOI 10.17487/RFC7365, October 447 2014, . 449 [RFC8014] Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. 450 Narten, "An Architecture for Data-Center Network 451 Virtualization over Layer 3 (NVO3)", RFC 8014, 452 DOI 10.17487/RFC8014, December 2016, 453 . 455 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 456 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 457 "Alternate-Marking Method for Passive and Hybrid 458 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 459 January 2018, . 461 Authors' Addresses 463 Giuseppe Fioccola 464 Huawei Technologies 465 Riesstrasse, 25 466 Munich 80992 467 Germany 469 Email: giuseppe.fioccola@huawei.com 471 Greg Mirsky 472 ZTE Corp. 474 Email: gregimirsky@gmail.com 476 Tal Mizrahi 477 Huawei Network.IO Innovation Lab 478 Israel 480 Email: tal.mizrahi.phd@gmail.com