idnits 2.17.1 draft-ietf-mpls-sfl-framework-07.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 03, 2020) is 1394 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-06 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 S. Bryant 4 Intended status: Informational Fururewei Technologies Inc 5 Expires: December 5, 2020 M. Chen 6 Z. Li 7 Huawei 8 G. Swallow 9 Southend Technical Center 10 S. Sivabalan 11 Cisco Systems 12 G. Mirsky 13 ZTE Corp. 14 June 03, 2020 16 Synonymous Flow Label Framework 17 draft-ietf-mpls-sfl-framework-07 19 Abstract 21 RFC 8372 (MPLS Flow Identification Considerations) describes the 22 requirement for introducing flow identities within the MPLS 23 architecture. This document describes a method of accomplishing this 24 by using a technique called Synonymous Flow Labels in which labels 25 which mimic the behaviour of other labels provide the identification 26 service. These identifiers can be used to trigger per-flow 27 operations on the packet at the receiving label switching router. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on December 5, 2020. 46 Copyright Notice 48 Copyright (c) 2020 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 65 3. Synonymous Flow Labels . . . . . . . . . . . . . . . . . . . 3 66 4. User Service Traffic in the Data Plane . . . . . . . . . . . 4 67 4.1. Applications Label Present . . . . . . . . . . . . . . . 4 68 4.1.1. Setting TTL and the Traffic Class Bits . . . . . . . 5 69 4.2. Single Label Stack . . . . . . . . . . . . . . . . . . . 5 70 4.2.1. Setting TTL and the Traffic Class Bits . . . . . . . 6 71 4.3. Aggregation of SFL Actions . . . . . . . . . . . . . . . 6 72 5. Equal Cost Multipath Considerations . . . . . . . . . . . . . 7 73 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 78 9.2. Informative References . . . . . . . . . . . . . . . . . 9 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 81 1. Introduction 83 [RFC8372] (MPLS Flow Identification Considerations) describes the 84 requirement for introducing flow identities within the MPLS 85 architecture. This document describes a method of accomplishing this 86 by using a technique called Synonymous Flow Labels (SFL) (see 87 Section 3) in which labels which mimic the behaviour of other labels 88 provide the identification service. These identifiers can be used to 89 trigger per-flow operations on the packet at the receiving label 90 switching router. 92 2. Requirements Language 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 96 "OPTIONAL" in this document are to be interpreted as described in BCP 97 14 [RFC2119] [RFC8174] when, and only when, they appear in all 98 capitals, as shown here. 100 3. Synonymous Flow Labels 102 An SFL is defined to be a label that causes exactly the same 103 behaviour at the egress Label Switching Router (LSR) as the label it 104 replaces, but in addition also causes an agreed action to take place 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 IPFIX inspection, triggering other types of Deep Packet 108 Inspection, or identification of the packet source. In, for example, 109 a Performance Monitoring (PM) application, the agreed action could be 110 the recording of the receipt of the packet by incrementing a packet 111 counter. This is a natural action in many MPLS implementations, and 112 where supported this permits the implementation of high quality 113 packet loss measurement without any change to the packet forwarding 114 system. 116 Consider an MPLS application such as a pseudowire (PW), and consider 117 that it is desired to use the approach specified in this document to 118 make a packet loss measurement. By some method outside the scope of 119 this text, two labels, synonymous with the PW labels are obtained 120 from the egress terminating provider edge (T-PE). One control 121 protocol providing a method of exhanging SFLs is described in 122 [I-D.bryant-mpls-sfl-control]. By alternating between these SFLs and 123 using them in place of the PW label, the PW packets may be batched 124 for counting without any impact on the PW forwarding behaviour (note 125 that strictly only one SFL is needed in this application, but that is 126 an optimization that is a matter for the implementor). 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 | . 353 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 354 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 355 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 356 . 358 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 359 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 360 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 361 2009, . 363 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 364 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 365 May 2017, . 367 9.2. Informative References 369 [I-D.bryant-mpls-sfl-control] 370 Bryant, S., Swallow, G., and S. Sivabalan, "A Simple 371 Control Protocol for MPLS SFLs", draft-bryant-mpls-sfl- 372 control-06 (work in progress), January 2020. 374 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 375 Measurement for MPLS Networks", RFC 6374, 376 DOI 10.17487/RFC6374, September 2011, 377 . 379 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 380 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 381 RFC 6790, DOI 10.17487/RFC6790, November 2012, 382 . 384 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 385 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 386 2014, . 388 [RFC8372] Bryant, S., Pignataro, C., Chen, M., Li, Z., and G. 389 Mirsky, "MPLS Flow Identification Considerations", 390 RFC 8372, DOI 10.17487/RFC8372, May 2018, 391 . 393 Authors' Addresses 395 Stewart Bryant 396 Fururewei Technologies Inc 398 Email: stewart.bryant@gmail.com 400 Stewart Bryant 401 Fururewei Technologies Inc 403 Email: sb@stewartbryant.com 404 Mach Chen 405 Huawei 407 Email: mach.chen@huawei.com 409 Zhenbin Li 410 Huawei 412 Email: lizhenbin@huawei.com 414 George Swallow 415 Southend Technical Center 417 Email: swallow.ietf@gmail.com 419 Siva Sivabalan 420 Cisco Systems 422 Email: msiva@cisco.com 424 Gregory Mirsky 425 ZTE Corp. 427 Email: gregimirsky@gmail.com