idnits 2.17.1 draft-ermagan-lisp-nsh-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 (October 3, 2016) is 2759 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'LISP' is defined on line 229, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-lisp-lcaf-12 ** Obsolete normative reference: RFC 6830 (ref. 'LISP') (Obsoleted by RFC 9300, RFC 9301) == Outdated reference: A later version (-04) exists of draft-lewis-lisp-gpe-02 == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-10 == Outdated reference: A later version (-13) exists of draft-ietf-nvo3-vxlan-gpe-02 Summary: 1 error (**), 0 flaws (~~), 6 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 6, 2017 F. Maino 6 F. Coras 7 Cisco Systems Inc 8 October 3, 2016 10 LISP Control Plane integration with NSH 11 draft-ermagan-lisp-nsh-02 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 http://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 6, 2017. 36 Copyright Notice 38 Copyright (c) 2016 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 (http://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 5.1. Packet Flow Example . . . . . . . . . . . . . . . . . . . 5 60 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 63 9. Normative References . . . . . . . . . . . . . . . . . . . . 6 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 The Locator/ID Separation Protocol (LISP) [LISP]defines a data plane 69 encapsulation format that carries IPv4 and IPv6 packets using a LISP 70 header - the LISP encapsulation - and an outer UDP/IP transport. 72 The combination of the LISP encapsulation and the LISP control plane 73 creates a dynamic network overlay. 75 LISP-GPE [LISP-GPE] and VXLAN-GPE [VXLAN-GPE] define an extension to 76 the LISP and VXLAN encapsulations with multi-protocol support, 77 enabling encapsulation of any inner payload, including IP, Ethernet, 78 and NSH [NSH]. 80 This document defines the necessary extensions to the LISP control 81 plane to support dynamic NSH-based service function chaining ( map- 82 and-encap based on SPI and SI) , using LISP-GPE/VXLAN-GPE as the 83 overlay transport protocol. 85 2. LISP Model of Service Function Chaining 87 The NSH header [NSH] identifies the service path that a packet 88 belongs to, and the next hop in the path for that packet via the 89 Service Path Identifier (SPI) and Service Index (SI) fields in the 90 Service Path header, as depicted in the figure below. 92 0 1 2 3 93 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 94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 95 | Service Path ID | Service Index | 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 98 To provide a dynamic overlay for NSH packets using LISP, the 99 assumptions are that a LISP xTR is co-located with, or connected to, 100 every Service Function Forwarder (SFF) [SFC] in a service path 101 visible to LISP, and that the xTR can send/receive the NSH packets 102 encapsulated in LISP-GPE/VXLAN-GPE headers. The ITRs in this 103 scenario need to resolve the combination of SPI and SI from the NSH 104 header ( which together identify the next hop in the Service Path) to 105 the associated Network locations (RLOCs) for the next hop. These 106 RLOCs in SFC terminology are the locators for the Service Function 107 Forwarder (SFF) that is hosting the next hop Service Function in the 108 associated Service Path. Once this mapping is resolved, the packet 109 is encapsulated to the destination RLOC (SFF). The ETR at the next 110 hop SFF receives and decapsulates this packet. The NSH packet is 111 then passed to the SFF. 113 As a result, the LISP mapping service and the xTRs need to be 114 extended to support a new identity type ( i.e. SPI+SI) as well as 115 encapsulation of NSH packets. 117 To this end, a new LCAF [LCAF] is defined to represent the SPI and SI 118 information as a new EID. We refer to this new LCAF as the SPI LCAF. 119 With this new LCAF, the LISP control protocol is extended to store 120 and retrieve SPI and SI information and their mappings to the routing 121 locators of the next hop in the associated service path. 123 3. Service Path Encoding 125 This section defines the new SPI LCAF required to encode NSH fields 126 and the associated path information in the LISP mapping system. 128 3.1. SPI LCAF 130 A new LCAF is defined to encode SPI and SI information as a new LISP 131 address type. The SPI LCAF fields are defined below. See [LCAF] for 132 a description of all LCAF fields. 134 0 1 2 3 135 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 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | AFI = 16387 | Rsvd1 | Flags | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | Type = 17 | Rsvd2 | 4 | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Service Path ID | Service index | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 Field definitions: 146 Service Path ID: The SPI from the NSH header that identifies the 147 service path this packet belongs to. 149 Service index: The SI from the NSH header that identifies the next 150 hop within the path for this packet. 152 4. LISP ITR Processing 154 LISP ITRs determine the destination routing locator to encapsulate 155 the packet to by looking up the Service Path ID and Service Index 156 from the NSH header in the mapping system. When querying the mapping 157 system, the ITRs will generate a Map-Request using the SPI LCAF as an 158 EID record. 160 The Map-Reply to such a Map-Request will have the SPI LCAF as the EID 161 record, and the routing locator information of only the next hop for 162 this SPI and SI combination, in the locator records. The ITRs store 163 this mapping in its local map-cache for future use. 165 5. LISP Map-Server Processing 167 A LISP Map-Server stores mapping entries such that it can resolve the 168 SPI and SI to the RLOC(s) of the associated next hop (SFF locators). 169 In the common deployment scenario, it is expected that the proxy- 170 reply bit is set for SPI and SI mapping entries, resulting in the 171 Map-Server proxy-replying to Map-Requests. When such a Map-Server 172 receives a Map-Request for an SPI and SI, the Map-Server returns in a 173 Map-Reply the routing locators associated with the next hop, 174 including their weights and priorities. This is done by using the 175 SPI LCAF as the EID record in the Map-Reply message. 177 5.1. Packet Flow Example 179 This section provides an example packet flow assuming that the NSH 180 Classifier function (co-located in this example with a LISP ITR), 181 classifies incoming traffic and imposes an NSH header (with the 182 appropriate SPI and SI values). Furthermore, a LISP xTR is co- 183 located with every SFF participating in the service path in this 184 example. 186 1. Upon receiving a packet with the NSH header, the LISP ITR creates 187 a Map-Request (if needed) with the SPI and SI from the NSH header and 188 forwards this request to the mapping system. This request is 189 eventually delivered to the Map-Server. 191 2. The Map-Server creates a LISP Map-Reply encoding the next hop 192 RLOC for the requested SPI and SI, and sends this reply back to the 193 requesting ITR. The ITR then caches this mapping. 195 3. The ITR now encapsulates packets matching this SPI and SI, in a 196 LISP-GPE header using the RLOC(s) returned in the mapping record, and 197 setting the Next Protocol of the header to indicate a NSH payload. 199 4. When the LISP packet arrives at the destination ETR, the ETR 200 decapsulates the packet and forwards to the co-located SFF. 202 5. When SFF needs to forward the serviced packet to the next hop in 203 the Service Path, the packet with the updated NSH header (new SI 204 value) is returned to co-located ITR, in which case, ITR continues as 205 in step 1. 207 6. At the last hop SFF, the SFF removes the NSH header and returns 208 the packet in its original form to the co-located ITR. In this case 209 the ITR performs normal LISP ITR processing as defined in . 211 6. Acknowledgments 213 NA in this version. 215 7. IANA Considerations 217 This draft includes no request to IANA. 219 8. Security Considerations 221 No additional security considerations are foreseen at this time. 223 9. Normative References 225 [LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 226 Address Format (LCAF)", draft-ietf-lisp-lcaf-12 (work in 227 progress), March 2016. 229 [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 230 "Locator/ID Separation Protocol (LISP)", RFC 6830, 231 January 2013. 233 [LISP-GPE] 234 Lewis, D., Agrawal, P., Kreeger, L., Maino, F., Quinn, P., 235 Smith, M., and N. Yadav, "LISP Generic Protocol 236 Extension", draft-lewis-lisp-gpe-02 (work in progress). 238 [NSH] Quinn, P. and U. Elzur, "Network Service Header", draft- 239 ietf-sfc-nsh-10 (work in progress), 2016. 241 [SFC] Halpern, J. and C. Pignataro, "Service Function Chaining 242 (SFC) Architecture", RFC 7665, 2016. 244 [VXLAN-GPE] 245 Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F., 246 Smith, M., Agrawal, P., Yong, L., Xu, X., Elzur, U., Garg, 247 P., and D. Melman, "Generic Protocol Extension for VXLAN", 248 draft-ietf-nvo3-vxlan-gpe-02 (work in progress). 250 Authors' Addresses 252 Vina Ermagan 253 Cisco Systems Inc 254 170 W Tasman Drive 255 San Jose, CA 95134 256 USA 258 Email: vermagan@cisco.com 260 Paul Quinn 261 Cisco Systems Inc 262 55 Cambridge Parkway 263 CAMBRIDGE, MA 02141 264 USA 266 Email: paulq@cisco.com 267 Darrel Lewis 268 Cisco Systems Inc 269 170 W Tasman Dr 270 San Jose, CA 95134 271 USA 273 Email: darlewis@cisco.com 275 Fabio Maino 276 Cisco Systems Inc 277 170 Tasman Drive 278 San Jose, CA 95134 279 USA 281 Email: fmaino@cisco.com 283 Florin Coras 284 Cisco Systems Inc 286 Email: fcoras@cisco.com