idnits 2.17.1 draft-fz-spring-srv6-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 : ---------------------------------------------------------------------------- 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 9, 2021) is 1021 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-04 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-11 -- 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: January 10, 2022 M. Cociglio 6 Telecom Italia 7 July 9, 2021 9 Segment Routing Header encapsulation for Alternate Marking Method 10 draft-fz-spring-srv6-alt-mark-01 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 January 10, 2022. 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 2.1. Controlled Domain . . . . . . . . . . . . . . . . . . . . 4 62 3. Definition of the SRH AltMark TLV . . . . . . . . . . . . . . 4 63 3.1. Data Fields Format . . . . . . . . . . . . . . . . . . . 4 64 4. Use of the SRH AltMark TLV . . . . . . . . . . . . . . . . . 6 65 5. Alternate Marking Method Operation . . . . . . . . . . . . . 7 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 71 9.2. Informative References . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 [RFC8321] and [RFC8889] describe a passive performance measurement 77 method, which can be used to measure packet loss, latency and jitter 78 on live traffic. Since this method is based on marking consecutive 79 batches of packets, the method is often referred as Alternate Marking 80 Method. 82 This document defines how the Alternate Marking Method ([RFC8321]) 83 can be used to measure packet loss and delay metrics for Segment 84 Routing with IPv6 data plane (SRv6). 86 [RFC8754] defines the Segment Routing Header (SRH) and how it is used 87 by nodes that are Segment Routing (SR) capable. 89 [I-D.fioccola-v6ops-ipv6-alt-mark] reported a summary on the possible 90 implementation options for the application of the Alternate Marking 91 Method in an IPv6 domain. [I-D.ietf-6man-ipv6-alt-mark] defines a 92 new TLV that can be encoded in the Option Headers (both Hop-by-hop or 93 Destination) for the purpose of the Alternate Marking Method 94 application in an IPv6 domain. 96 This document defines how Alternate Marking data is carried as SRH 97 TLV, that can be can be piggybacked in the packet and transported as 98 part of the SRH. The usage of SRH TLV is introduced in [RFC8754]. 100 2. Application of the Alternate Marking to SRv6 102 The Alternate Marking Method requires a marking field. A possibility 103 is already offered by [I-D.ietf-6man-ipv6-alt-mark] while the use of 104 a new TLV to be encoded in the SRH is defined in this document. 106 Since [I-D.ietf-6man-ipv6-alt-mark] defines the IPv6 Application of 107 the Alternate Marking Method through both Hop-by-Hop and Destination 108 Options Header, it is applicable also to SRv6 network. Indeed the 109 use of Destination Option Header carrying Alternate Marking bits 110 coupled with SRH allows to monitor every node along the SR path. 112 This document introduces the SRH TLV carrying Alternate Marking bits 113 and this can be a preferred approach in case of SRv6 network since it 114 does not rely on the use of Destination Option Header. 116 The optimization of both implementation and scaling of the Alternate 117 Marking Method is also considered and a way to identify flows is 118 required. The Flow Monitoring Identification field (FlowMonID), as 119 introduced in the next sections, goes in this direction and it is 120 used to identify a monitored flow. 122 Note that the FlowMonID is different from the Flow Label field of the 123 IPv6 Header ([RFC8200]). Flow Label is used for application service, 124 like load-balancing/equal cost multi-path (LB/ECMP) and QoS. 125 Instead, FlowMonID is only used to identify the monitored flow. The 126 reuse of flow label field for identifying monitored flows is not 127 considered since it may change the application intent and forwarding 128 behaviour. Furthermore the flow label may be changed en route and 129 this may also violate the measurement task. Those reasons make the 130 definition of the FlowMonID necessary for IPv6. Flow Label and 131 FlowMonID within the same packet have different scope, identify 132 different flows, and associate different uses. 134 An important point that will also be discussed in this document is 135 the the uniqueness of the FlowMonID and how to allow disambiguation 136 of the FlowMonID in case of collision. 138 The following section highlights an important requirement for the 139 application of the Alternate Marking to IPv6 and SRv6. The concept 140 of the controlled domain is explained and it is considered an 141 essential precondition. 143 2.1. Controlled Domain 145 [RFC8799] introduces the concept of specific limited domain solutions 146 and, in this regard, it is reported the Application of the Alternate 147 Marking Method as an example. 149 IPv6 has much more flexibility than IPv4 and innovative applications 150 have been proposed, but for a number of reasons, such as the 151 policies, options supported, the style of network management and 152 security requirements, it is suggested to limit some of these 153 applications to a controlled domain. This is also the case of the 154 Alternate Marking application to SRv6 as assumed hereinafter. 156 Therefore, the application of the Alternate Marking Method to SRv6 157 MUST NOT be deployed outside a controlled domain. It is RECOMMENDED 158 that an implementation can be able to reject packets that carry 159 Alternate Marking data and are entering or leaving the controlled 160 domains. 162 3. Definition of the SRH AltMark TLV 164 A new TLV carrying the data fields dedicated to the alternate marking 165 method can be defined for the SRH extension headers. 167 This enables the Alternate Marking Method to take advantage of the 168 network programmability capability of SRv6 169 ([I-D.ietf-spring-srv6-network-programming]). Specifically, the 170 ability for an SRv6 endpoint to determine whether to process or 171 ignore some specific SRH TLVs is based on the SID function. The 172 nodes that are not capable of supporting the Alternate Marking 173 functionality do not have to look or process the SRH AltMark TLV and 174 can simply ignore it. This also enables collection of Alternate 175 Marking data only from the supporting segment endpoints. 177 3.1. Data Fields Format 179 The following figure shows the data fields format for enhanced 180 alternate marking TLV. This AltMark data is expected to be 181 encapsulated as SRH TLV. 183 0 1 2 3 184 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 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | SRH TLV Type | SRH TLV Len | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | FlowMonID |L|D| Reserved | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 where: 192 o SRH TLV Type: 8 bit identifier of the type of Option/TLV that 193 needs to be allocated. Unrecognised Types MUST be ignored on 194 receipt. 196 o SRH TLV Len: The length of the Data Fields of this TLV in bytes. 198 o FlowMonID: 20 bits unsigned integer. The FlowMon identifier is 199 described hereinafter. 201 o L: Loss flag as defined in [RFC8321] and 202 [I-D.ietf-6man-ipv6-alt-mark]; 204 o D: Delay flag as defined in [RFC8321] and 205 [I-D.ietf-6man-ipv6-alt-mark]; 207 o Reserved: is reserved for future use. These bits MUST be set to 208 zero on transmission and ignored on receipt. 210 The Flow Monitoring Identification (FlowMonID) is required for some 211 general reasons: 213 First, it helps to reduce the per node configuration. Otherwise, 214 each node needs to configure an access-control list (ACL) for each 215 of the monitored flows. Moreover, using a flow identifier allows 216 a flexible granularity for the flow definition. 218 Second, it simplifies the counters handling. Hardware processing 219 of flow tuples (and ACL matching) is challenging and often incurs 220 into performance issues, especially in tunnel interfaces. 222 Third, it eases the data export encapsulation and correlation for 223 the collectors. 225 The FlowMon identifier field is to uniquely identify a monitored flow 226 within the measurement domain. The field is set at the source node. 227 The FlowMonID can be uniformly assigned by the central controller or 228 algorithmically generated by the source node. The latter approach 229 cannot guarantee the uniqueness of FlowMonID but it may be preferred 230 for local or private network, where the conflict probability is small 231 due to the large FlowMonID space. 233 It is important to note that if the 20 bit FlowMonID is set 234 independently and pseudo randomly there is a chance of collision. 235 So, in some cases, FlowMonID could not be sufficient for uniqueness. 237 This issue is more visible when the FlowMonID is pseudo randomly 238 generated by the source node and there needs to tag it with 239 additional flow information to allow disambiguation. While, in case 240 of a centralized controller, the controller should set FlowMonID by 241 considering these aspects and instruct the nodes properly in order to 242 guarantee its uniqueness. 244 4. Use of the SRH AltMark TLV 246 SRv6 leverages the Segment Routing header which consists of a new 247 type of routing header. Like any other use case of IPv6, Hop-by-Hop 248 and Destination Options are useable when SRv6 header is present. 249 Because SRv6 is a routing header, destination options before the 250 routing header are processed by each destination in the route list. 252 SRH TLV can also be used to encode the AltMark Data Fields for SRv6 253 and to monitor every node along the SR path. For SRv6, it may be 254 preferred to use the SRH TLV, while for all the other cases with IPv6 255 data plane the use of the Hop-by-Hop and Destination Option to carry 256 AltMark data fields (as described in [I-D.ietf-6man-ipv6-alt-mark]) 257 is the best choice. 259 It is to be noted that the SR nodes implementing the Alternate 260 Marking functionality follows the MTU and other considerations 261 outlined in [I-D.voyer-6man-extension-header-insertion]. 262 Furthermore, in a SRv6 network, the intermediated nodes that are not 263 in the SID list do not consider the SRH, therefore they cannot 264 support and dig into the SRH TLV. 266 It is possible to summarize the procedure for AltMark data 267 encapsulation in SRv6 SRH: 269 * Ingress Node: As part of the SRH encapsulation, the ingress node 270 of an SR domain or an SR Policy 271 [I-D.ietf-spring-segment-routing-policy] MAY add the AltMark TLV 272 in the SRH of the data packet, if it supports AltMark 273 functionality and based on local configuration. 275 * Intermediate SR Node: The intermediate SR node is any node 276 receiving an IPv6 packet where the destination address of that 277 packet is a local SID. If an intermediate SR node is not capable 278 of processing AltMark TLV, it simply ignores it. While, if an 279 intermediate SR node is capable of processing AltMark TLV, it 280 checks if SRH AltMark TLV is present in the packet using 281 procedures defined in [RFC8754] and process it. 283 * Egress Node: The Egress node is the last node in the segment- 284 list of the SRH. The processing of AltMark TLV at the Egress node 285 is similar to the processing of AltMark TLV at the Intermediate SR 286 Nodes. 288 5. Alternate Marking Method Operation 290 [RFC8321], [RFC8889] describe the Alternate Marking Method in 291 general. While [I-D.ietf-6man-ipv6-alt-mark] describe in detail the 292 application and the Operation of the methodology for IPv6. 294 6. Security Considerations 296 The security considerations of SRv6 are discussed in [RFC8754] and 297 [I-D.ietf-spring-srv6-network-programming], and the security 298 considerations of Alternate Marking in general and its application to 299 IPv6 are discussed in [RFC8321] and [I-D.ietf-6man-ipv6-alt-mark]. 301 The Alternate Marking application to IPv6, defined in 302 [I-D.ietf-6man-ipv6-alt-mark], analyzes different security concerns 303 and related solutions. These aspects are valid and applicable also 304 to this document. In particular the fundamental security requirement 305 is that Alternate Marking MUST be applied in a specific limited 306 domain, as also mentioned in [RFC8799]. 308 Alternate Marking is a feature applied to a trusted domain, where one 309 or several operators decide on leveraging and configuring Alternate 310 Marking according to their needs. Additionally, operators need to 311 properly secure the Alternate Marking domain to avoid malicious 312 configuration and attacks, which could include injecting malicious 313 packets into a domain. So the implementation of Alternate Marking is 314 applied within a controlled domain where the network nodes are 315 locally administered. A limited administrative domain provides the 316 network administrator with the means to select, monitor and control 317 the access to the network. 319 7. IANA Considerations 321 The SRH TLV Type should be assigned in IANA's Segment Routing Header 322 TLVs Registry. 324 This draft requests to allocate a SRH TLV Type for Alternate Marking 325 TLV data fields under registry name "Segment Routing Header TLVs" 326 requested by [RFC8754]. 328 SRH TLV Type Description Reference 329 ----------------------------------------------------------- 330 TBD AltMark Data Fields TLV This document 332 8. Acknowledgements 334 TBD 336 9. References 338 9.1. Normative References 340 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 341 Requirement Levels", BCP 14, RFC 2119, 342 DOI 10.17487/RFC2119, March 1997, 343 . 345 9.2. Informative References 347 [I-D.fioccola-v6ops-ipv6-alt-mark] 348 Fioccola, G., Velde, G. V. D., Cociglio, M., and P. Muley, 349 "IPv6 Performance Measurement with Alternate Marking 350 Method", draft-fioccola-v6ops-ipv6-alt-mark-01 (work in 351 progress), June 2018. 353 [I-D.ietf-6man-ipv6-alt-mark] 354 Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. 355 Pang, "IPv6 Application of the Alternate Marking Method", 356 draft-ietf-6man-ipv6-alt-mark-04 (work in progress), March 357 2021. 359 [I-D.ietf-spring-segment-routing-policy] 360 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 361 P. Mattes, "Segment Routing Policy Architecture", draft- 362 ietf-spring-segment-routing-policy-11 (work in progress), 363 April 2021. 365 [I-D.ietf-spring-srv6-network-programming] 366 Filsfils, C., Garvia, P. C., Leddy, J., Voyer, D., 367 Matsushima, S., and Z. Li, "Segment Routing over IPv6 368 (SRv6) Network Programming", draft-ietf-spring-srv6- 369 network-programming-28 (work in progress), December 2020. 371 [I-D.voyer-6man-extension-header-insertion] 372 Voyer, D., Filsfils, C., Dukes, D., Matsushima, S., Leddy, 373 J., Li, Z., and J. Guichard, "Deployments With Insertion 374 of IPv6 Segment Routing Headers", draft-voyer-6man- 375 extension-header-insertion-10 (work in progress), November 376 2020. 378 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 379 (IPv6) Specification", STD 86, RFC 8200, 380 DOI 10.17487/RFC8200, July 2017, 381 . 383 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 384 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 385 "Alternate-Marking Method for Passive and Hybrid 386 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 387 January 2018, . 389 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 390 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 391 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 392 . 394 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 395 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 396 . 398 [RFC8889] Fioccola, G., Ed., Cociglio, M., Sapio, A., and R. Sisto, 399 "Multipoint Alternate-Marking Method for Passive and 400 Hybrid Performance Monitoring", RFC 8889, 401 DOI 10.17487/RFC8889, August 2020, 402 . 404 Authors' Addresses 406 Giuseppe Fioccola 407 Huawei 408 Riesstrasse, 25 409 Munich 80992 410 Germany 412 Email: giuseppe.fioccola@huawei.com 414 Tianran Zhou 415 Huawei 416 156 Beiqing Rd. 417 Beijing 100095 418 China 420 Email: zhoutianran@huawei.com 421 Mauro Cociglio 422 Telecom Italia 423 Via Reiss Romoli, 274 424 Torino 10148 425 Italy 427 Email: mauro.cociglio@telecomitalia.it