idnits 2.17.1 draft-ietf-mpls-sfc-encapsulation-04.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 (March 21, 2019) is 1863 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-bess-nsh-bgp-control-plane-09 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 A. Malis 3 Internet-Draft S. Bryant 4 Intended status: Informational Huawei Technologies 5 Expires: September 22, 2019 J. Halpern 6 Ericsson 7 W. Henderickx 8 Nokia 9 March 21, 2019 11 MPLS Transport Encapsulation For The SFC NSH 12 draft-ietf-mpls-sfc-encapsulation-04 14 Abstract 16 This document describes how to use a Service Function Forwarder (SFF) 17 Label (similar to a pseudowire label or VPN label) to indicate the 18 presence of a Service Function Chaining (SFC) Network Service Header 19 (NSH) between an MPLS label stack and the packet original packet/ 20 frame. This allows SFC packets using the NSH to be forwarded between 21 SFFs over an MPLS network, and to select one of multiple SFFs in the 22 destination MPLS node. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 22, 2019. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. MPLS Encapsulation Using an SFF Label . . . . . . . . . . . . 3 61 2.1. MPLS Label Stack Construction at the Sending Node . . . . 4 62 2.2. SFF Label Processing at the Destination Node . . . . . . 5 63 3. Equal Cost Multipath (ECMP) Considerations . . . . . . . . . 5 64 4. Operations, Administration, and Maintenance (OAM) 65 Considerations . . . . . . . . . . . . . . . . . . . . . . . 6 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 71 8.2. Informative References . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 As discussed in [RFC8300], a number of transport encapsulations for 77 the Service Function Chaining (SFC) Network Service Header (NSH) 78 already exist, such as Ethernet, UDP, GRE, and others. 80 This document describes an MPLS transport encapsulation for the NSH 81 and how to use a Service Function Forwarder (SFF) [RFC7665] Label to 82 indicate the presence of the NSH in the MPLS packet payload. This 83 allows SFC packets using the NSH to be forwarded between SFFs in an 84 MPLS transport network, where MPLS is used to interconnect the 85 network nodes that contain one or more SFFs. The label is also used 86 to select between multiple SFFs in the destination MPLS node. 88 This encapsulation is equivalent from an SFC perspective to other 89 transport encapsulations of packets using the NSH. This can be 90 illustrated by adding an additional line to the example of a next-hop 91 SPI/SI-to-network overlay network locator mapping in Table 1 of 92 [RFC8300]: 94 +------+------+---------------------+-------------------------+ 95 | SPI | SI | Next Hop(s) | Transport Encapsulation | 96 +------+------+---------------------+-------------------------+ 97 | 25 | 220 | Label 5467 | MPLS | 98 +------+------+---------------------+-------------------------+ 100 Table 1: Extension to RFC 8300 Table 1 102 SFF Labels are similar to other service labels at the bottom of an 103 MPLS label stack that denote the contents of the MPLS payload being 104 other than a normally routed IP packet, such as a layer 2 pseudowire, 105 an IP packet that is routed in a VPN context with a private address, 106 or an Ethernet virtual private wire service. 108 This informational document follows well-established MPLS procedures 109 and does not require any actions by IANA or any new protocol 110 extensions. 112 Note that using the MPLS label stack as a replacement for the SFC 113 NSH, covering use cases that do not require per-packet metadata, is 114 described elsewhere [I-D.ietf-mpls-sfc]. 116 1.1. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 120 "OPTIONAL" in this document are to be interpreted as described in BCP 121 14 [RFC2119] [RFC8174] when, and only when, they appear in all 122 capitals, as shown here. 124 2. MPLS Encapsulation Using an SFF Label 126 The encapsulation is a standard MPLS label stack [RFC3032] with an 127 SFF Label at the bottom of the stack, followed by a NSH as defined by 128 [RFC8300] and the NSH original packet/frame. 130 Much like a pseudowire label, an SFF Label MUST be allocated by the 131 downstream receiver of the NSH from its per-platform label space, 132 since the meaning of the label is identical independent of which 133 incoming interface it is received [RFC3031]. 135 If a receiving node supports more than one SFF (i.e., more than one 136 SFC forwarding instance), then the SFF Label can be used to select 137 the proper SFF, by having the receiving node advertise more than one 138 SFF Label to its upstream sending nodes as appropriate. 140 The method used by the downstream receiving node to advertise SFF 141 Labels to the upstream sending node is out of scope of this document. 143 That said, a number of methods are possible, such as via a protocol 144 exchange, or via a controller that manages both the sender and the 145 receiver using NETCONF/YANG, BGP, PCEP, etc. One such BGP-based 146 method has already been defined, and is documented in 147 [I-D.ietf-bess-nsh-bgp-control-plane]. This does not constrain the 148 further definition of other such advertisement methods in the future. 150 While the SFF label will usually be at the bottom of the label stack, 151 there may be cases where there are additional label stack entries 152 beneath it. For example, when an Associated Channel Header (ACH) is 153 carried that applies to the SFF, a Generic Associated Channel Label 154 (GAL) [RFC5586] will be in the label stack below the SFF. Similarly, 155 an Entropy Label Indicator/Entropy Label (ELI/EL) [RFC6790] may be 156 carried below the SFF in the label stack. This is identical to the 157 situation with VPN labels. 159 This document does not define a use for the Traffic Class (TC) field 160 [RFC5462] (formerly known as the Experimental Use (EXP) bits 161 [RFC3032]) in the SFF Label. 163 2.1. MPLS Label Stack Construction at the Sending Node 165 When one SFF wishes to send an SFC packet with a NSH to another SFF 166 over an MPLS transport network, a label stack needs to be constructed 167 by the MPLS node that contains the sending SFF in order to transport 168 the packet to the destination MPLS node that contains the receiving 169 SFF. The label stack is constructed as follows: 171 1. Push zero or more labels that are interpreted by the destination 172 MPLS node on to the packet, such as the Generic Associated 173 Channel [RFC5586] label (see Section 4). The TTL for these 174 labels is set according to the relevant standards that define 175 these labels. 177 2. Push the SFF Label to identify the desired SFF in the receiving 178 MPLS node. The TTL for this MPLS label MUST be set to one to 179 avoid mis-forwarding. 181 3. Push zero or more additional labels such that (a) the resulting 182 label stack will cause the packet to be transported to the 183 destination MPLS node, and (b) when the packet arrives at the 184 destination node, either: 186 * the SFF Label will be at the top of the label stack (this is 187 typically the case when penultimate hop popping is used at the 188 penultimate node, or the source and destination nodes are 189 direct neighbors), or 191 * as a part of normal MPLS processing, the SFF Label becomes the 192 top label in the stack before the packet is forwarded to 193 another node and before the packet is dispatched to a higher 194 layer. 196 The TTL for these labels is set by configuration, or set to the 197 defaults for normal MPLS operation in the network. 199 2.2. SFF Label Processing at the Destination Node 201 The destination MPLS node performs a lookup on the SFF label to 202 retrieve the next-hop context between the SFF and SF, e.g. to 203 retrieve the destination MAC address in the case where native 204 Ethernet encapsulation is used between SFF and SF. How the next-hop 205 context is populated is out of the scope of this document. 207 The receiving SFF SHOULD check that the received SFF label has a TTL 208 of 1 upon receipt. Any other values indicate a likely error 209 condition and SHOULD result in discarding the packet. 211 The receiving MPLS node then pops the SFF Label (and any labels 212 beneath it) so that the destination SFF receives the SFC packet with 213 the NSH is at the top of the packet. 215 3. Equal Cost Multipath (ECMP) Considerations 217 As discussed in [RFC4928] and [RFC7325], there are ECMP 218 considerations for payloads carried by MPLS. 220 Many existing routers use deep packet inspection to examine the 221 payload of an MPLS packet, and if the first nibble of the payload is 222 equal to 0x4 or 0x6, these routers (sometimes incorrectly, as 223 discussed in [RFC4928]) assume that the payload is IPv4 or IPv6 224 respectively, and as a result, perform ECMP load balancing based on 225 (presumed) information present in IP/TCP/UDP payload headers or in a 226 combination of MPLS label stack and (presumed) IP/TCP/UDP payload 227 headers in the packet. 229 For SFC, ECMP may or may not be desirable. To prevent ECMP when it 230 is not desired, the NSH Base Header was carefully constructed so that 231 the NSH could not look like IPv4 or IPv6 based on its first nibble. 232 See Section 2.2 of [RFC8300] for further details. Accordingly, the 233 default behavior for MPLS-encapsulated SFC is to not use ECMP. 235 If ECMP is desired when SFC is used with an MPLS transport network, 236 there are two possible options, Entropy [RFC6790] and Flow-Aware 237 Transport [RFC6391] labels. A recommendation between these options, 238 and their proper placement in the label stack, is for future study. 240 4. Operations, Administration, and Maintenance (OAM) Considerations 242 OAM at the SFC Layer is handled by SFC-defined mechanisms [RFC8300]. 243 However, OAM may be required at the MPLS transport layer. If so, 244 then standard MPLS-layer OAM mechanisms may be used at the transport 245 label layer (the labels above the SFF label). 247 5. IANA Considerations 249 This document does not request any actions from IANA. 251 Editorial note to RFC Editor: This section may be removed at your 252 discretion. 254 6. Security Considerations 256 This document describes a method for transporting SFC packets using 257 the NSH over an MPLS transport network. It follows well-established 258 MPLS procedures in widespread operational use and does not define any 259 new protocol elements or allocate any new code points, and is no more 260 or less secure than carrying any other protocol over MPLS. To the 261 MPLS network, the NSH and its contents is simply an opaque payload. 263 In addition, the security considerations in [I-D.ietf-mpls-sfc] also 264 apply to this document. 266 7. Acknowledgements 268 The authors would like to thank Jim Guichard, Eric Rosen, Med 269 Boucadair, Sasha Vainshtein, Jeff Tantsura, Anoop Ghanwani, John 270 Drake, Loa Andersson, Carlos Pignataro, Christian Hopps, and Benjamin 271 Kaduk for their reviews and comments. 273 8. References 275 8.1. Normative References 277 [I-D.ietf-mpls-sfc] 278 Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based 279 Forwarding Plane for Service Function Chaining", draft- 280 ietf-mpls-sfc-07 (work in progress), March 2019. 282 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 283 Requirement Levels", BCP 14, RFC 2119, 284 DOI 10.17487/RFC2119, March 1997, 285 . 287 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 288 Label Switching Architecture", RFC 3031, 289 DOI 10.17487/RFC3031, January 2001, 290 . 292 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 293 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 294 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 295 . 297 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 298 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 299 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 300 2009, . 302 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 303 Chaining (SFC) Architecture", RFC 7665, 304 DOI 10.17487/RFC7665, October 2015, 305 . 307 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 308 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 309 May 2017, . 311 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 312 "Network Service Header (NSH)", RFC 8300, 313 DOI 10.17487/RFC8300, January 2018, 314 . 316 8.2. Informative References 318 [I-D.ietf-bess-nsh-bgp-control-plane] 319 Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. 320 Jalil, "BGP Control Plane for NSH SFC", draft-ietf-bess- 321 nsh-bgp-control-plane-09 (work in progress), March 2019. 323 [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal 324 Cost Multipath Treatment in MPLS Networks", BCP 128, 325 RFC 4928, DOI 10.17487/RFC4928, June 2007, 326 . 328 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 329 "MPLS Generic Associated Channel", RFC 5586, 330 DOI 10.17487/RFC5586, June 2009, 331 . 333 [RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., 334 Regan, J., and S. Amante, "Flow-Aware Transport of 335 Pseudowires over an MPLS Packet Switched Network", 336 RFC 6391, DOI 10.17487/RFC6391, November 2011, 337 . 339 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 340 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 341 RFC 6790, DOI 10.17487/RFC6790, November 2012, 342 . 344 [RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A., 345 and C. Pignataro, "MPLS Forwarding Compliance and 346 Performance Requirements", RFC 7325, DOI 10.17487/RFC7325, 347 August 2014, . 349 Authors' Addresses 351 Andrew G. Malis 352 Huawei Technologies 354 Email: agmalis@gmail.com 356 Stewart Bryant 357 Huawei Technologies 359 Email: stewart.bryant@gmail.com 361 Joel M. Halpern 362 Ericsson 364 Email: joel.halpern@ericsson.com 366 Wim Henderickx 367 Nokia 369 Email: wim.henderickx@nokia.com