idnits 2.17.1 draft-liu-mpls-nas-combination-00.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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 14 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (24 May 2022) is 703 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 (-04) exists of draft-andersson-mpls-mna-fwk-01 ** Downref: Normative reference to an Informational draft: draft-andersson-mpls-mna-fwk (ref. 'I-D.andersson-mpls-mna-fwk') == Outdated reference: A later version (-04) exists of draft-ietf-mpls-mna-usecases-00 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Liu 3 Internet-Draft Z. Zhang 4 Intended status: Standards Track ZTE 5 Expires: 25 November 2022 24 May 2022 7 Combination Method of NASs 8 draft-liu-mpls-nas-combination-00 10 Abstract 12 This document provides an alternate mechanism to provide different 13 ordering of in-stack data for MNA solutions which leverage the fixed 14 bit catalogs. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on 25 November 2022. 33 Copyright Notice 35 Copyright (c) 2022 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 40 license-info) in effect on the date of publication of this document. 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. Code Components 43 extracted from this document must include Revised BSD License text as 44 described in Section 4.e of the Trust Legal Provisions and are 45 provided without warranty as described in the Revised BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 51 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Combination of NASs . . . . . . . . . . . . . . . . . . . . . 3 53 2.1. Different Ordering of Network Action/In-stack Data . . . 3 54 2.2. C-bit in the Indicator . . . . . . . . . . . . . . . . . 4 55 2.3. Encoding Example . . . . . . . . . . . . . . . . . . . . 4 56 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 57 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 58 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 5.1. Normative References . . . . . . . . . . . . . . . . . . 5 60 5.2. Informative References . . . . . . . . . . . . . . . . . 5 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 63 1. Introduction 65 There is significant interest in developing the MPLS data plane to 66 address the requirements of new applications 67 [I-D.ietf-mpls-mna-usecases]. As introduced in 68 [I-D.andersson-mpls-mna-fwk], the MPLS Network Actions (MNA) 69 technologies aim to solve this. An MNA solution is envisioned as a 70 set of network action sub-stacks(NAS), each consists of label, 71 indicators and in-Stack Data. 73 One MNA solution may choose to encode the set of network actions as a 74 list of bits in the network action indicator, and the ordering of the 75 in-stack data LSEs corresponds to the ordering of the network action 76 indicators. If the meaning and ordering of the bits in the network 77 action indicator is fixed, then the ordering of the network action 78 and the corresponding possible in-stack data in the NAS are fixed 79 either. 81 Solutions leveraging the fixed bit catalogs are efficient for LSRs to 82 process, but there may be scenarios where the ordering of the network 83 actions/in-stack datas expected is not the ordering specified in the 84 network action indicator. 86 This document provides an alternate mechanism to provide different 87 ordering of in-stack data for MNA solutions which leverage the fixed 88 bit catalogs and makes these solutions more flexible. 90 1.1. Requirements Language 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 1.2. Terminology 98 The terminologies follows [I-D.andersson-mpls-mna-fwk]. 100 * Ancillary Data (AD): Data relating to the MPLS packet that may be 101 used to affect the forwarding or other processing of that packet, 102 either at an Label Edge Router (LER) [RFC4221] or Label Switching 103 Router (LSR). This data may be encoded within a network action 104 sub-stack (see below) (in-stack data), and/or after the bottom of 105 the label stack (post-stack data). 107 * Network Action: An operation to be performed on a packet. A 108 network action may affect router state, packet forwarding, or it 109 may affect the packet in some other way. A network action is said 110 to be present if there is an indicator in the packet that invokes 111 the action. 113 * Network Action Indication (NAI): An indication in the packet that 114 a certain network action is to be perfomed. There may be 115 associated ancillary data in the packet. 117 * Network Action Sub-Stack (NAS): A set of related, contiguous Label 118 Stack Entries (LSEs). The first LSE is the Network Action Sub- 119 stack Indicator. The TC and TTL values in the sub-stack may be 120 redefined. 122 * Network Action Sub-Stack Indicator (NSI): An LSE that contains a 123 special label that indicates the start of a Network Action Sub- 124 stack. 126 2. Combination of NASs 128 2.1. Different Ordering of Network Action/In-stack Data 130 0 1 2 3 131 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Label |x x x|S|x x|x|x x x|A|B| 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 Figure 1: Bit-cataloged Indicator 138 Figure 1 show an example of a bit-cataloged indicator in the NAS 139 (using the TC and TTL repurposed method). 141 Bit A indicates that network action A and the corresponding in-stack 142 ancillary data A is present when set to 1. 144 Bit B indicates that network action B and the corresponding in-stack 145 ancillary data A is present when set to 1. 147 If bit A and bit B are both set to 1, it indicates that both network 148 action A and network action B are present, and the LSE which carries 149 data A is followed by that which contains data B. 151 If it is required that data B is located before data A in the packet, 152 an single NAS based on the fixed-bit approach can't fulfill this 153 requirement. 155 2.2. C-bit in the Indicator 157 This document introduces a continue bit (C-bit) in the indicator as 158 shown in the encoding example in Figure 2. 160 0 1 2 3 161 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Label |x x x|S|x x|C|x x x|x|x| 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 Figure 2: C-bit in the Indicator 168 When C-bit is set to 1, it indicates that there's another NAS 169 following and the LSR SHOULD continue to look for the beginning of 170 the next NAS and process it. 172 With C-bit, NASs can be combined together as a whole to express 173 different ordering of network actions and in-stack data. 175 2.3. Encoding Example 177 Figure 3 shows an encoding example of the combination of NASs 178 leveraging C-bit. 180 0 1 2 3 181 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------------- 183 | Label |x x x|S|x x|1|x x x|0|1| 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NAS-1 185 | Data B | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------------- 187 | Label |x x x|S|x x|0|x x x|1|0| 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NAS-2 189 | Data A | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------------- 191 Figure 3: Combination of NASs 193 For the indicator in NAS-1: 195 C=1: there's another NAS following. 197 B=1: Data B is included. 199 For the indicator in NAS-2: 201 C=0: there's no NAS following. 203 A=1: Data A is included. 205 3. IANA Considerations 207 IANA is requested to create a new registry to assign a bit position 208 for C-bit of the network action indicator. . 210 +==============+=============+===============+ 211 | Bit Position | Description | Reference | 212 +==============+=============+===============+ 213 | TBA | Continue to | This document | 214 | | next NAS | | 215 +--------------+-------------+---------------+ 217 4. Security Considerations 219 This document introduces no new security considerations. 221 5. References 223 5.1. Normative References 225 [I-D.andersson-mpls-mna-fwk] 226 Andersson, L., Bryant, S., Bocci, M., and T. Li, "MPLS 227 Network Actions Framework", Work in Progress, Internet- 228 Draft, draft-andersson-mpls-mna-fwk-01, 27 April 2022, 229 . 232 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 233 Requirement Levels", BCP 14, RFC 2119, 234 DOI 10.17487/RFC2119, March 1997, 235 . 237 5.2. Informative References 239 [I-D.ietf-mpls-mna-usecases] 240 Saad, T., Makhijani, K., Song, H., and G. Mirsky, "Use 241 Cases for MPLS Network Action Indicators and MPLS 242 Ancillary Data", Work in Progress, Internet-Draft, draft- 243 ietf-mpls-mna-usecases-00, 19 May 2022, 244 . 247 [RFC4221] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol 248 Label Switching (MPLS) Management Overview", RFC 4221, 249 DOI 10.17487/RFC4221, November 2005, 250 . 252 Authors' Addresses 254 Yao Liu 255 ZTE 256 Nanjing 257 China 258 Email: liu.yao71@zte.com.cn 260 Zheng Zhang 261 ZTE 262 Nanjing 263 China 264 Email: zhang.zheng@zte.com.cn