idnits 2.17.1 draft-malis-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 (June 19, 2018) is 2138 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 SFC Working Group A. Malis 3 Internet-Draft S. Bryant 4 Intended status: Informational Huawei Technologies 5 Expires: December 21, 2018 J. Halpern 6 Ericsson 7 June 19, 2018 9 MPLS Encapsulation for SFC NSH 10 draft-malis-mpls-sfc-encapsulation-00 12 Abstract 14 This document describes how to use a Service Function Forwarder (SFF) 15 Label (similar to a pseudowire label or VPN label) to indicate the 16 presence of a Service Function Chaining (SFC) Network Service Header 17 (NSH) between an MPLS label stack and the packet payload. This 18 allows SFC packets using the NSH to be forwarded between SFFs over an 19 MPLS network, and the selection between multiple SFFs in the 20 destination node. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 21, 2018. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. MPLS Encapsulation . . . . . . . . . . . . . . . . . . . . . 2 58 3. SFF Label . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 60 5. Security considerations . . . . . . . . . . . . . . . . . . . 3 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 64 7.2. Informative References . . . . . . . . . . . . . . . . . 4 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 67 1. Introduction 69 As discussed in [RFC8300], a number of encapsulations for the Service 70 Function Chaining (SFC) Network Service Header (NSH) already exist, 71 such as in Ethernet, GRE [RFC2784], and VXLAN-GPE 72 [I-D.ietf-nvo3-vxlan-gpe]. This document describes an MPLS 73 encapsulation for the NSH, and also describes how to use an Service 74 Function Forwarder (SFF) [RFC7665] Label to indicate the presence of 75 the NSH header in the MPLS packet payload. This allows SFC packets 76 using the NSH to be forwarded between SFFs over an MPLS network, and 77 the selection between multiple SFFs in the destination node. 79 SFF Labels are similar to other labels at the bottom of an MPLS label 80 stack that denote the contents of the MPLS payload being other than 81 globally routed IP, such as a layer 2 pseudowire, an IP packet that 82 is routed in a VPN context with a private address, or an Ethernet 83 virtual private wire service. 85 This informational document follows well-established MPLS procedures 86 and does not require any actions by IANA or any new protocol 87 elements. 89 2. MPLS Encapsulation 91 The encapsulation is simply a standard MPLS label stack [RFC3032] 92 with the SFF Label at the bottom of the stack, followed by a NSH as 93 defined by [RFC8300] and the NSH payload. 95 As discussed by [RFC4928] and [RFC7325], there are Equal Cost 96 Multipath (ECMP) considerations for payloads carried by MPLS. Many 97 existing routers use deep packet inspection to examine the payload of 98 an MPLS packet, and if the first nibble of the payload is equal to 99 0x4 or 0x6, these routers assume that the payload is IPv4 or IPv6 100 respectively, and perform ECMP load balancing on the MPLS packets. 102 For SFC, this is undesirable for several reasons. First of all, NSH 103 is not IPv4 and IPv6, and the presumed contents of the TCP/IP five- 104 tuple used for load balancing would be incorrect. Also, as discussed 105 in [RFC8300], ECMP in general is undesirable for SFC and should be 106 avoided. For this reason, the NSH Base Header was carefully 107 constructed so that the NSH could not look like IPv4 or IPv6 based on 108 its first nibble. See Section 2.2 of [RFC8300] for further details. 110 3. SFF Label 112 Much like a pseudowire label, an SFF Label is allocated by the 113 downstream receiver of the NSH header from its per-platform label 114 space. 116 If a receiving node supports more than one SFF (i.e, more than one 117 SFC forwarding instance), then the SFF Label can be used select the 118 proper SFF, by having the receiving advertise more than one SFF Label 119 to its upstream sending nodes as appropriate. 121 The method used by the downstream receiving node to advertise SFF 122 Labels to the upstream sending node is currently out of scope of this 123 document. That said, a number of methods are possible, such as via a 124 protocol exchange, or via a centralized controller that manages both 125 the sender and the receiver via NETCONF/YANG, BGP, PCEP, etc. These 126 are meant as possible examples and not to constrain the future 127 definition of such advertisement methods. 129 4. IANA Considerations 131 This document does not request any actions from IANA. 133 Editorial note to RFC Editor: This section may be removed at your 134 discretion. 136 5. Security considerations 138 This document describes a method for transporting SFC packets using 139 the NSH over MPLS. It follows well-established MPLS procedures and 140 does not define any new protocol elements or allocate any new code 141 points. It is operationally equivalent to other existing NSH 142 encapsulations as defined in [RFC8300]. As such, it should have no 143 effect on SFC security as already discussed in Section 8 of 144 [RFC8300]. 146 6. Acknowledgements 148 Thanks to Jim Guichard for his review and comments. 150 7. References 152 7.1. Normative References 154 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 155 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 156 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 157 . 159 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 160 "Network Service Header (NSH)", RFC 8300, 161 DOI 10.17487/RFC8300, January 2018, 162 . 164 7.2. Informative References 166 [I-D.ietf-nvo3-vxlan-gpe] 167 Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol 168 Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-06 (work 169 in progress), April 2018. 171 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 172 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 173 DOI 10.17487/RFC2784, March 2000, 174 . 176 [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal 177 Cost Multipath Treatment in MPLS Networks", BCP 128, 178 RFC 4928, DOI 10.17487/RFC4928, June 2007, 179 . 181 [RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A., 182 and C. Pignataro, "MPLS Forwarding Compliance and 183 Performance Requirements", RFC 7325, DOI 10.17487/RFC7325, 184 August 2014, . 186 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 187 Chaining (SFC) Architecture", RFC 7665, 188 DOI 10.17487/RFC7665, October 2015, 189 . 191 Authors' Addresses 193 Andrew G. Malis 194 Huawei Technologies 196 Email: agmalis@gmail.com 198 Stewart Bryant 199 Huawei Technologies 201 Email: stewart.bryant@gmail.com 203 Joel M. Halpern 204 Ericsson 206 Email: joel.halpern@ericsson.com