idnits 2.17.1 draft-ietf-mpls-sfl-framework-09.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 08, 2020) is 1389 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-bryant-mpls-sfl-control-08 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group S. Bryant 3 Internet-Draft Fururewei Technologies Inc 4 Intended status: Informational M. Chen 5 Expires: January 9, 2021 Huawei 6 G. Swallow 7 Southend Technical Center 8 S. Sivabalan 9 Ciena Corporation 10 G. Mirsky 11 ZTE Corp. 12 July 08, 2020 14 Synonymous Flow Label Framework 15 draft-ietf-mpls-sfl-framework-09 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 January 9, 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. Applications 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 accomplishing this 85 by using a technique called Synonymous Flow Labels (SFL) in which 86 labels which mimic the behaviour of other labels provide the 87 identification service. These identifiers can be used to trigger 88 per-flow operations on the packet at the receiving label switching 89 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 Switching Router (LSR) as the label it 103 replaces, but in addition also causes an agreed action to take place 104 on the packet. There are many possible additional actions such as 105 the measurement of the number of received packets in a flow, 106 triggering IPFIX inspection, triggering other types of Deep Packet 107 Inspection, or identification of the packet source. In, for example, 108 a Performance Monitoring (PM) application, the agreed action could be 109 the recording of the receipt of the packet by incrementing a packet 110 counter. This is a natural action in many MPLS implementations, and 111 where supported this permits the implementation of high quality 112 packet loss measurement without any change to the packet forwarding 113 system. 115 As an example application of this technology, let us consider a 116 pseudowire (PW) [RFC3985] on which it is desired to make packet loss 117 measurement. Two labels, synonymous with the PW labels, are obtained 118 from the egress terminating provider edge (T-PE). By alternating 119 between these SFLs and using them in place of the PW label, the PW 120 packets may be batched for counting without any impact on the PW 121 forwarding behavior (note that strictly only one SFL is needed in 122 this application, but that is an optimization that is a matter for 123 the implementor). The method of obtaining these additional labels is 124 outside the scope of this text, however, one control protocol that 125 provides a method of obtaining SFLs is described in 126 [I-D.bryant-mpls-sfl-control]. 128 Now consider an MPLS application that is multi-point to point such as 129 a VPN. Here it is necessary to identify a packet batch from a 130 specific source. This is achieved by making the SFLs source 131 specific, so that batches from one source are marked differently from 132 batches from another source. The sources all operate independently 133 and asynchronously from each other, independently co-ordinating with 134 the destination. Each ingress is thus able to establish its own SFL 135 to identify the sub-flow and thus enable PM per flow. 137 Finally we need to consider the case where there is no MPLS 138 application label such as occurs when sending IP over an LSP. In 139 this case introducing an SFL that was synonymous with the LSP label 140 would introduce network wide forwarding state. This would not be 141 acceptable for scaling reasons. We therefore have no choice but to 142 introduce an additional label. Where penultimate hop popping (PHP) 143 is in use, the semantics of this additional label can be similar to 144 the LSP label. Where PHP is not in use, the semantics are similar to 145 an MPLS explicit NULL [RFC3032]. In both of these cases the label 146 has the additional semantics of the SFL. 148 Note that to achieve the goals set out in Section 1 SFLs need to be 149 allocated from the platform label table. 151 4. User Service Traffic in the Data Plane 153 As noted in Section 3 it is necessary to consider two cases: 155 1. Applications label present 157 2. Single label stack 159 4.1. Applications Label Present 161 Figure 1 shows the case in which both an LSP label and an application 162 label are present in the MPLS label stack. Traffic with no SFL 163 function present runs over the "normal" stack, and SFL enabled flows 164 run over the SFL stack with the SFL used to indicate the packet 165 batch. 167 +-----------------+ +-----------------+ 168 | | | | 169 | LSP | | LSP | . 359 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 360 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 361 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 362 . 364 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 365 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 366 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 367 2009, . 369 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 370 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 371 May 2017, . 373 10.2. Informative References 375 [I-D.bryant-mpls-sfl-control] 376 Bryant, S., Swallow, G., and S. Sivabalan, "A Simple 377 Control Protocol for MPLS SFLs", draft-bryant-mpls-sfl- 378 control-08 (work in progress), June 2020. 380 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation 381 Edge-to-Edge (PWE3) Architecture", RFC 3985, 382 DOI 10.17487/RFC3985, March 2005, 383 . 385 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 386 Measurement for MPLS Networks", RFC 6374, 387 DOI 10.17487/RFC6374, September 2011, 388 . 390 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 391 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 392 RFC 6790, DOI 10.17487/RFC6790, November 2012, 393 . 395 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 396 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 397 2014, . 399 [RFC8372] Bryant, S., Pignataro, C., Chen, M., Li, Z., and G. 400 Mirsky, "MPLS Flow Identification Considerations", 401 RFC 8372, DOI 10.17487/RFC8372, May 2018, 402 . 404 Authors' Addresses 406 Stewart Bryant 407 Fururewei Technologies Inc 409 Email: sb@stewartbryant.com 411 Mach Chen 412 Huawei 414 Email: mach.chen@huawei.com 416 George Swallow 417 Southend Technical Center 419 Email: swallow.ietf@gmail.com 421 Siva Sivabalan 422 Ciena Corporation 424 Email: ssivabal@ciena.com 426 Gregory Mirsky 427 ZTE Corp. 429 Email: gregimirsky@gmail.com