idnits 2.17.1 draft-ietf-mpls-sfc-encapsulation-00.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 (November 05, 2018) is 1997 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-nvo3-vxlan-gpe-06 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: May 9, 2019 J. Halpern 6 Ericsson 7 W. Henderickx 8 Nokia 9 November 05, 2018 11 MPLS Encapsulation for SFC NSH 12 draft-ietf-mpls-sfc-encapsulation-00 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 May 9, 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 . . . . . . . . . . . . . . . . . . . . . . 5 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 70 8.2. Informative References . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 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, GRE [RFC2784], and VXLAN-GPE 78 [I-D.ietf-nvo3-vxlan-gpe]. 80 This document describes an MPLS transport encapsulation for the NSH, 81 and also describes how to use a Service Function Forwarder (SFF) 82 [RFC7665] Label to indicate the presence of the NSH in the MPLS 83 packet payload. This allows SFC packets using the NSH to be 84 forwarded between SFFs in an MPLS transport network, where MPLS is 85 used to interconnect the network nodes that contain one or more SFFs. 86 The label is also used to select between multiple SFFs in the 87 destination MPLS node. 89 SFF Labels are similar to other service labels at the bottom of an 90 MPLS label stack that denote the contents of the MPLS payload being 91 other than IP, such as a layer 2 pseudowire, an IP packet that is 92 routed in a VPN context with a private address, or an Ethernet 93 virtual private wire service. 95 This informational document follows well-established MPLS procedures 96 and does not require any actions by IANA or any new protocol 97 extensions. 99 2. MPLS Encapsulation Using an SFF Label 101 The encapsulation is a standard MPLS label stack [RFC3032] with an 102 SFF Label at the bottom of the stack, followed by a NSH as defined by 103 [RFC8300] and the NSH payload. 105 Much like a pseudowire label, an SFF Label is allocated by the 106 downstream receiver of the NSH from its per-platform label space. 108 If a receiving node supports more than one SFF (i.e, more than one 109 SFC forwarding instance), then the SFF Label can be used to select 110 the proper SFF, by having the receiving node advertise more than one 111 SFF Label to its upstream sending nodes as appropriate. 113 The method used by the downstream receiving node to advertise SFF 114 Labels to the upstream sending node is out of scope of this document. 115 That said, a number of methods are possible, such as via a protocol 116 exchange, or via a controller that manages both the sender and the 117 receiver using NETCONF/YANG, BGP, PCEP, etc. These are meant as 118 possible examples and not to constrain the future definition of such 119 advertisement methods. 121 While the SFF label will usually be at the bottom of the label stack, 122 there may be cases where there are additional label stack entries 123 beneath it. For example, when an ACH is carried that applies to the 124 SFF, a GAL [RFC5586] will be in the label stack below the SFF. 125 Similarly, an ELI/EL [RFC6790] may be carried below the SFF in the 126 label stack. This is identical to the situation with VPN labels. 128 2.1. MPLS Label Stack Construction at the Sending Node 130 When one SFF wishes to send an SFC packet with the NSH to another SFF 131 over an MPLS transport network, a label stack needs to be constructed 132 by the MPLS node that contains the sending SFF in order to transport 133 the packet to the destination MPLS node that contains the receiving 134 SFF. The label can be constructed as follows: 136 1. Push on zero or more labels that are interpreted by the 137 destination MPLS node, such as the Generic Associated Channel 138 [RFC5586] label (see OAM Considerations below). 140 2. Push on the SFF Label to identify the desired SFF in the 141 receiving MPLS node. 143 3. Push on zero or more additional labels such that (a) the 144 resulting label stack will cause the packet to be transported to 145 the destination MPLS node, and (b) when the packet arrives at the 146 destination node, either: 148 * the SFF Label will be at the top of the label stack, or 150 * the SFF Label will rise to the top of the label stack before 151 the packet is forwarded to another node and before the packet 152 is dispatched to a higher layer. 154 2.2. SFF Label Processing at the Destination Node 156 The destination MPLS node performs a lookup on the SFF label to 157 retrieve the next-hop context between the SFF and SF, e.g. to 158 retrieve the destination MAC address in the case where native 159 Ethernet encapsulation is used between SFF and SF. How the next-hop 160 context is populated is out of the scope of this document. 162 The receiving MPLS node then pops the SFF Label (and any labels 163 beneath it) so that the destination SFF receives the SFC packet with 164 the NSH is at the top of the packet. 166 3. Equal Cost Multipath (ECMP) Considerations 168 As discussed in [RFC4928] and [RFC7325], there are ECMP 169 considerations for payloads carried by MPLS. 171 Many existing routers use deep packet inspection to examine the 172 payload of an MPLS packet, and if the first nibble of the payload is 173 equal to 0x4 or 0x6, these routers (sometimes incorrectly, as 174 discussed in [RFC4928]) assume that the payload is IPv4 or IPv6 175 respectively, and as a result, perform ECMP load balancing based on 176 (presumed) information present in IP/TCP/UDP payload headers or in a 177 combination of MPLS label stack and (presumed) IP/TCP/UDP payload 178 headers in the packet. 180 For SFC, ECMP may or may not be desirable. To prevent unintended 181 ECMP when it is not desired, the NSH Base Header was carefully 182 constructed so that the NSH could not look like IPv4 or IPv6 based on 183 its first nibble. See Section 2.2 of [RFC8300] for further details. 185 If ECMP is desired when SFC is used with an MPLS transport network, 186 there are two possible options, Entropy [RFC6790] and Flow-Aware 187 Transport [RFC6391] labels. A recommendation between these options, 188 and their proper placement in the label stack, is for future study. 190 4. Operations, Administration, and Maintenance (OAM) Considerations 192 OAM at the SFC Layer is handled by SFC-defined mechanisms [RFC8300]. 193 However, OAM may be required at the MPLS transport layer. If so, 194 then standard MPLS-layer OAM mechanisms such as the Generic 195 Associated Channel [RFC5586] label may be used. 197 5. IANA Considerations 199 This document does not request any actions from IANA. 201 Editorial note to RFC Editor: This section may be removed at your 202 discretion. 204 6. Security Considerations 206 This document describes a method for transporting SFC packets using 207 the NSH over an MPLS transport network. It follows well-established 208 MPLS procedures and does not define any new protocol elements or 209 allocate any new code points. It is therefore operationally 210 equivalent to other existing SFC transport encapsulations as defined 211 in [RFC8300]. As such, it should have no effect on SFC security as 212 already discussed in Section 8 of [RFC8300]. 214 7. Acknowledgements 216 The authors would like to thank Jim Guichard, Eric Rosen, Med 217 Boucadair, Sasha Vainshtein, and Jeff Tantsura for their reviews and 218 comments. 220 8. References 222 8.1. Normative References 224 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 225 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 226 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 227 . 229 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 230 "Network Service Header (NSH)", RFC 8300, 231 DOI 10.17487/RFC8300, January 2018, 232 . 234 8.2. Informative References 236 [I-D.ietf-nvo3-vxlan-gpe] 237 Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol 238 Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-06 (work 239 in progress), April 2018. 241 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 242 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 243 DOI 10.17487/RFC2784, March 2000, 244 . 246 [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal 247 Cost Multipath Treatment in MPLS Networks", BCP 128, 248 RFC 4928, DOI 10.17487/RFC4928, June 2007, 249 . 251 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 252 "MPLS Generic Associated Channel", RFC 5586, 253 DOI 10.17487/RFC5586, June 2009, 254 . 256 [RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., 257 Regan, J., and S. Amante, "Flow-Aware Transport of 258 Pseudowires over an MPLS Packet Switched Network", 259 RFC 6391, DOI 10.17487/RFC6391, November 2011, 260 . 262 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 263 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 264 RFC 6790, DOI 10.17487/RFC6790, November 2012, 265 . 267 [RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A., 268 and C. Pignataro, "MPLS Forwarding Compliance and 269 Performance Requirements", RFC 7325, DOI 10.17487/RFC7325, 270 August 2014, . 272 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 273 Chaining (SFC) Architecture", RFC 7665, 274 DOI 10.17487/RFC7665, October 2015, 275 . 277 Authors' Addresses 278 Andrew G. Malis 279 Huawei Technologies 281 Email: agmalis@gmail.com 283 Stewart Bryant 284 Huawei Technologies 286 Email: stewart.bryant@gmail.com 288 Joel M. Halpern 289 Ericsson 291 Email: joel.halpern@ericsson.com 293 Wim Henderickx 294 Nokia 296 Email: wim.henderickx@nokia.com