idnits 2.17.1 draft-ietf-mpls-sfc-encapsulation-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 : ---------------------------------------------------------------------------- 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 04, 2018) is 1971 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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 7, 2019 J. Halpern 6 Ericsson 7 W. Henderickx 8 Nokia 9 December 04, 2018 11 MPLS Encapsulation for SFC NSH 12 draft-ietf-mpls-sfc-encapsulation-01 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 the selection between 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 June 7, 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 . . . . . . . . . . . . . . . . . . . . . . . 4 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 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 also describes how to use a Service Function Forwarder (SFF) 81 [RFC7665] Label to indicate the presence of the NSH in the MPLS 82 packet payload. This allows SFC packets using the NSH to be 83 forwarded between SFFs in an MPLS transport network, where MPLS is 84 used to interconnect the network nodes that contain one or more SFFs. 85 The label is also used to select between multiple SFFs in the 86 destination MPLS node. 88 SFF Labels are similar to other service labels at the bottom of an 89 MPLS label stack that denote the contents of the MPLS payload being 90 other than IP, such as a layer 2 pseudowire, an IP packet that is 91 routed in a VPN context with a private address, or an Ethernet 92 virtual private wire service. 94 This informational document follows well-established MPLS procedures 95 and does not require any actions by IANA or any new protocol 96 extensions. 98 2. MPLS Encapsulation Using an SFF Label 100 The encapsulation is a standard MPLS label stack [RFC3032] with an 101 SFF Label at the bottom of the stack, followed by a NSH as defined by 102 [RFC8300] and the NSH payload. 104 Much like a pseudowire label, an SFF Label is allocated by the 105 downstream receiver of the NSH from its per-platform label space. 107 If a receiving node supports more than one SFF (i.e, more than one 108 SFC forwarding instance), then the SFF Label can be used to select 109 the proper SFF, by having the receiving node advertise more than one 110 SFF Label to its upstream sending nodes as appropriate. 112 The method used by the downstream receiving node to advertise SFF 113 Labels to the upstream sending node is out of scope of this document. 114 That said, a number of methods are possible, such as via a protocol 115 exchange, or via a controller that manages both the sender and the 116 receiver using NETCONF/YANG, BGP, PCEP, etc. These are meant as 117 possible examples and not to constrain the future definition of such 118 advertisement methods. 120 While the SFF label will usually be at the bottom of the label stack, 121 there may be cases where there are additional label stack entries 122 beneath it. For example, when an ACH is carried that applies to the 123 SFF, a GAL [RFC5586] will be in the label stack below the SFF. 124 Similarly, an ELI/EL [RFC6790] may be carried below the SFF in the 125 label stack. This is identical to the situation with VPN labels. 127 2.1. MPLS Label Stack Construction at the Sending Node 129 When one SFF wishes to send an SFC packet with the NSH to another SFF 130 over an MPLS transport network, a label stack needs to be constructed 131 by the MPLS node that contains the sending SFF in order to transport 132 the packet to the destination MPLS node that contains the receiving 133 SFF. The label can be constructed as follows: 135 1. Push on zero or more labels that are interpreted by the 136 destination MPLS node, such as the Generic Associated Channel 137 [RFC5586] label (see OAM Considerations below). 139 2. Push on the SFF Label to identify the desired SFF in the 140 receiving MPLS node. 142 3. Push on zero or more additional labels such that (a) the 143 resulting label stack will cause the packet to be transported to 144 the destination MPLS node, and (b) when the packet arrives at the 145 destination node, either: 147 * the SFF Label will be at the top of the label stack, or 149 * the SFF Label will rise to the top of the label stack before 150 the packet is forwarded to another node and before the packet 151 is dispatched to a higher layer. 153 2.2. SFF Label Processing at the Destination Node 155 The destination MPLS node performs a lookup on the SFF label to 156 retrieve the next-hop context between the SFF and SF, e.g. to 157 retrieve the destination MAC address in the case where native 158 Ethernet encapsulation is used between SFF and SF. How the next-hop 159 context is populated is out of the scope of this document. 161 The receiving MPLS node then pops the SFF Label (and any labels 162 beneath it) so that the destination SFF receives the SFC packet with 163 the NSH is at the top of the packet. 165 3. Equal Cost Multipath (ECMP) Considerations 167 As discussed in [RFC4928] and [RFC7325], there are ECMP 168 considerations for payloads carried by MPLS. 170 Many existing routers use deep packet inspection to examine the 171 payload of an MPLS packet, and if the first nibble of the payload is 172 equal to 0x4 or 0x6, these routers (sometimes incorrectly, as 173 discussed in [RFC4928]) assume that the payload is IPv4 or IPv6 174 respectively, and as a result, perform ECMP load balancing based on 175 (presumed) information present in IP/TCP/UDP payload headers or in a 176 combination of MPLS label stack and (presumed) IP/TCP/UDP payload 177 headers in the packet. 179 For SFC, ECMP may or may not be desirable. To prevent unintended 180 ECMP when it is not desired, the NSH Base Header was carefully 181 constructed so that the NSH could not look like IPv4 or IPv6 based on 182 its first nibble. See Section 2.2 of [RFC8300] for further details. 184 If ECMP is desired when SFC is used with an MPLS transport network, 185 there are two possible options, Entropy [RFC6790] and Flow-Aware 186 Transport [RFC6391] labels. A recommendation between these options, 187 and their proper placement in the label stack, is for future study. 189 4. Operations, Administration, and Maintenance (OAM) Considerations 191 OAM at the SFC Layer is handled by SFC-defined mechanisms [RFC8300]. 192 However, OAM may be required at the MPLS transport layer. If so, 193 then standard MPLS-layer OAM mechanisms such as the Generic 194 Associated Channel [RFC5586] label may be used. 196 5. IANA Considerations 198 This document does not request any actions from IANA. 200 Editorial note to RFC Editor: This section may be removed at your 201 discretion. 203 6. Security Considerations 205 This document describes a method for transporting SFC packets using 206 the NSH over an MPLS transport network. It follows well-established 207 MPLS procedures in widespread operational use and does not define any 208 new protocol elements or allocate any new code points, and is no more 209 or less secure than carrying any other protocol over MPLS. To the 210 MPLS network, the NSH and its contents is simply an opaque payload. 212 Discussion of the security properties of SFC networks can be found in 213 [RFC7665]. Further security discussion regarding the NSH is 214 contained in [RFC8300]. 216 [RFC8300] references a number of transport encapsulations of the NSH, 217 including Ethernet, GRE, UDP, and others. This document simply 218 defines one additional transport encapsulation. The NSH was 219 specially constructed to be agnostic to its transport encapsulation. 220 As as result, in general this additional encapsulation is no more or 221 less secure than carrying the NSH in any other encapsulation. 223 However, it can be argued that carrying the NSH over MPLS is more 224 secure than using other encapsulations, as it is extremely difficult, 225 due to the MPLS architecture, for an attempted attacker to inject 226 unexpected MPLS packets into a network, as MPLS networks do not by 227 design accept MPLS packets from external interfaces, and an attacker 228 would need knowledge of the specific labels allocated by control and/ 229 or management plane protocols. Thus, an attacker attempting to spoof 230 MPLS-encapsulated NSH packets would require insider knowledge of the 231 network's control and management planes and a way to inject packets 232 into internal interfaces. This is compared to, for example, NSH over 233 UDP over IP, which could be injected into any external interface in a 234 network that was not properly configured to filter out such packets 235 at the ingress. 237 7. Acknowledgements 239 The authors would like to thank Jim Guichard, Eric Rosen, Med 240 Boucadair, Sasha Vainshtein, and Jeff Tantsura for their reviews and 241 comments. 243 8. References 245 8.1. Normative References 247 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 248 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 249 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 250 . 252 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 253 "Network Service Header (NSH)", RFC 8300, 254 DOI 10.17487/RFC8300, January 2018, 255 . 257 8.2. Informative References 259 [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal 260 Cost Multipath Treatment in MPLS Networks", BCP 128, 261 RFC 4928, DOI 10.17487/RFC4928, June 2007, 262 . 264 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 265 "MPLS Generic Associated Channel", RFC 5586, 266 DOI 10.17487/RFC5586, June 2009, 267 . 269 [RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., 270 Regan, J., and S. Amante, "Flow-Aware Transport of 271 Pseudowires over an MPLS Packet Switched Network", 272 RFC 6391, DOI 10.17487/RFC6391, November 2011, 273 . 275 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 276 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 277 RFC 6790, DOI 10.17487/RFC6790, November 2012, 278 . 280 [RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A., 281 and C. Pignataro, "MPLS Forwarding Compliance and 282 Performance Requirements", RFC 7325, DOI 10.17487/RFC7325, 283 August 2014, . 285 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 286 Chaining (SFC) Architecture", RFC 7665, 287 DOI 10.17487/RFC7665, October 2015, 288 . 290 Authors' Addresses 292 Andrew G. Malis 293 Huawei Technologies 295 Email: agmalis@gmail.com 297 Stewart Bryant 298 Huawei Technologies 300 Email: stewart.bryant@gmail.com 302 Joel M. Halpern 303 Ericsson 305 Email: joel.halpern@ericsson.com 307 Wim Henderickx 308 Nokia 310 Email: wim.henderickx@nokia.com