idnits 2.17.1 draft-many-mpls-multiple-gal-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 (28 April 2021) is 1093 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 (-03) exists of draft-lm-mpls-sfc-path-verification-02 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 G. Mirsky 3 Internet-Draft ZTE Corp. 4 Updates: 5586 (if approved) H. van Helvoort 5 Intended status: Standards Track Individual Contributor 6 Expires: 30 October 2021 S. Bryant 7 Futurewei Technologies Inc. 8 A. Vainshtein 9 Ribbon Communications Inc. 10 I. Busi 11 Huawei 12 28 April 2021 14 Number of Generic Associated Channel Labels in the MPLS Label Stack 15 draft-many-mpls-multiple-gal-01 17 Abstract 19 This document describes the requirements for using multiple Generic 20 Associated Channel Labels (GALs) in an MPLS label stack. As a 21 result, the document updates RFC 5586 by removing the restriction 22 imposed on the usage of GAL that limits the number of GAL in the MPLS 23 label stack to one. 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 30 October 2021. 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 (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 60 3. Number of GAL in the MPLS Label Stack . . . . . . . . . . . . 3 61 4. Processing GAL when not at the Bottom of the Label Stack . . 3 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 64 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 4 67 8.2. Informative References . . . . . . . . . . . . . . . . . 4 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 70 1. Introduction 72 [RFC5085] defined the associated channel mechanism and the Associated 73 Channel Header (ACH) for exchange of control, management, and 74 Operations, Administration, and Maintenance (OAM) messages in 75 Pseudowires (PWs). [RFC5586] generalized that associated channel 76 mechanism and the ACH for use in Sections, Label Switched Paths 77 (LSPs), and PWs as the Generic Associated Channel (G-ACh) and 78 introduced the generalized label-based exception mechanism using the 79 Generic Associated Channel Label (GAL). 81 [RFC5586] restricted the number of times a GAL can appear in an MPLS 82 label stack to one time only. This document updates [RFC5586] by 83 removing that restriction for non-MPLS-TP networks. 85 2. Requirements Language 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 89 "OPTIONAL" in this document are to be interpreted as described in BCP 90 14 [RFC2119] [RFC8174] when, and only when, they appear in all 91 capitals, as shown here. 93 3. Number of GAL in the MPLS Label Stack 95 [RFC5586] has limited the number of GALs in an MPLS label stack: 97 Furthermore, when present, the GAL MUST NOT appear more than once 98 in the label stack. 100 In some MPLS networks, e.g., when realizing Service Function Chaining 101 with MPLS-based forwarding plane [RFC8595], putting more than a 102 single GAL in the MPLS label stack can simplify the processing of OAM 103 packets and, as a result, improve the performance. An extension of 104 the MPLS Echo Request and Reply protocol [RFC8029] in such an 105 environment is discussed in [I-D.lm-mpls-sfc-path-verification]. 106 Because it is expected that a general Service Function does not 107 support processing of MPLS echo request messages, a GAL being used 108 within a basic unit of MPLS label stack to indicate that the payload 109 is ACH-encapsulated OAM message. And in the label-stacking case, 110 multiple basic units on the MPLS label stack, and, consequently, GALs 111 could be placed in an MPLS label stack. Thus, this document removes 112 the limit on the number of GALs present in an MPLS label stack by 113 changing the statement in [RFC5586] as follows: 115 Furthermore, in non-MPLS-TP networks, when present, the GAL MAY 116 appear more than once in the label stack. 118 [RFC5586] requires that when GAL is at the bottom of the label stack, 119 it is followed by an ACH: 121 Where the GAL is at the bottom of the label stack (i.e., S bit set 122 to 1), then it MUST always be followed by an ACH. 124 This document updates [RFC5586] by extending that requirement for 125 environments when GAL is not at the bottom of the label stack as 126 follows: 128 Where GAL is present in the label stack, the label element at the 129 bottom of the label stack (i.e., S bit set to 1) MUST always be 130 followed by an ACH. 132 4. Processing GAL when not at the Bottom of the Label Stack 134 [Ed.note: Describe GAL processing by transit and egress nodes. 135 Illustrate the transformation of the MPLS label stack as a packet 136 transits through the domain.] 138 5. IANA Considerations 140 This document makes no request for IANA allocations. This section 141 should be removed before publication. 143 6. Security Considerations 145 There are no further security considerations than those in [RFC5586]. 147 7. Acknowledgments 149 TBA 151 8. References 153 8.1. Normative References 155 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 156 Requirement Levels", BCP 14, RFC 2119, 157 DOI 10.17487/RFC2119, March 1997, 158 . 160 [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual 161 Circuit Connectivity Verification (VCCV): A Control 162 Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, 163 December 2007, . 165 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 166 "MPLS Generic Associated Channel", RFC 5586, 167 DOI 10.17487/RFC5586, June 2009, 168 . 170 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 171 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 172 May 2017, . 174 [RFC8595] Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based 175 Forwarding Plane for Service Function Chaining", RFC 8595, 176 DOI 10.17487/RFC8595, June 2019, 177 . 179 8.2. Informative References 181 [I-D.lm-mpls-sfc-path-verification] 182 Yao, L. and G. Mirsky, "MPLS-based Service Function 183 Path(SFP) Consistency Verification", Work in Progress, 184 Internet-Draft, draft-lm-mpls-sfc-path-verification-02, 21 185 February 2021, . 188 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 189 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 190 Switched (MPLS) Data-Plane Failures", RFC 8029, 191 DOI 10.17487/RFC8029, March 2017, 192 . 194 Authors' Addresses 196 Greg Mirsky 197 ZTE Corp. 199 Email: gregimirsky@gmail.com, gregory.mirsky@ztetx.com 201 Huub van Helvoort 202 Individual Contributor 204 Email: huubatwork@gmail.com 206 Stewart Bryant 207 Futurewei Technologies Inc. 209 Email: sb@stewartbryant.com 211 Alexander Vainshtein 212 Ribbon Communications Inc. 214 Email: Alexander.Vainshtein@rbbn.com 216 Italo Busi 217 Huawei 219 Email: italo.busi@huawei.com