idnits 2.17.1 draft-ietf-mpls-sfc-encapsulation-02.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 (December 11, 2018) is 1956 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ietf-mpls-sfc-04 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: June 14, 2019 J. Halpern 6 Ericsson 7 W. Henderickx 8 Nokia 9 December 11, 2018 11 MPLS Encapsulation For The SFC NSH 12 draft-ietf-mpls-sfc-encapsulation-02 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 payload. This 20 allows SFC packets using the NSH to be forwarded between SFFs over an 21 MPLS network, and to select one of multiple SFFs in the destination 22 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 June 14, 2019. 41 Copyright Notice 43 Copyright (c) 2018 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 2. MPLS Encapsulation Using an SFF Label . . . . . . . . . . . . 3 60 2.1. MPLS Label Stack Construction at the Sending Node . . . . 3 61 2.2. SFF Label Processing at the Destination Node . . . . . . 4 62 3. Equal Cost Multipath (ECMP) Considerations . . . . . . . . . 4 63 4. Operations, Administration, and Maintenance (OAM) 64 Considerations . . . . . . . . . . . . . . . . . . . . . . . 5 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 70 8.2. Informative References . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Introduction 75 As discussed in [RFC8300], a number of transport encapsulations for 76 the Service Function Chaining (SFC) Network Service Header (NSH) 77 already exist, such as Ethernet, UDP, GRE, and others. 79 This document describes an MPLS transport encapsulation for the NSH 80 and how to use a Service Function Forwarder (SFF) [RFC7665] Label to 81 indicate the presence of the NSH in the MPLS packet payload. This 82 allows SFC packets using the NSH to be forwarded between SFFs in an 83 MPLS transport network, where MPLS is used to interconnect the 84 network nodes that contain one or more SFFs. The label is also used 85 to select between multiple SFFs in the destination MPLS node. 87 SFF Labels are similar to other service labels at the bottom of an 88 MPLS label stack that denote the contents of the MPLS payload being 89 other than IP, such as a layer 2 pseudowire, an IP packet that is 90 routed in a VPN context with a private address, or an Ethernet 91 virtual private wire service. 93 This informational document follows well-established MPLS procedures 94 and does not require any actions by IANA or any new protocol 95 extensions. 97 Note that using the MPLS label stack as a replacement for the SFC 98 NSH, covering use cases that do not require per-packet metadata, is 99 described elsewhere [I-D.ietf-mpls-sfc]. 101 2. MPLS Encapsulation Using an SFF Label 103 The encapsulation is a standard MPLS label stack [RFC3032] with an 104 SFF Label at the bottom of the stack, followed by a NSH as defined by 105 [RFC8300] and the NSH payload. 107 Much like a pseudowire label, an SFF Label is allocated by the 108 downstream receiver of the NSH from its per-platform label space. 110 If a receiving node supports more than one SFF (i.e, more than one 111 SFC forwarding instance), then the SFF Label can be used to select 112 the proper SFF, by having the receiving node advertise more than one 113 SFF Label to its upstream sending nodes as appropriate. 115 The method used by the downstream receiving node to advertise SFF 116 Labels to the upstream sending node is out of scope of this document. 117 That said, a number of methods are possible, such as via a protocol 118 exchange, or via a controller that manages both the sender and the 119 receiver using NETCONF/YANG, BGP, PCEP, etc. These are meant as 120 possible examples and not to constrain the future definition of such 121 advertisement methods. 123 While the SFF label will usually be at the bottom of the label stack, 124 there may be cases where there are additional label stack entries 125 beneath it. For example, when an ACH is carried that applies to the 126 SFF, a GAL [RFC5586] will be in the label stack below the SFF. 127 Similarly, an Entropy Label Indicator/Entropy Label (ELI/EL) 128 [RFC6790] may be carried below the SFF in the label stack. This is 129 identical to the situation with VPN labels. 131 2.1. MPLS Label Stack Construction at the Sending Node 133 When one SFF wishes to send an SFC packet with a NSH to another SFF 134 over an MPLS transport network, a label stack needs to be constructed 135 by the MPLS node that contains the sending SFF in order to transport 136 the packet to the destination MPLS node that contains the receiving 137 SFF. The label stack is constructed as follows: 139 1. Push zero or more labels that are interpreted by the destination 140 MPLS node on to the packet, such as the Generic Associated 141 Channel [RFC5586] label (see Section 4). 143 2. Push the SFF Label to identify the desired SFF in the receiving 144 MPLS node. 146 3. Push zero or more additional labels such that (a) the resulting 147 label stack will cause the packet to be transported to the 148 destination MPLS node, and (b) when the packet arrives at the 149 destination node, either: 151 * the SFF Label will be at the top of the label stack (this is 152 typically the case when penultimate hop popping is used at the 153 penultimate node, or the source and destination nodes are 154 direct neighbors), or 156 * as a part of normal MPLS processing, the SFF Label becomes the 157 top label in the stack before the packet is forwarded to 158 another node and before the packet is dispatched to a higher 159 layer. 161 2.2. SFF Label Processing at the Destination Node 163 The destination MPLS node performs a lookup on the SFF label to 164 retrieve the next-hop context between the SFF and SF, e.g. to 165 retrieve the destination MAC address in the case where native 166 Ethernet encapsulation is used between SFF and SF. How the next-hop 167 context is populated is out of the scope of this document. 169 The receiving MPLS node then pops the SFF Label (and any labels 170 beneath it) so that the destination SFF receives the SFC packet with 171 the NSH is at the top of the packet. 173 3. Equal Cost Multipath (ECMP) Considerations 175 As discussed in [RFC4928] and [RFC7325], there are ECMP 176 considerations for payloads carried by MPLS. 178 Many existing routers use deep packet inspection to examine the 179 payload of an MPLS packet, and if the first nibble of the payload is 180 equal to 0x4 or 0x6, these routers (sometimes incorrectly, as 181 discussed in [RFC4928]) assume that the payload is IPv4 or IPv6 182 respectively, and as a result, perform ECMP load balancing based on 183 (presumed) information present in IP/TCP/UDP payload headers or in a 184 combination of MPLS label stack and (presumed) IP/TCP/UDP payload 185 headers in the packet. 187 For SFC, ECMP may or may not be desirable. To prevent ECMP when it 188 is not desired, the NSH Base Header was carefully constructed so that 189 the NSH could not look like IPv4 or IPv6 based on its first nibble. 190 See Section 2.2 of [RFC8300] for further details. 192 If ECMP is desired when SFC is used with an MPLS transport network, 193 there are two possible options, Entropy [RFC6790] and Flow-Aware 194 Transport [RFC6391] labels. A recommendation between these options, 195 and their proper placement in the label stack, is for future study. 197 4. Operations, Administration, and Maintenance (OAM) Considerations 199 OAM at the SFC Layer is handled by SFC-defined mechanisms [RFC8300]. 200 However, OAM may be required at the MPLS transport layer. If so, 201 then standard MPLS-layer OAM mechanisms such as the Generic 202 Associated Channel [RFC5586] label may be used. 204 5. IANA Considerations 206 This document does not request any actions from IANA. 208 Editorial note to RFC Editor: This section may be removed at your 209 discretion. 211 6. Security Considerations 213 This document describes a method for transporting SFC packets using 214 the NSH over an MPLS transport network. It follows well-established 215 MPLS procedures in widespread operational use and does not define any 216 new protocol elements or allocate any new code points, and is no more 217 or less secure than carrying any other protocol over MPLS. To the 218 MPLS network, the NSH and its contents is simply an opaque payload. 220 Discussion of the security properties of SFC networks can be found in 221 [RFC7665]. Further security discussion regarding the NSH is 222 contained in [RFC8300]. 224 [RFC8300] references a number of transport encapsulations of the NSH, 225 including Ethernet, GRE, UDP, and others. This document simply 226 defines one additional transport encapsulation. The NSH was 227 specially constructed to be agnostic to its transport encapsulation. 228 As as result, in general this additional encapsulation is no more or 229 less secure than carrying the NSH in any other encapsulation. 231 However, it can be argued that carrying the NSH over MPLS is more 232 secure than using other encapsulations, as it is extremely difficult, 233 due to the MPLS architecture, for an attempted attacker to inject 234 unexpected MPLS packets into a network, as MPLS networks do not by 235 design accept MPLS packets from external interfaces, and an attacker 236 would need knowledge of the specific labels allocated by control and/ 237 or management plane protocols. Thus, an attacker attempting to spoof 238 MPLS-encapsulated NSH packets would require insider knowledge of the 239 network's control and management planes and a way to inject packets 240 into internal interfaces. This is compared to, for example, NSH over 241 UDP over IP, which could be injected into any external interface in a 242 network that was not properly configured to filter out such packets 243 at the ingress. 245 7. Acknowledgements 247 The authors would like to thank Jim Guichard, Eric Rosen, Med 248 Boucadair, Sasha Vainshtein, Jeff Tantsura, Anoop Ghanwani, John 249 Drake, and Loa Andersson for their reviews and comments. 251 8. References 253 8.1. Normative References 255 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 256 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 257 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 258 . 260 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 261 "Network Service Header (NSH)", RFC 8300, 262 DOI 10.17487/RFC8300, January 2018, 263 . 265 8.2. Informative References 267 [I-D.ietf-mpls-sfc] 268 Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based 269 Forwarding Plane for Service Function Chaining", draft- 270 ietf-mpls-sfc-04 (work in progress), November 2018. 272 [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal 273 Cost Multipath Treatment in MPLS Networks", BCP 128, 274 RFC 4928, DOI 10.17487/RFC4928, June 2007, 275 . 277 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 278 "MPLS Generic Associated Channel", RFC 5586, 279 DOI 10.17487/RFC5586, June 2009, 280 . 282 [RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., 283 Regan, J., and S. Amante, "Flow-Aware Transport of 284 Pseudowires over an MPLS Packet Switched Network", 285 RFC 6391, DOI 10.17487/RFC6391, November 2011, 286 . 288 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 289 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 290 RFC 6790, DOI 10.17487/RFC6790, November 2012, 291 . 293 [RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A., 294 and C. Pignataro, "MPLS Forwarding Compliance and 295 Performance Requirements", RFC 7325, DOI 10.17487/RFC7325, 296 August 2014, . 298 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 299 Chaining (SFC) Architecture", RFC 7665, 300 DOI 10.17487/RFC7665, October 2015, 301 . 303 Authors' Addresses 305 Andrew G. Malis 306 Huawei Technologies 308 Email: agmalis@gmail.com 310 Stewart Bryant 311 Huawei Technologies 313 Email: stewart.bryant@gmail.com 315 Joel M. Halpern 316 Ericsson 318 Email: joel.halpern@ericsson.com 320 Wim Henderickx 321 Nokia 323 Email: wim.henderickx@nokia.com