idnits 2.17.00 (12 Aug 2021) /tmp/idnits17921/draft-fioccola-spring-flow-label-alt-mark-01.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 ([RFC6294]), 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 26, 2017) is 1661 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: draft-ietf-ippm-alt-mark has been published as RFC 8321 == Outdated reference: A later version (-10) exists of draft-voyer-6man-extension-header-insertion-01 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group G. Fioccola, Ed. 3 Internet-Draft Telecom Italia 4 Intended status: Standards Track G. Van de Velde, Ed. 5 Expires: April 29, 2018 Nokia 6 M. Cociglio 7 Telecom Italia 8 P. Muley 9 Nokia 10 October 26, 2017 12 Using the IPv6 Flow Label for Performance Measurement with Alternate 13 Marking Method in Segment Routing 14 draft-fioccola-spring-flow-label-alt-mark-01 16 Abstract 18 [RFC6294] makes a survey of Proposed Use Cases for the IPv6 Flow 19 Label. The IPv6 protocol includes a flow label in every packet 20 header, but this field is, according to [RFC6294], not used in 21 practice. This document describes how the alternate marking method 22 can be used as the passive performance measurement method in a IPv6 23 domain. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 29, 2018. 48 Copyright Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. IPv6 Flow Labels and Alternate Marking . . . . . . . . . . . 3 67 2.1. IPv6 Tunnel . . . . . . . . . . . . . . . . . . . . . . . 3 68 2.2. SRv6 Policy . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Alternate Marking Method Operation . . . . . . . . . . . . . 4 70 3.1. Single Mark Measurement . . . . . . . . . . . . . . . . . 5 71 3.2. Double Mark Measurement . . . . . . . . . . . . . . . . . 5 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 73 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 77 7.2. Informative References . . . . . . . . . . . . . . . . . 6 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 80 1. Introduction 82 The IPv6 Header Format defined in [RFC2460] introduces the 83 availability of an 20-bit flow label in the base IPv6 Header. 85 The flow label is an immutable field recommended to contain a pseudo- 86 random value [RFC6437]. However, in most packets it has the default 87 value of zero, although some TCP/IP stacks do set it according to 88 [RFC6437]. 90 [RFC6436] and [RFC6437] open the door for IPv6 Flow Label to be used 91 in controlled environment, e.g. for IPv6 tunnelled packets or SRv6 92 policies (see following Sections for more details). For example 93 [RFC6438] describes the use of the IPv6 Flow Label field for load 94 distribution purpose, especially across Equal Cost Multi-Path (ECMP) 95 and/or Link Aggregation Group (LAG) paths. 97 But, a specific goal presented in [RFC6437] is to enable and 98 encourage the use of the flow label. In fact it is important to 99 underline two aspects from this specification: 101 o It encourages non-zero flow label values to be used and clearly 102 defines how to set a non-zero value. 104 o It retains the rule that the flow label must not be changed en 105 route but allows routers to set the label on behalf of hosts that 106 do not do so. 108 Based on these considerations, it is allowed to use the flow label 109 field in a managed domain, assuming when a packet leaves the domain, 110 the original flow label value MUST be restored. 112 [I-D.ietf-ippm-alt-mark] describes passive performance measurement 113 method, which can be used to measure packet loss, latency and jitter 114 on live traffic. Because this method is based on marking consecutive 115 batches of packets the method often referred as Alternate Marking 116 Method. 118 This document defines how the alternate marking method can be used to 119 measure packet loss and delay metrics of IPv6 tunneled packets or 120 SRv6 policies. 122 2. IPv6 Flow Labels and Alternate Marking 124 The application of the Alternate Marking method in a managed and 125 controlled domain is realised with two fundamental assumptions: 127 o The original flow-label reconstructed when leaving SP controlled 128 domain. 130 o The usage of IPv6 tunnels (IPv6inIPv6, IPSec, IPv6 UDP, etc..) or 131 SRv6 policies. 133 2.1. IPv6 Tunnel 135 The ingress router is the "source" of the IPv6 tunnel and impose the 136 OUTER IPv6 header, so Ingress router can control the Flow-label of 137 OUTER IPv6 header. The Egress router removes OUTER IPv6 header, 138 restoring ORIGINAL payload and payload headers (IPv6, IPv4, L2 139 traffic, MBH, etc...). 141 2.2. SRv6 Policy 143 When IPv6 SRv6 Encapsulation is used, the outer SRv6 header uses 2 144 bits (Mark Field) from 20 bit flow-label field. Outer SRv6 header 145 will be removed when exiting the SP domain and the original Flow- 146 label is restored at egress. 148 As described in [I-D.voyer-6man-extension-header-insertion], when 149 IPv6 SRv6 EH insertion is used, there is the insertion of IPv6 150 Extension Headers. However in [RFC8200] it was ruled against 151 insertion of EHs and it is recommended that Extension Headers are not 152 processed, inserted, or deleted by any node along the path, until the 153 packet from source node reaches the destination node. 155 3. Alternate Marking Method Operation 157 The Figure 1 displays format of the Mark field (2 bits from 20 bit 158 IPv6 flow-label field). 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Flow Label | MF| 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 Mark Field (MF) is: 166 0 167 0 1 168 +-+-+-+-+ 169 | S | D | 170 +-+-+-+-+ 172 Figure 1: Mark field format 174 where: 176 o S - Single mark method; 178 o D - Double mark method. 180 The use of the other 18 bits is not specified in this document 181 because is out of scope here. But it should follow [RFC6437]. If 182 the domain is using flow-label based load balancing, ECMP or LAG 183 internally, there are two possibilities. The methodology SHOULD be 184 used within a controlled domain where the load-balancing based on 185 flow label is disabled. Otherwise, the network element MUST mask the 186 Mark Field (MF), so it will not change hashing calculation for the 187 same flow because only 18 bits + 2 zeros are used for the entropy. 189 3.1. Single Mark Measurement 191 As explained in the [I-D.ietf-ippm-alt-mark], marking can be applied 192 to delineate blocks of packets based either on equal number of 193 packets in a block or based on equal time interval. The latter 194 method offers better control as it allows better account for 195 capabilities of downstream nodes to report statistics related to 196 batches of packets and, at the same time, time resolution that 197 affects defect detection interval. 199 If the Single Mark measurement used, then the D flag MUST be set to 200 zero on transmit and ignored by monitoring point. 202 The S flag is used to create alternate flows to measure the packet 203 loss by switching value of the S flag. Delay metrics MAY be 204 calculated with the alternate flow using any of the following 205 methods: 207 o First/Last Batch Packet Delay calculation: timestamps are 208 collected based on order of arrival so this method is sensitive to 209 packet loss and re-ordering. 211 o Average Packet Delay calculation: an average delay is calculated 212 by considering the average arrival time of the packets within a 213 single block. This method only provides single metric for the 214 duration of the block and it doesn't give information about the 215 delay distribution. 217 3.2. Double Mark Measurement 219 Double Mark method allows more detailed measurement of delays for the 220 monitored flow but it requires more nodal and network resources. If 221 the Double Mark method used, then the S flag MUST be used to create 222 the alternate flow. The D flag MUST be used to mark single packets 223 to measure delay jitter. 225 The first marking (S flag alternation) is needed for packet loss and 226 also for average delay measurement. The second marking (D flag is 227 put to one) creates a new set of marked packets that are fully 228 identified and dedicated for delay. This method is useful to have 229 not only the average delay but also to know more about the statistic 230 distribution of delay values. 232 4. Security Considerations 234 tbc 236 5. Acknowledgements 238 tbc 240 6. IANA Considerations 242 7. References 244 7.1. Normative References 246 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 247 Requirement Levels", BCP 14, RFC 2119, 248 DOI 10.17487/RFC2119, March 1997, 249 . 251 7.2. Informative References 253 [I-D.ietf-ippm-alt-mark] 254 Fioccola, G., Capello, A., Cociglio, M., Castaldelli, L., 255 Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 256 "Alternate Marking method for passive and hybrid 257 performance monitoring", draft-ietf-ippm-alt-mark-13 (work 258 in progress), October 2017. 260 [I-D.voyer-6man-extension-header-insertion] 261 daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., 262 Leddy, J., Filsfils, C., Previdi, S., Salsano, S., 263 Cianfrani, A., Lebrun, D., Bonaventure, O., Jonnalagadda, 264 P., Sharif, M., Elmalky, H., Abdelsalam, A., Raszuk, R., 265 Ayyangar, A., Steinberg, D., and W. Henderickx, "Insertion 266 of IPv6 Segment Routing Headers in a Controlled Domain", 267 draft-voyer-6man-extension-header-insertion-01 (work in 268 progress), September 2017. 270 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 271 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 272 December 1998, . 274 [RFC6294] Hu, Q. and B. Carpenter, "Survey of Proposed Use Cases for 275 the IPv6 Flow Label", RFC 6294, DOI 10.17487/RFC6294, June 276 2011, . 278 [RFC6436] Amante, S., Carpenter, B., and S. Jiang, "Rationale for 279 Update to the IPv6 Flow Label Specification", RFC 6436, 280 DOI 10.17487/RFC6436, November 2011, 281 . 283 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 284 "IPv6 Flow Label Specification", RFC 6437, 285 DOI 10.17487/RFC6437, November 2011, 286 . 288 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 289 for Equal Cost Multipath Routing and Link Aggregation in 290 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 291 . 293 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 294 (IPv6) Specification", STD 86, RFC 8200, 295 DOI 10.17487/RFC8200, July 2017, 296 . 298 Authors' Addresses 300 Giuseppe Fioccola (editor) 301 Telecom Italia 302 Torino 303 Italy 305 Email: giuseppe.fioccola@telecomitalia.it 307 Gunter Van de Velde (editor) 308 Nokia 309 Antwerp 310 BE 312 Email: gunter.van_de_velde@nokia.com 314 Mauro Cociglio 315 Telecom Italia 316 Torino 317 Italy 319 Email: mauro.cociglio@telecomitalia.it 320 Praveen Muley 321 Nokia 322 Mountain View 323 USA 325 Email: praveen.muley@nokia.com