idnits 2.17.1 draft-ermagan-lisp-nsh-06.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 (October 1, 2018) is 2006 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6830 (ref. 'LISP') (Obsoleted by RFC 9300, RFC 9301) == Outdated reference: A later version (-19) exists of draft-ietf-lisp-gpe-06 == Outdated reference: A later version (-13) exists of draft-ietf-nvo3-vxlan-gpe-06 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LISP Working Group V. Ermagan 3 Internet-Draft P. Quinn 4 Intended status: Experimental D. Lewis 5 Expires: April 4, 2019 F. Maino 6 F. Coras 7 Cisco Systems Inc 8 October 1, 2018 10 LISP Control Plane integration with NSH 11 draft-ermagan-lisp-nsh-06 13 Abstract 15 This document defines extensions to the LISP control plane protocol 16 to enable support for Network Service Header(NSH) based Service 17 Function Chaining (SFC). 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 4, 2019. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. LISP Model of Service Function Chaining . . . . . . . . . . . 2 55 3. Service Path Encoding . . . . . . . . . . . . . . . . . . . . 3 56 3.1. SPI LCAF . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. LISP ITR Processing . . . . . . . . . . . . . . . . . . . . . 4 58 5. LISP Map-Server Processing . . . . . . . . . . . . . . . . . 4 59 6. Packet Flow Example . . . . . . . . . . . . . . . . . . . . . 4 60 7. Multiple Data Planes . . . . . . . . . . . . . . . . . . . . 5 61 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 62 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 10. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 11. Normative References . . . . . . . . . . . . . . . . . . . . 5 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 67 1. Introduction 69 The Locator/ID Separation Protocol (LISP) [LISP] defines a control 70 plane for driving dynamic network overlays, and can be used with 71 various encapsulations such as VXLAN, LISP, LISP-GPE [LISP-GPE], 72 VXLAN-GPE[VXLAN-GPE], NV-GRE. 74 LISP-GPE/VXLAN-GPE defines a way for the LISP/VXLAN to support multi- 75 protocol encapsulations; i.e. enabling encapsulation of any inner 76 payload, including IP, Ethernet, and NSH [NSH]. 78 This document defines the necessary extensions to the LISP control 79 plane to support driving a dynamic NSH-based service function chain ( 80 map-and-encap based on SPI and SI). These extensions enable a LISP 81 xTR [LISP] or a service node [SFC] to use the LISP control plane for 82 dynamically looking up the next hop's locator in the service path. 84 2. LISP Model of Service Function Chaining 86 The NSH header [NSH] identifies the service path that a packet 87 belongs to, and the next hop in the path for that packet via the 88 Service Path Identifier (SPI) and Service Index (SI) fields in the 89 Service Path header, as depicted in the figure below. 91 0 1 2 3 92 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 93 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 94 | Service Path ID | Service Index | 95 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 To provide a dynamic overlay for NSH packets using LISP, the 98 assumptions are that a LISP xTR is co-located with, or connected to, 99 every Service Function Forwarder (SFF) [SFC] in a service path 100 visible to LISP, and that the xTR can send/receive the NSH packets 101 encapsulated in LISP-GPE/VXLAN-GPE headers. The ITRs in this 102 scenario need to resolve the combination of SPI and SI from the NSH 103 header ( which together identify the next hop in the Service Path) to 104 the associated Network locations (RLOCs) for the next hop. These 105 RLOCs in SFC terminology are the locators for the Service Function 106 Forwarder (SFF) that is hosting the next hop Service Function in the 107 associated Service Path. Once this mapping is resolved, the packet 108 is encapsulated to the destination RLOC (SFF). The ETR at the next 109 hop SFF receives and decapsulates this packet. The NSH packet is 110 then passed to the SFF. 112 As a result, the LISP mapping service and the xTRs need to be 113 extended to support a new identity type ( i.e. SPI+SI) as well as 114 encapsulation of NSH packets. 116 To this end, a new LCAF [LCAF] is defined to represent the SPI and SI 117 information as a new EID. We refer to this new LCAF as the SPI LCAF. 118 With this new LCAF, the LISP control protocol is extended to store 119 and retrieve SPI and SI information and their mappings to the routing 120 locators of the next hop in the associated service path. 122 3. Service Path Encoding 124 This section defines the new SPI LCAF required to encode NSH fields 125 and the associated path information in the LISP mapping system. 127 3.1. SPI LCAF 129 A new LCAF is defined to encode SPI and SI information as a new LISP 130 address type. The SPI LCAF fields are defined below. See [LCAF] for 131 a description of all LCAF fields. 133 0 1 2 3 134 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | AFI = 16387 | Rsvd1 | Flags | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | Type = 17 | Rsvd2 | 4 | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Service Path ID | Service index | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 Field definitions: 145 Service Path ID: The SPI from the NSH header that identifies the 146 service path this packet belongs to. 148 Service index: The SI from the NSH header that identifies the next 149 hop within the path for this packet. 151 4. LISP ITR Processing 153 LISP ITRs determine the destination routing locator to encapsulate 154 the packet to by looking up the Service Path ID and Service Index 155 from the NSH header in the mapping system. When querying the mapping 156 system, the ITRs will generate a Map-Request using the SPI LCAF as an 157 EID record. 159 The Map-Reply to such a Map-Request will have the SPI LCAF as the EID 160 record, and the routing locator information of only the next hop for 161 this SPI and SI combination, in the locator records. The ITRs store 162 this mapping in its local map-cache for future use. 164 5. LISP Map-Server Processing 166 A LISP Map-Server stores mapping entries such that it can resolve the 167 SPI and SI to the RLOC(s) of the associated next hop (SFF locators). 168 In the common deployment scenario, it is expected that the proxy- 169 reply bit is set for SPI and SI mapping entries, resulting in the 170 Map-Server proxy-replying to Map-Requests. When such a Map-Server 171 receives a Map-Request for an SPI and SI, the Map-Server returns in a 172 Map-Reply the routing locators associated with the next hop, 173 including their weights and priorities. This is done by using the 174 SPI LCAF as the EID record in the Map-Reply message. 176 6. Packet Flow Example 178 This section provides an example packet flow assuming that the NSH 179 Classifier function (co-located in this example with a LISP ITR), 180 classifies incoming traffic and imposes an NSH header (with the 181 appropriate SPI and SI values). Furthermore, a LISP xTR is co- 182 located with every SFF participating in the service path in this 183 example. 185 1. Upon receiving a packet with the NSH header, the LISP ITR creates 186 a Map-Request (if needed) with the SPI and SI from the NSH header and 187 forwards this request to the mapping system. This request is 188 eventually delivered to the Map-Server. 190 2. The Map-Server creates a LISP Map-Reply encoding the next hop 191 RLOC for the requested SPI and SI, and sends this reply back to the 192 requesting ITR. The ITR then caches this mapping. 194 3. The ITR now encapsulates packets matching this SPI and SI, in a 195 LISP-GPE header using the RLOC(s) returned in the mapping record, and 196 setting the Next Protocol of the header to indicate a NSH payload. 198 4. When the LISP packet arrives at the destination ETR, the ETR 199 decapsulates the packet and forwards to the co-located SFF. 201 5. When SFF needs to forward the serviced packet to the next hop in 202 the Service Path, the packet with the updated NSH header (new SI 203 value) is returned to co-located ITR, in which case, ITR continues as 204 in step 1. 206 6. At the last hop SFF, the SFF removes the NSH header and returns 207 the packet in its original form to the co-located ITR. In this case 208 the ITR performs normal LISP ITR processing as defined in . 210 7. Multiple Data Planes 212 In a heterogeneous environment where different hops in a single 213 service path have different data plane encapsulation capabilities, 214 the supported encapsulation formats can be specified together with 215 the locator mappings using the multiple data plane LCAF type 216 16[LCAF]. In such cases, xTR receiving a Map Reply with an RLOC 217 encoded in LCAF type 16 can choose a matching encapsulation format 218 among next hop's supported encapsulations. 220 8. Acknowledgments 222 NA in this version. 224 9. IANA Considerations 226 This draft includes no request to IANA. 228 10. Security Considerations 230 No additional security considerations are foreseen at this time. 232 11. Normative References 234 [LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 235 Address Format (LCAF)", RFC8060. 237 [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 238 "Locator/ID Separation Protocol (LISP)", RFC 6830, 239 January 2013. 241 [LISP-GPE] 242 Maino, F., Lemon, J., Agrawal, P., Lewis, D., and M. 243 Smith, "LISP Generic Protocol Extension", draft-ietf-lisp- 244 gpe-06 (work in progress). 246 [NSH] Quinn, P., Elzur, U., and C. Pignataro, "Network Service 247 Header", RFC 8300. 249 [SFC] Halpern, J. and C. Pignataro, "Service Function Chaining 250 (SFC) Architecture", RFC 7665. 252 [VXLAN-GPE] 253 Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol 254 Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-06 (work 255 in progress). 257 Authors' Addresses 259 Vina Ermagan 260 Cisco Systems Inc 261 170 W Tasman Drive 262 San Jose, CA 95134 263 USA 265 Email: vermagan@cisco.com 267 Paul Quinn 268 Cisco Systems Inc 269 55 Cambridge Parkway 270 CAMBRIDGE, MA 02141 271 USA 273 Email: paulq@cisco.com 275 Darrel Lewis 276 Cisco Systems Inc 277 170 W Tasman Dr 278 San Jose, CA 95134 279 USA 281 Email: darlewis@cisco.com 282 Fabio Maino 283 Cisco Systems Inc 284 170 Tasman Drive 285 San Jose, CA 95134 286 USA 288 Email: fmaino@cisco.com 290 Florin Coras 291 Cisco Systems Inc 293 Email: fcoras@cisco.com