idnits 2.17.1 draft-ietf-mpls-sfl-framework-11.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 (October 02, 2020) is 1303 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 (-09) exists of draft-bryant-mpls-sfl-control-08 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group S. Bryant 3 Internet-Draft Futurewei Technologies Inc 4 Intended status: Standards Track M. Chen 5 Expires: April 5, 2021 Huawei 6 G. Swallow 7 Southend Technical Center 8 S. Sivabalan 9 Ciena Corporation 10 G. Mirsky 11 ZTE Corp. 12 October 02, 2020 14 Synonymous Flow Label Framework 15 draft-ietf-mpls-sfl-framework-11 17 Abstract 19 RFC 8372 (MPLS Flow Identification Considerations) describes the 20 requirement for introducing flow identities within the MPLS 21 architecture. This document describes a method of accomplishing this 22 by using a technique called Synonymous Flow Labels in which labels 23 which mimic the behaviour of other labels provide the identification 24 service. These identifiers can be used to trigger per-flow 25 operations on the packet at the receiving label switching router. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 5, 2021. 44 Copyright Notice 46 Copyright (c) 2020 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 63 3. Synonymous Flow Labels . . . . . . . . . . . . . . . . . . . 3 64 4. User Service Traffic in the Data Plane . . . . . . . . . . . 4 65 4.1. Application Label Present . . . . . . . . . . . . . . . . 4 66 4.1.1. Setting TTL and the Traffic Class Bits . . . . . . . 5 67 4.2. Single Label Stack . . . . . . . . . . . . . . . . . . . 5 68 4.2.1. Setting TTL and the Traffic Class Bits . . . . . . . 6 69 4.3. Aggregation of SFL Actions . . . . . . . . . . . . . . . 6 70 5. Equal Cost Multipath Considerations . . . . . . . . . . . . . 7 71 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . 8 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 77 10.2. Informative References . . . . . . . . . . . . . . . . . 9 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 80 1. Introduction 82 [RFC8372] (MPLS Flow Identification Considerations) describes the 83 requirement for introducing flow identities within the MPLS 84 architecture. This document describes a method of providing the 85 required identification by using a technique called Synonymous Flow 86 Labels (SFL) in which labels which mimic the behaviour of other MPLS 87 labels provide the identification service. These identifiers can be 88 used to trigger per-flow operations on the packet at the receiving 89 label switching router. 91 2. Requirements Language 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 95 "OPTIONAL" in this document are to be interpreted as described in BCP 96 14 [RFC2119] [RFC8174] when, and only when, they appear in all 97 capitals, as shown here. 99 3. Synonymous Flow Labels 101 An SFL is defined to be a label that causes exactly the same 102 behaviour at the egress Label Edge Router (LER) as the label it 103 replaces, except that it also causes one or more additional actions 104 that have been previously agreed between the peer LERs to be executed 105 on the packet. There are many possible additional actions such as 106 the measurement of the number of received packets in a flow, 107 triggering an IP Flow Information Export (IPFIX) [RFC7011] capture, 108 triggering other types of Deep Packet Inspection, or identification 109 of the packet source. In, for example, a Performance Monitoring (PM) 110 application, the agreed action could be the recording of the receipt 111 of the packet by incrementing a packet counter. This is a natural 112 action in many MPLS implementations, and where supported this permits 113 the implementation of high quality packet loss measurement without 114 any change to the packet forwarding system. 116 To illustrate the use of this technology, we start by considering the 117 case where there is an "application" label in the MPLS label stack. 118 As a first example, let us consider a pseudowire (PW) [RFC3985] on 119 which it is desired to make packet loss measurements. Two labels, 120 synonymous with the PW labels, are obtained from the egress 121 terminating provider edge (T-PE). By alternating between these SFLs 122 and using them in place of the PW label, the PW packets may be 123 batched for counting without any impact on the PW forwarding behavior 124 [RFC8321] (note that strictly only one SFL is needed in this 125 application, but that is an optimization that is a matter for the 126 implementor). The method of obtaining these additional labels is 127 outside the scope of this text, however, one control protocol that 128 provides a method of obtaining SFLs is described in 129 [I-D.bryant-mpls-sfl-control]. 131 Now consider an MPLS application that is multi-point to point such as 132 a VPN. Here it is necessary to identify a packet batch from a 133 specific source. This is achieved by making the SFLs source 134 specific, so that batches from one source are marked differently from 135 batches from another source. The sources all operate independently 136 and asynchronously from each other, independently coordinating with 137 the destination. Each ingress LER is thus able to establish its own 138 SFL to identify the sub-flow and thus enable PM per flow. 140 Finally we need to consider the case where there is no MPLS 141 application label such as occurs when sending IP over an LSP, i.e. 142 there is a single label in the MPLS label stack. In this case 143 introducing an SFL that was synonymous with the LSP label would 144 introduce network-wide forwarding state. This would not be 145 acceptable for scaling reasons. We therefore have no choice but to 146 introduce an additional label. Where penultimate hop popping (PHP) 147 is in use, the semantics of this additional label can be similar to 148 the LSP label. Where PHP is not in use, the semantics are similar to 149 an MPLS explicit NULL [RFC3032]. In both of these cases the label 150 has the additional semantics of the SFL. 152 Note that to achieve the goals set out above, SFLs need to be 153 allocated from the platform label table. 155 4. User Service Traffic in the Data Plane 157 As noted in Section 3 it is necessary to consider two cases: 159 1. Application label is present 161 2. Single label stack 163 4.1. Application Label Present 165 Figure 1 shows the case in which both an LSP label and an application 166 label are present in the MPLS label stack. Traffic with no SFL 167 function present runs over the "normal" stack, and SFL-enabled flows 168 run over the SFL stack with the SFL used to indicate the packet 169 batch. 171 +-----------------+ +-----------------+ 172 | LSP | | LSP | 173 | Label | | Label | 174 | (May be PHPed) | | (May be PHPed) | 175 +-----------------+ +-----------------+ 176 | | | | 177 | Application | | Synonymous Flow | 178 | Label | | Label | 179 +-----------------+ <= BoS +-----------------+ <= Bottom of stack 180 | | | | 181 | Payload | | Payload | 182 | | | | 183 +-----------------+ +-----------------+ 185 "Normal" Label Stack Label Stack with SFL 187 Figure 1: Use of Synonymous Labels In A Two Label MPLS Label Stack 189 At the egress LER the LSP label is popped (if present). Then the SFL 190 is processed executing both the synonymous function and the 191 corresponding application function. 193 4.1.1. Setting TTL and the Traffic Class Bits 195 The TTL and the Traffic Class bits [RFC5462] in the SFL label stack 196 entry (LSE) would normally be set to the same value as would have 197 been set in the label that the SFL is synonymous with. However, it 198 is recognized that if there is an application need these fields in 199 the SFL Label Stack Entry (LSE) MAY be set these to some other value. 200 An example would be where it was desired to cause the SFL to trigger 201 an action in the TTL expiry exception path as part of the label 202 action. 204 4.2. Single Label Stack 206 Figure 2 shows the case in which only an LSP label is present in the 207 MPLS label stack. Traffic with no SFL function present runs over the 208 "normal" stack and SFL-enabled flows run over the SFL stack with the 209 SFL used to indicate the packet batch. However in this case it is 210 necessary for the ingress Label Edge Router (LER) to first push the 211 SFL and then to push the LSP label. 213 +-----------------+ 214 | LSP | 215 | Label | 216 | (May be PHPed) | 217 +-----------------+ +-----------------+ 218 | LSP | | | <= Synonymous with 219 | Label | | Synonymous Flow | Explicit NULL 220 | (May be PHPed) | | Label | 221 +-----------------+ <= BoS +-----------------+ <= Bottom of stack 222 | | | | 223 | Payload | | Payload | 224 | | | | 225 +-----------------+ +-----------------+ 227 "Normal" Label Stack Label Stack with SFL 229 Figure 2: Use of Synonymous Labels In A Single Label MPLS Label Stack 231 At the receiving Label Switching Router (LSR) it is necessary to 232 consider two cases: 234 1. Where the LSP label is still present 235 2. Where the LSP label is penultimate hop popped 237 If the LSP label is present, it is processed exactly as it would 238 normally processed and then it is popped. This reveals the SFL, 239 which, in the case of [RFC6374] measurements, is simply counted and 240 then discarded. In this respect the processing of the SFL is 241 synonymous with an MPLS Explicit NULL. As the SFL is the bottom of 242 stack, the IP packet that follows is processed as normal. 244 If the LSP label is not present due to PHP action in the upstream 245 LSR, two almost equivalent processing actions can take place. Either 246 the SFL can be treated as an LSP label that was not PHPed and the 247 additional associated SFL action is taken when the label is 248 processed. Alternatively, it can be treated as an MPLS Explicit NULL 249 with associated SFL actions. From the perspective of the measurement 250 system described in this document the behaviour of the two approaches 251 is indistinguishable and thus either may be implemented. 253 4.2.1. Setting TTL and the Traffic Class Bits 255 The TTL and the Traffic Class considerations described in 256 Section 4.1.1 apply. 258 4.3. Aggregation of SFL Actions 260 There are cases where it is desirable to aggregate an SFL action 261 against a number of labels. For example, where it is desirable to 262 have one counter record the number of packets received over a group 263 of application labels, or where the number of labels used by a single 264 application is large, and the resultant increase in the number of 265 allocated labels needed to support the SFL actions may becomes too 266 large to be viable. In these circumstances it would be necessary to 267 introduce an additional label in the stack to act as an aggregate 268 instruction. This is not strictly a synonymous action in that the 269 SFL is not replacing an existing label, but is somewhat similar to 270 the single label case shown in Section 4.2, and the same signalling, 271 management and configuration tools would be applicable. 273 +-----------------+ 274 | LSP | 275 | Label | 276 | (May be PHPed) | 277 +-----------------+ +-----------------+ 278 | LSP | | | 279 | Label | | Aggregate | 280 | (May be PHPed) | | SFL | 281 +-----------------+ +-----------------+ 282 | | | | 283 | Application | | Application | 284 | Label | | Label | 285 +-----------------+ <=BoS +-----------------+ <= Bottom of stack 286 | | | | 287 | Payload | | Payload | 288 | | | | 289 +-----------------+ +-----------------+ 291 "Normal" Label Stack Label Stack with SFL 293 Figure 3: Aggregate SFL Actions 295 The Aggregate SFL is shown in the label stack depicted in Figure 3 as 296 preceding the application label, however the choice of position 297 before, or after, the application label will be application specific. 298 In the case described in Section 4.1, by definition the SFL has the 299 full application context. In this case the positioning will depend 300 on whether the SFL action needs the full context of the application 301 to perform its action and whether the complexity of the application 302 will be increased by finding an SFL following the application label. 304 5. Equal Cost Multipath Considerations 306 The introduction of an SFL to an existing flow may cause that flow to 307 take a different path through the network under conditions of Equal 308 Cost Multi-path (ECMP). This in turn may invalidate certain uses of 309 the SFL such as performance measurement applications. Where this is 310 a problem there are two solutions worthy of consideration: 312 1. The operator MAY elect to always run with the SFL in place in the 313 MPLS label stack. 315 2. The operator can elect to use [RFC6790] Entropy Labels in a 316 network that fully supports this type of ECMP. If this approach 317 is adopted, the intervening MPLS network MUST NOT load balance on 318 any packet field other than the entropy label. Note that this is 319 stricter than the text in Section 4.3 of [RFC6790]. 321 6. Privacy Considerations 323 IETF concerns on pervasive monitoring are described in [RFC7258]. 324 The inclusion of originating and/or flow information in a packet 325 provides more identity information and hence potentially degrades the 326 privacy of the communication to an attacker in a position to observe 327 the added identifier. Whilst the inclusion of the additional 328 granularity does allow greater insight into the flow characteristics 329 it does not specifically identify which node originated the packet 330 unless the attacker can inspect the network at the point of ingress, 331 or inspection of the control protocol packets. This privacy threat 332 may be mitigated by encrypting the control protocol packets, by 333 regularly changing the synonymous labels or by concurrently using a 334 number of such labels, including the use of a combination of those 335 methods. Minimizing the scope of the identity indication can be 336 useful in minimizing the observability of the flow characteristics. 337 Whenever IPFIX or other DPI technique is used, their relavent privacy 338 considerations apply. 340 7. Security Considerations 342 There are no new security issues associated with the MPLS data plane. 343 Any control protocol used to request SFLs will need to ensure the 344 legitimacy of the request, i.e. that the requesting node is 345 authorized to make that SFL request by the network operator. 347 8. IANA Considerations 349 This draft makes no IANA requests. 351 9. Contributing Authors 353 Zhenbin Li 354 Huawei 355 Email: lizhenbin@huawei.com 357 10. References 359 10.1. Normative References 361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 362 Requirement Levels", BCP 14, RFC 2119, 363 DOI 10.17487/RFC2119, March 1997, 364 . 366 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 367 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 368 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 369 . 371 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 372 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 373 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 374 2009, . 376 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 377 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 378 RFC 6790, DOI 10.17487/RFC6790, November 2012, 379 . 381 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 382 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 383 May 2017, . 385 10.2. Informative References 387 [I-D.bryant-mpls-sfl-control] 388 Bryant, S., Swallow, G., and S. Sivabalan, "A Simple 389 Control Protocol for MPLS SFLs", draft-bryant-mpls-sfl- 390 control-08 (work in progress), June 2020. 392 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation 393 Edge-to-Edge (PWE3) Architecture", RFC 3985, 394 DOI 10.17487/RFC3985, March 2005, 395 . 397 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 398 Measurement for MPLS Networks", RFC 6374, 399 DOI 10.17487/RFC6374, September 2011, 400 . 402 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 403 "Specification of the IP Flow Information Export (IPFIX) 404 Protocol for the Exchange of Flow Information", STD 77, 405 RFC 7011, DOI 10.17487/RFC7011, September 2013, 406 . 408 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 409 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 410 2014, . 412 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 413 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 414 "Alternate-Marking Method for Passive and Hybrid 415 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 416 January 2018, . 418 [RFC8372] Bryant, S., Pignataro, C., Chen, M., Li, Z., and G. 419 Mirsky, "MPLS Flow Identification Considerations", 420 RFC 8372, DOI 10.17487/RFC8372, May 2018, 421 . 423 Authors' Addresses 425 Stewart Bryant 426 Futurewei Technologies Inc 428 Email: sb@stewartbryant.com 430 Mach Chen 431 Huawei 433 Email: mach.chen@huawei.com 435 George Swallow 436 Southend Technical Center 438 Email: swallow.ietf@gmail.com 440 Siva Sivabalan 441 Ciena Corporation 443 Email: ssivabal@ciena.com 445 Gregory Mirsky 446 ZTE Corp. 448 Email: gregimirsky@gmail.com