idnits 2.17.1 draft-ietf-mpls-sfc-encapsulation-03.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 (February 28, 2019) is 1877 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-07 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-sfc-05 Summary: 0 errors (**), 0 flaws (~~), 3 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 1, 2019 J. Halpern 6 Ericsson 7 W. Henderickx 8 Nokia 9 February 28, 2019 11 MPLS Transport Encapsulation For The SFC NSH 12 draft-ietf-mpls-sfc-encapsulation-03 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 1, 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 . . . . . . . . . . . . . . . . . . . . . . 7 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 71 8.2. Informative References . . . . . . . . . . . . . . . . . 8 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. 234 If ECMP is desired when SFC is used with an MPLS transport network, 235 there are two possible options, Entropy [RFC6790] and Flow-Aware 236 Transport [RFC6391] labels. A recommendation between these options, 237 and their proper placement in the label stack, is for future study. 239 4. Operations, Administration, and Maintenance (OAM) Considerations 241 OAM at the SFC Layer is handled by SFC-defined mechanisms [RFC8300]. 242 However, OAM may be required at the MPLS transport layer. If so, 243 then standard MPLS-layer OAM mechanisms may be used at the transport 244 label layer (the labels above the SFF label). 246 5. IANA Considerations 248 This document does not request any actions from IANA. 250 Editorial note to RFC Editor: This section may be removed at your 251 discretion. 253 6. Security Considerations 255 This document describes a method for transporting SFC packets using 256 the NSH over an MPLS transport network. It follows well-established 257 MPLS procedures in widespread operational use and does not define any 258 new protocol elements or allocate any new code points, and is no more 259 or less secure than carrying any other protocol over MPLS. To the 260 MPLS network, the NSH and its contents is simply an opaque payload. 262 Discussion of the security properties of SFC networks can be found in 263 [RFC7665]. Further security discussion regarding the NSH is 264 contained in [RFC8300]. 266 [RFC8300] references a number of transport encapsulations of the NSH, 267 including Ethernet, GRE, UDP, and others. This document simply 268 defines one additional transport encapsulation. The NSH was 269 specially constructed to be agnostic to its transport encapsulation. 270 As as result, in general this additional encapsulation is no more or 271 less secure than carrying the NSH in any other encapsulation. 273 However, it can be argued that carrying the NSH over MPLS is more 274 secure than using other encapsulations, as it is extremely difficult, 275 due to the MPLS architecture, for an attempted attacker to inject 276 unexpected MPLS packets into a network, as MPLS networks do not by 277 design accept MPLS packets from external interfaces, and an attacker 278 would need knowledge of the specific labels allocated by control and/ 279 or management plane protocols. Thus, an attacker attempting to spoof 280 MPLS-encapsulated NSH packets would require insider knowledge of the 281 network's control and management planes and a way to inject packets 282 into internal interfaces. This is compared to, for example, NSH over 283 UDP over IP, which could be injected into any external interface in a 284 network that was not properly configured to filter out such packets 285 at the ingress. 287 7. Acknowledgements 289 The authors would like to thank Jim Guichard, Eric Rosen, Med 290 Boucadair, Sasha Vainshtein, Jeff Tantsura, Anoop Ghanwani, John 291 Drake, Loa Andersson, Carlos Pignataro, and Christian Hopps for their 292 reviews and comments. 294 8. References 296 8.1. Normative References 298 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 299 Requirement Levels", BCP 14, RFC 2119, 300 DOI 10.17487/RFC2119, March 1997, 301 . 303 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 304 Label Switching Architecture", RFC 3031, 305 DOI 10.17487/RFC3031, January 2001, 306 . 308 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 309 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 310 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 311 . 313 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 314 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 315 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 316 2009, . 318 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 319 Chaining (SFC) Architecture", RFC 7665, 320 DOI 10.17487/RFC7665, October 2015, 321 . 323 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 324 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 325 May 2017, . 327 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 328 "Network Service Header (NSH)", RFC 8300, 329 DOI 10.17487/RFC8300, January 2018, 330 . 332 8.2. Informative References 334 [I-D.ietf-bess-nsh-bgp-control-plane] 335 Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. 336 Jalil, "BGP Control Plane for NSH SFC", draft-ietf-bess- 337 nsh-bgp-control-plane-07 (work in progress), February 338 2019. 340 [I-D.ietf-mpls-sfc] 341 Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based 342 Forwarding Plane for Service Function Chaining", draft- 343 ietf-mpls-sfc-05 (work in progress), February 2019. 345 [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal 346 Cost Multipath Treatment in MPLS Networks", BCP 128, 347 RFC 4928, DOI 10.17487/RFC4928, June 2007, 348 . 350 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 351 "MPLS Generic Associated Channel", RFC 5586, 352 DOI 10.17487/RFC5586, June 2009, 353 . 355 [RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., 356 Regan, J., and S. Amante, "Flow-Aware Transport of 357 Pseudowires over an MPLS Packet Switched Network", 358 RFC 6391, DOI 10.17487/RFC6391, November 2011, 359 . 361 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 362 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 363 RFC 6790, DOI 10.17487/RFC6790, November 2012, 364 . 366 [RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A., 367 and C. Pignataro, "MPLS Forwarding Compliance and 368 Performance Requirements", RFC 7325, DOI 10.17487/RFC7325, 369 August 2014, . 371 Authors' Addresses 373 Andrew G. Malis 374 Huawei Technologies 376 Email: agmalis@gmail.com 377 Stewart Bryant 378 Huawei Technologies 380 Email: stewart.bryant@gmail.com 382 Joel M. Halpern 383 Ericsson 385 Email: joel.halpern@ericsson.com 387 Wim Henderickx 388 Nokia 390 Email: wim.henderickx@nokia.com