idnits 2.17.1 draft-ietf-mpls-sfl-framework-08.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 (June 08, 2020) is 1410 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-07 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: December 10, 2020 Huawei 6 G. Swallow 7 Southend Technical Center 8 S. Sivabalan 9 Ciena Corporation 10 G. Mirsky 11 ZTE Corp. 12 June 08, 2020 14 Synonymous Flow Label Framework 15 draft-ietf-mpls-sfl-framework-08 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 December 10, 2020. 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 . . . . . . . . . . . . . . . . . . . . . . . 9 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) (see 86 Section 3) in which labels which mimic the behaviour of other labels 87 provide the identification service. These identifiers can be used to 88 trigger per-flow operations on the packet at the receiving label 89 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 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 Consider an MPLS application such as a pseudowire (PW), and consider 116 that it is desired to use the approach specified in this document to 117 make a packet loss measurement. By some method outside the scope of 118 this text, two labels, synonymous with the PW labels are obtained 119 from the egress terminating provider edge (T-PE). One control 120 protocol providing a method of exhanging SFLs is described in 121 [I-D.bryant-mpls-sfl-control]. By alternating between these SFLs and 122 using them in place of the PW label, the PW packets may be batched 123 for counting without any impact on the PW forwarding behaviour (note 124 that strictly only one SFL is needed in this application, but that is 125 an optimization that is a matter for the implementor). 127 Now consider an MPLS application that is multi-point to point such as 128 a VPN. Here it is necessary to identify a packet batch from a 129 specific source. This is achieved by making the SFLs source 130 specific, so that batches from one source are marked differently from 131 batches from another source. The sources all operate independently 132 and asynchronously from each other, independently co-ordinating with 133 the destination. Each ingress is thus able to establish its own SFL 134 to identify the sub-flow and thus enable PM per flow. 136 Finally we need to consider the case where there is no MPLS 137 application label such as occurs when sending IP over an LSP. In 138 this case introducing an SFL that was synonymous with the LSP label 139 would introduce network wide forwarding state. This would not be 140 acceptable for scaling reasons. We therefore have no choice but to 141 introduce an additional label. Where penultimate hop popping (PHP) 142 is in use, the semantics of this additional label can be similar to 143 the LSP label. Where PHP is not in use, the semantics are similar to 144 an MPLS explicit NULL [RFC3032]. In both of these cases the label 145 has the additional semantics of the SFL. 147 Note that to achieve the goals set out in Section 1 SFLs need to be 148 allocated from the platform label table. 150 4. User Service Traffic in the Data Plane 152 As noted in Section 3 it is necessary to consider two cases: 154 1. Applications label present 156 2. Single label stack 158 4.1. Applications Label Present 160 Figure 1 shows the case in which both an LSP label and an application 161 label are present in the MPLS label stack. Traffic with no SFL 162 function present runs over the "normal" stack, and SFL enabled flows 163 run over the SFL stack with the SFL used to indicate the packet 164 batch. 166 +-----------------+ +-----------------+ 167 | | | | 168 | 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-07 (work in progress), June 2020. 380 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 381 Measurement for MPLS Networks", RFC 6374, 382 DOI 10.17487/RFC6374, September 2011, 383 . 385 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 386 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 387 RFC 6790, DOI 10.17487/RFC6790, November 2012, 388 . 390 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 391 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 392 2014, . 394 [RFC8372] Bryant, S., Pignataro, C., Chen, M., Li, Z., and G. 395 Mirsky, "MPLS Flow Identification Considerations", 396 RFC 8372, DOI 10.17487/RFC8372, May 2018, 397 . 399 Authors' Addresses 401 Stewart Bryant 402 Fururewei Technologies Inc 404 Email: sb@stewartbryant.com 405 Mach Chen 406 Huawei 408 Email: mach.chen@huawei.com 410 George Swallow 411 Southend Technical Center 413 Email: swallow.ietf@gmail.com 415 Siva Sivabalan 416 Ciena Corporation 418 Email: ssivabal@ciena.com 420 Gregory Mirsky 421 ZTE Corp. 423 Email: gregimirsky@gmail.com