idnits 2.17.1 draft-liu-spring-sr-sfc-metadata-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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 115: '...milar approaches MAY be used for SR-MP...' RFC 2119 keyword, line 152: '...Metadata Label>) SHOULD be placed at t...' RFC 2119 keyword, line 178: '...Metadata Label>) SHOULD be placed in t...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (15 September 2021) is 947 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) == Unused Reference: 'RFC4928' is defined on line 291, but no explicit reference was found in the text == Unused Reference: 'RFC7274' is defined on line 296, but no explicit reference was found in the text == Unused Reference: 'RFC8660' is defined on line 323, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-spring-sr-service-programming-05 ** Downref: Normative reference to an Informational RFC: RFC 7665 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group Yao. Liu 3 Internet-Draft ZTE Corporation 4 Intended status: Standards Track 15 September 2021 5 Expires: 19 March 2022 7 Metadata in SR-MPLS Service Programming 8 draft-liu-spring-sr-sfc-metadata-01 10 Abstract 12 This document proposes methods to carry metadata in SR service 13 programming with SR-MPLS data plane. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on 19 March 2022. 32 Copyright Notice 34 Copyright (c) 2021 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 39 license-info) in effect on the date of publication of this document. 40 Please review these documents carefully, as they describe your rights 41 and restrictions with respect to this document. Code Components 42 extracted from this document must include Simplified BSD License text 43 as described in Section 4.e of the Trust Legal Provisions and are 44 provided without warranty as described in the Simplified BSD License. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 2. Metadata in SR-MPLS Data Plane . . . . . . . . . . . . . . . 3 50 2.1. the RFC8595 Method . . . . . . . . . . . . . . . . . . . 3 51 2.1.1. Indicating Metadata in User Data Packets . . . . . . 3 52 2.1.2. In-Band Programming of Metadata . . . . . . . . . . . 4 53 2.2. Per Packet Metadata . . . . . . . . . . . . . . . . . . . 4 54 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 55 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 56 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 5.1. Normative References . . . . . . . . . . . . . . . . . . 6 58 5.2. Informative References . . . . . . . . . . . . . . . . . 7 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 61 1. Introduction 63 Service Function Chaining (SFC)[RFC7665] provides support for the 64 creation of composite services that consist of an ordered set of 65 Service Functions (SF) that are to be applied to packets and/or 66 frames selected as a result of classification. 67 [I-D.ietf-spring-sr-service-programming] describes how a service can 68 be associated with a SID and how to achieve service function chaining 69 in SR-enabled MPLS and IPv6 networks. 71 Metadata is defined in [RFC7665] as providing the ability to exchange 72 context information between classifiers and SFs, and among SFs. In 73 the context of Service Function Chaining, metadata provides 74 contextual information about the data packets which traverse a 75 Service Function Chain. 77 For service programming with the SR-MPLS data plane, 78 [I-D.ietf-spring-sr-service-programming] proposes that a SRH inserted 79 between the last MPLS label and the MPLS payload can be used as a 80 metadata container. The SRH does not carry any segment but only the 81 mandatory header fields required for transporting the metadata, which 82 means a new header needs to be defined based on the SRH to carry the 83 metadata. As for the indication the presence of metadata, 84 [I-D.ietf-spring-sr-service-programming] provides two possible 85 methods, one is to add the indication about the presence of metadata 86 in the semantic of the service SIDs, another is to introduce a 87 protocol identifier field within the MPLS packet as described in 88 [I-D.xu-mpls-payload-protocol-identifier]. 90 To summarize, there're requirements to carry metadata in SR service 91 programming with SR-MPLS data plane and the methods need to be 92 standardized. 94 To carry metadata in SR-MPLS service programming scenario, this 95 document proposes how to utilize the existing mechanism, and 96 considering the ongoing work in MPLS OPEN DT, a new method is 97 introduced as well. 99 2. Metadata in SR-MPLS Data Plane 101 2.1. the RFC8595 Method 103 [RFC8595] provides method to realize SFC in an MPLS network by means 104 of using a logical representation of the Network Service Header (NSH) 105 in an MPLS label stack. 107 [RFC8595] chapter 12 describes how metadata is associated with user 108 data packets or programmed in-band by introducing new eSPL and 109 Metadata Label. As specified in [RFC8595], the methods can only be 110 used for carrying metadata that is "per-SFP" or "per-flow" [RFC8393], 111 but cannot support "per-packet" metadata, where the metadata needs to 112 be carried with payload in each packets. 114 If it's not required to carry metadata and payload together in the 115 packet, similar approaches MAY be used for SR-MPLS service 116 programming. 118 The main ideas of the approaches are described in section 2.1.1 and 119 section 2.1.2 121 2.1.1. Indicating Metadata in User Data Packets 123 +-------------------+ 124 ~ Other Labels ~ 125 +-------------------+ ------------ 126 | Extension = 15 | 127 +-------------------+ 128 | MLI=16 | Metadata 129 +-------------------+ Label Triple 130 | Metadata Label | 131 +-------------------+ ------------ 132 ~ Other ~ 133 | Metadata | 134 ~ Label Triples ~ 135 +-------------------+ 136 | | 137 ~ Payload ~ 138 | | 139 +-------------------+ 141 Figure 1: Figure 1: Indicating Metadata in User Data Packets 143 An extended special-purpose label called the Metadata Label Indicator 144 (MLI) (value 16) is defined in [RFC8595]to indicate the presence of 145 the Metadata Label. 147 The Metadata Label value is an index into a table of metadata that is 148 programmed into the network using in-band or out-of-band mechanisms. 149 The metadata itself is not carried in the packet. 151 If this method is used for SR-MPLS service programming, the Metadata 152 Label Triples(i.e, <15,MLI, Metadata Label>) SHOULD be placed at the 153 bottom of the label stack. 155 2.1.2. In-Band Programming of Metadata 157 +-------------------+ 158 ~ Other Labels ~ 159 +-------------------+ 160 | Extension = 15 | 161 +-------------------+ 162 | MPI=17 | 163 +-------------------+ 164 | Metadata Label | 165 +-------------------+ 166 | | 167 ~ Metadata ~ 168 | | 169 +-------------------+ 171 Figure 2: Figure 2: In-Band Programming of Metadata 173 An extended special-purpose label called the Metadata Present 174 Indicator (MPI) (value 17) is defined in [RFC8595]to indicate the 175 presence of the Metadata Label and the metadata field. 177 If this method is used for SR-MPLS service programming, the Metadata 178 Label Triple(i.e, <15,MPI, Metadata Label>) SHOULD be placed in the 179 bottom of the label stack. 181 Instead of user payload data, metadata is included after the bottom 182 of the MPLS label stack. The metadata is formatted as a TLV as 183 defined in [RFC8595]. 185 2.2. Per Packet Metadata 187 The methods described above can only partially meet the requirements 188 of carrying metadata in SR-MPLS service programming. How to carry 189 the metadata in the user data packets still needs to be solved. 191 This section proposes a method to fulfill the requirements to carry 192 metadata with/without the user payload in the packets for SR-MPLS 193 traffic. 195 Note:There's a an ongoing work in MPLS OPEN DT to figure out the 196 format and processing procedure of the indicator in the label stack 197 and the data carried in/after the bottom of stack. So the method 198 introduced in this section will be modified in the future version to 199 follow the specification of the DT. 201 Firstly, an indicator in the label stack is needed to indicate the 202 presence of metadata after the bottom of stack. This indicator may 203 be an SPL or eSPL. 205 The metadata can be carried for SR-MPLS traffic between the last MPLS 206 label and the MPLS payload, or it can also be carried after the BOS 207 without the payload. In the latter case, the method introduced in 208 section 2.1.2 are no longer necessary. 210 Two types of metadata for SR-MPLS service programming are required: 211 fixed-length metadata and variable-length metadata. 213 The format of fixed-length metadata field is shown in figure 3, 214 where: 216 0 1 2 3 217 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 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Length | Next Header | | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 221 | | 222 | Service Metadata | 223 | | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 Figure 3: Figure 3: Fixed-Length Service Metadata 228 Length: 14. 230 Next Header: This field identifies the type of the header immediately 231 following the metadata field 233 Service Metadata: 14-octet field to carry metadata. 235 The variable-length metadata is a container to carry Service Metadata 236 in the form of Variable-Length Metadata as defined in [RFC8300] for 237 NSH MD Type 2. The format is shown in figure 4, where: 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Length | Next Header | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 244 // Service Metadata // 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 Figure 4: Figure 4: Variable-Length Service Metadata 249 Length: The total length of the Variable-Length Metadata field. 251 Next Header: This field identifies the type of the header immediately 252 following the metadata field 254 Service Metadata: a list of Service Metadata TLV as defined in 255 [RFC8300] for NSH MD Type 2. 257 A potential requirement is to carry the service function path(SFP) 258 identifier in the packets for SR-MPLS service programming. One 259 possible solution is to carry it in the metadata, another is to carry 260 in the label stack. This will discussed in future versions. 262 3. Security Considerations 264 This document does not change the underlying security issues inherent 265 in [I-D.ietf-spring-sr-service-programming]. 267 4. IANA Considerations 269 TBD 271 5. References 273 5.1. Normative References 275 [I-D.ietf-spring-sr-service-programming] 276 Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C., 277 Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and 278 S. Salsano, "Service Programming with Segment Routing", 279 Work in Progress, Internet-Draft, draft-ietf-spring-sr- 280 service-programming-05, 10 September 2021, 281 . 284 [I-D.xu-mpls-payload-protocol-identifier] 285 Xu, X., Assarpour, H., Ma, S., and F. Clad, "MPLS Payload 286 Protocol Identifier", Work in Progress, Internet-Draft, 287 draft-xu-mpls-payload-protocol-identifier-09, 2 September 288 2021, . 291 [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal 292 Cost Multipath Treatment in MPLS Networks", BCP 128, 293 RFC 4928, DOI 10.17487/RFC4928, June 2007, 294 . 296 [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating 297 and Retiring Special-Purpose MPLS Labels", RFC 7274, 298 DOI 10.17487/RFC7274, June 2014, 299 . 301 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 302 Chaining (SFC) Architecture", RFC 7665, 303 DOI 10.17487/RFC7665, October 2015, 304 . 306 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 307 "Network Service Header (NSH)", RFC 8300, 308 DOI 10.17487/RFC8300, January 2018, 309 . 311 [RFC8393] Farrel, A. and J. Drake, "Operating the Network Service 312 Header (NSH) with Next Protocol "None"", RFC 8393, 313 DOI 10.17487/RFC8393, May 2018, 314 . 316 [RFC8595] Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based 317 Forwarding Plane for Service Function Chaining", RFC 8595, 318 DOI 10.17487/RFC8595, June 2019, 319 . 321 5.2. Informative References 323 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 324 Decraene, B., Litkowski, S., and R. Shakir, "Segment 325 Routing with the MPLS Data Plane", RFC 8660, 326 DOI 10.17487/RFC8660, December 2019, 327 . 329 Author's Address 330 Liu Yao 331 ZTE Corporation 332 Nanjing 333 China 335 Email: liu.yao71@zte.com.cn