idnits 2.17.1 draft-fz-spring-srv6-alt-mark-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 date (January 19, 2021) is 1193 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 (-17) exists of draft-ietf-6man-ipv6-alt-mark-02 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-09 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) -- Obsolete informational reference (is this intentional?): RFC 8889 (Obsoleted by RFC 9342) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group G. Fioccola 3 Internet-Draft T. Zhou 4 Intended status: Standards Track Huawei 5 Expires: July 23, 2021 M. Cociglio 6 Telecom Italia 7 January 19, 2021 9 Segment Routing Header encapsulation for Alternate Marking Method 10 draft-fz-spring-srv6-alt-mark-00 12 Abstract 14 This document describes how the Alternate Marking Method can be used 15 as the passive performance measurement tool in an SRv6 network. It 16 defines how Alternate Marking data fields are transported as part of 17 the Segment Routing with IPv6 data plane (SRv6) header. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on July 23, 2021. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Application of the Alternate Marking to SRv6 . . . . . . . . 3 61 3. Definition of the SRH AltMark TLV . . . . . . . . . . . . . . 3 62 3.1. Data Fields Format . . . . . . . . . . . . . . . . . . . 4 63 4. Use of the SRH AltMark TLV . . . . . . . . . . . . . . . . . 5 64 5. Alternate Marking Method Operation . . . . . . . . . . . . . 6 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 70 9.2. Informative References . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 [RFC8321] and [RFC8889] describe a passive performance measurement 76 method, which can be used to measure packet loss, latency and jitter 77 on live traffic. Since this method is based on marking consecutive 78 batches of packets, the method is often referred as Alternate Marking 79 Method. 81 This document defines how the Alternate Marking Method ([RFC8321]) 82 can be used to measure packet loss and delay metrics for Segment 83 Routing with IPv6 data plane (SRv6). 85 [RFC8754] defines the Segment Routing Header (SRH) and how it is used 86 by nodes that are Segment Routing (SR) capable. 88 [I-D.fioccola-v6ops-ipv6-alt-mark] reported a summary on the possible 89 implementation options for the application of the Alternate Marking 90 Method in an IPv6 domain. [I-D.ietf-6man-ipv6-alt-mark] defines a 91 new TLV that can be encoded in the Option Headers (both Hop-by-hop or 92 Destination) for the purpose of the Alternate Marking Method 93 application in an IPv6 domain. 95 This document defines how Alternate Marking data is carried as SRH 96 TLV, that can be can be piggybacked in the packet and transported as 97 part of the SRH. The usage of SRH TLV is introduced in [RFC8754]. 99 2. Application of the Alternate Marking to SRv6 101 The Alternate Marking Method requires a marking field. A possibility 102 is already offered by [I-D.ietf-6man-ipv6-alt-mark] while the use of 103 a new TLV to be encoded in the SRH is defined in this document. 105 Since [I-D.ietf-6man-ipv6-alt-mark] defines the IPv6 Application of 106 the Alternate Marking Method through both Hop-by-Hop and Destination 107 Options Header, it is applicable also to SRv6 network. Indeed the 108 use of Destination Option Header carrying Alternate Marking bits 109 coupled with SRH allows to monitor every node along the SR path. 111 This document introduces the SRH TLV carrying Alternate Marking bits 112 and this can be a preferred approach in case of SRv6 network since it 113 does not rely on the use of Destination Option Header. 115 The optimization of both implementation and scaling of the Alternate 116 Marking Method is also considered and a way to identify flows is 117 required. The Flow Monitoring Identification field (FlowMonID), as 118 introduced in the next sections, goes in this direction and it is 119 used to identify a monitored flow. 121 Note that the FlowMonID is different from the Flow Label field of the 122 IPv6 Header ([RFC8200]). Flow Label is used for application service, 123 like load-balancing/equal cost multi-path (LB/ECMP) and QoS. 124 Instead, FlowMonID is only used to identify the monitored flow. The 125 reuse of flow label field for identifying monitored flows is not 126 considered since it may change the application intent and forwarding 127 behaviour. Furthermore the flow label may be changed en route and 128 this may also violate the measurement task. Those reasons make the 129 definition of the FlowMonID necessary for IPv6. Flow Label and 130 FlowMonID within the same packet have different scope, identify 131 different flows, and associate different uses. 133 An important point that will also be discussed in this document is 134 the the uniqueness of the FlowMonID and how to allow disambiguation 135 of the FlowMonID in case of collision. 137 3. Definition of the SRH AltMark TLV 139 The desired choice is to define a new TLV for the SRH extension 140 headers, carrying the data fields dedicated to the alternate marking 141 method. 143 This enables the Alternate Marking Method to take advantage of the 144 network programmability capability of SRv6 145 ([I-D.ietf-spring-srv6-network-programming]). Specifically, the 146 ability for an SRv6 endpoint to determine whether to process or 147 ignore some specific SRH TLVs is based on the SID function. The 148 nodes that are not capable of supporting the Alternate Marking 149 functionality do not have to look or process the SRH AltMark TLV and 150 can simply ignore it. This also enables collection of Alternate 151 Marking data only from the supporting segment endpoints. 153 3.1. Data Fields Format 155 The following figure shows the data fields format for enhanced 156 alternate marking TLV. This AltMark data is expected to be 157 encapsulated as SRH TLV. 159 0 1 2 3 160 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 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | SRH TLV Type | SRH TLV Len | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | FlowMonID |L|D| Reserved | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 where: 169 o SRH TLV Type: 8 bit identifier of the type of Option/TLV that 170 needs to be allocated. Unrecognised Types MUST be ignored on 171 receipt. 173 o SRH TLV Len: The length of the Data Fields of this TLV in bytes. 175 o FlowMonID: 20 bits unsigned integer. The FlowMon identifier is 176 described hereinafter. 178 o L: Loss flag as defined in [RFC8321] and 179 [I-D.ietf-6man-ipv6-alt-mark]; 181 o D: Delay flag as defined in [RFC8321] and 182 [I-D.ietf-6man-ipv6-alt-mark]; 184 o Reserved: is reserved for future use. These bits MUST be set to 185 zero on transmission and ignored on receipt. 187 The Flow Monitoring Identification (FlowMonID) is required for some 188 general reasons: 190 First, it helps to reduce the per node configuration. Otherwise, 191 each node needs to configure an access-control list (ACL) for each 192 of the monitored flows. Moreover, using a flow identifier allows 193 a flexible granularity for the flow definition. 195 Second, it simplifies the counters handling. Hardware processing 196 of flow tuples (and ACL matching) is challenging and often incurs 197 into performance issues, especially in tunnel interfaces. 199 Third, it eases the data export encapsulation and correlation for 200 the collectors. 202 The FlowMon identifier field is to uniquely identify a monitored flow 203 within the measurement domain. The field is set at the source node. 204 The FlowMonID can be uniformly assigned by the central controller or 205 algorithmically generated by the source node. The latter approach 206 cannot guarantee the uniqueness of FlowMonID but it may be preferred 207 for local or private network, where the conflict probability is small 208 due to the large FlowMonID space. 210 It is important to note that if the 20 bit FlowMonID is set 211 independently and pseudo randomly there is a chance of collision. 212 So, in some cases, FlowMonID could not be sufficient for uniqueness. 214 This issue is more visible when the FlowMonID is pseudo randomly 215 generated by the source node and there needs to tag it with 216 additional flow information to allow disambiguation. While, in case 217 of a centralized controller, the controller should set FlowMonID by 218 considering these aspects and instruct the nodes properly in order to 219 guarantee its uniqueness. 221 4. Use of the SRH AltMark TLV 223 SRv6 leverages the Segment Routing header which consists of a new 224 type of routing header. Like any other use case of IPv6, Hop-by-Hop 225 and Destination Options are useable when SRv6 header is present. 226 Because SRv6 is a routing header, destination options before the 227 routing header are processed by each destination in the route list. 229 SRH TLV can also be used to encode the AltMark Data Fields for SRv6 230 and to monitor every node along the SR path. For SRv6, it may be 231 preferred to use the SRH TLV, while for all the other cases with IPv6 232 data plane the use of the Hop-by-Hop and Destination Option to carry 233 AltMark data fields (as described in [I-D.ietf-6man-ipv6-alt-mark]) 234 is the best choice. 236 It is to be noted that the SR nodes implementing the Alternate 237 Marking functionality follows the MTU and other considerations 238 outlined in [I-D.voyer-6man-extension-header-insertion]. 239 Furthermore, in a SRv6 network, the intermediated nodes that are not 240 in the SID list do not consider the SRH, therefore they cannot 241 support and dig into the SRH TLV. 243 It is possible to summarize the procedure for AltMark data 244 encapsulation in SRv6 SRH: 246 * Ingress Node: As part of the SRH encapsulation, the ingress node 247 of an SR domain or an SR Policy 248 [I-D.ietf-spring-segment-routing-policy] MAY add the AltMark TLV 249 in the SRH of the data packet, if it supports AltMark 250 functionality and based on local configuration. 252 * Intermediate SR Node: The intermediate SR node is any node 253 receiving an IPv6 packet where the destination address of that 254 packet is a local SID. If an intermediate SR node is not capable 255 of processing AltMark TLV, it simply ignores it. While, if an 256 intermediate SR node is capable of processing AltMark TLV, it 257 checks if SRH AltMark TLV is present in the packet using 258 procedures defined in [RFC8754] and process it. 260 * Egress Node: The Egress node is the last node in the segment- 261 list of the SRH. The processing of AltMark TLV at the Egress node 262 is similar to the processing of AltMark TLV at the Intermediate SR 263 Nodes. 265 5. Alternate Marking Method Operation 267 [RFC8321], [RFC8889] describe the Alternate Marking Method in 268 general. While [I-D.ietf-6man-ipv6-alt-mark] describe in detail the 269 application and the Operation of the methodology for IPv6. 271 6. Security Considerations 273 The security considerations of SRv6 are discussed in [RFC8754] and 274 [I-D.ietf-spring-srv6-network-programming], and the security 275 considerations of Alternate Marking in general and its application to 276 IPv6 are discussed in [RFC8321] and [I-D.ietf-6man-ipv6-alt-mark]. 278 Alternate Marking is a feature applied to a "controlled domain", 279 where one or several operators decide on leveraging and configuring 280 Alternate Marking according to their needs. Additionally, operators 281 need to properly secure the Alternate Marking domain to avoid 282 malicious configuration and use, which could include injecting 283 malicious packets into a domain. 285 7. IANA Considerations 287 The SRH TLV Type should be assigned in IANA's Segment Routing Header 288 TLVs Registry. 290 This draft requests to allocate a SRH TLV Type for Alternate Marking 291 TLV data fields under registry name "Segment Routing Header TLVs" 292 requested by [RFC8754]. 294 SRH TLV Type Description Reference 295 ----------------------------------------------------------- 296 TBD AltMark Data Fields TLV This document 298 8. Acknowledgements 300 TBD 302 9. References 304 9.1. Normative References 306 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 307 Requirement Levels", BCP 14, RFC 2119, 308 DOI 10.17487/RFC2119, March 1997, 309 . 311 9.2. Informative References 313 [I-D.fioccola-v6ops-ipv6-alt-mark] 314 Fioccola, G., Velde, G., Cociglio, M., and P. Muley, "IPv6 315 Performance Measurement with Alternate Marking Method", 316 draft-fioccola-v6ops-ipv6-alt-mark-01 (work in progress), 317 June 2018. 319 [I-D.ietf-6man-ipv6-alt-mark] 320 Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. 321 Pang, "IPv6 Application of the Alternate Marking Method", 322 draft-ietf-6man-ipv6-alt-mark-02 (work in progress), 323 October 2020. 325 [I-D.ietf-spring-segment-routing-policy] 326 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 327 P. Mattes, "Segment Routing Policy Architecture", draft- 328 ietf-spring-segment-routing-policy-09 (work in progress), 329 November 2020. 331 [I-D.ietf-spring-srv6-network-programming] 332 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 333 Matsushima, S., and Z. Li, "SRv6 Network Programming", 334 draft-ietf-spring-srv6-network-programming-28 (work in 335 progress), December 2020. 337 [I-D.voyer-6man-extension-header-insertion] 338 Voyer, D., Filsfils, C., Dukes, D., Matsushima, S., Leddy, 339 J., Li, Z., and J. Guichard, "Deployments With Insertion 340 of IPv6 Segment Routing Headers", draft-voyer-6man- 341 extension-header-insertion-10 (work in progress), November 342 2020. 344 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 345 (IPv6) Specification", STD 86, RFC 8200, 346 DOI 10.17487/RFC8200, July 2017, 347 . 349 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 350 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 351 "Alternate-Marking Method for Passive and Hybrid 352 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 353 January 2018, . 355 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 356 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 357 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 358 . 360 [RFC8889] Fioccola, G., Ed., Cociglio, M., Sapio, A., and R. Sisto, 361 "Multipoint Alternate-Marking Method for Passive and 362 Hybrid Performance Monitoring", RFC 8889, 363 DOI 10.17487/RFC8889, August 2020, 364 . 366 Authors' Addresses 368 Giuseppe Fioccola 369 Huawei 370 Riesstrasse, 25 371 Munich 80992 372 Germany 374 Email: giuseppe.fioccola@huawei.com 375 Tianran Zhou 376 Huawei 377 156 Beiqing Rd. 378 Beijing 100095 379 China 381 Email: zhoutianran@huawei.com 383 Mauro Cociglio 384 Telecom Italia 385 Via Reiss Romoli, 274 386 Torino 10148 387 Italy 389 Email: mauro.cociglio@telecomitalia.it