idnits 2.17.1 draft-rodrigueznatal-lisp-oam-05.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 8, 2016) is 2694 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-barkai-lisp-nfv-09 == Outdated reference: A later version (-12) exists of draft-farinacci-lisp-te-11 -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LISP Working Group A. Rodriguez-Natal 3 Internet-Draft Cisco Systems 4 Intended status: Informational A. Cabellos-Aparicio 5 Expires: June 11, 2017 Technical University of Catalonia 6 M. Portoles-Comeras 7 M. Kowal 8 D. Lewis 9 F. Maino 10 Cisco Systems 11 December 8, 2016 13 LISP-OAM (Operations, Administration and Management): Use cases and 14 requirements 15 draft-rodrigueznatal-lisp-oam-05 17 Abstract 19 This document describes Operations Administration and Management 20 (OAM) use-cases and the requirements that they have towards the LISP 21 architecture. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on June 11, 2017. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Definition of terms . . . . . . . . . . . . . . . . . . . . . 3 59 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3.1. General LISP operation . . . . . . . . . . . . . . . . . 3 61 3.2. MPTCP . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.3. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.4. NFV/SFC . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 8 65 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 8. Informative References . . . . . . . . . . . . . . . . . . . 10 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 71 1. Introduction 73 LISP with its location/ID split in place creates two separated 74 namespaces, the RLOC space where the transit network elements are 75 deployed and the EID space that applies to the end-hosts. This 76 inherently splits the network in an underlay, represented by the RLOC 77 space, and an overlay, represented by the EID space. 79 However, LISP introduces some drawbacks since relevant details of the 80 underlay network are hidden to the overlay nodes (e.g, xTR). With 81 LISP, an overlay node can learn about the reachability of a path 82 towards a locator and its liveness. In terms of control, it can -by 83 means of priorities and weights- load-balance traffic across 84 different locators and, taking advantage of LISP-TE 85 [I-D.farinacci-lisp-te] and LISP-SR [I-D.brockners-lisp-sr], control 86 how the traffic flows through the underlay topology. However, 87 overlay nodes lack of appropriate knowledge about the characteristics 88 of the paths, such as loss, latency, delay, length in IP/AS hops, 89 etc. Furthermore, LISP nodes have little knowledge about the 90 topological location of the RTRs as well as the characteristics of 91 the underlay paths interconnecting them. 93 The mechanisms specified by LISP to monitor and control the underlay 94 may not be enough for the complex overlay services that are arising 95 today. Indeed, nowadays there are a plethora of services that 96 require fine-grain control and real-time information of the network 97 state. Such services could take advantage of the programmable 98 overlay scheme that LISP introduces as long as the appropriate 99 mechanisms to control and monitor the underlay are in place. 101 LISP can leverage the mapping system to operate, administer, and 102 manage the underlay-overlay relationship. Network devices can push 103 to the Mapping System information about the capabilities and state of 104 the network in order to allow it to take the best network operation 105 and management decisions. 107 In this document we analyze the most common use-cases of overlay 108 services and the requirements -from an abstract point of view- that 109 they impose on the LISP architecture. 111 2. Definition of terms 113 o OAM: The term OAM is used in this document as the acronym for 114 Operation, Administration and Management. It refers to the set of 115 procedures and mechanism that ensure that a network deployment 116 behaves as expected and adapts properly to new situations. 118 o Underlay: In this document, underlay is used to refer to the set 119 of physical devices (i.e. hosts, routers, servers, etc) that 120 support the networking operation in general and the LISP operation 121 in particular. It also refers to the address space on where those 122 devices communicate. In most cases the underlay is equivalent to 123 the RLOC space, however it can also comprise information from 124 external sources such traffic engineering databases, monitoring 125 tools, etc. 127 o Overlay: The term Overlay is used here to denote the virtual 128 network that sits on top of the underlay thanks to the LISP 129 namespace split. It also refers to the address space that the 130 virtual network uses as well as to the devices that are deployed 131 on that address space. The overlay corresponds to the EID space. 133 The rest of the terms are defined in their respective documents. See 134 the LISP specification [RFC6830] for most of the definitions, 135 [RFC6832] for PxTR, [I-D.ietf-lisp-lcaf] for LCAF and 136 [I-D.farinacci-lisp-te] for RTR. 138 3. Use Cases 140 3.1. General LISP operation 142 The overlay introduced by LISP provides an abstract view of the 143 network that simplifies the deployment and operation of the network 144 and its services. However this abstraction also hides the details of 145 the underneath physical topology. While the overlay deployment can 146 be fully defined at a logical level, the underlay is permanently 147 subject to physical state changes that can affect the overall 148 performance. Any LISP deployment has to deal with both the overlay 149 and underlay management and with underlay issues that can impact the 150 overlay operation. In this context, the overlay needs to be aware of 151 the underlay state in order to adapt itself to the current network 152 conditions. 154 A LISP deployment where the overlay has detailed information of the 155 underlay presents several advantages. First it can help 156 troubleshooting the deployment. For instance, when a problem is 157 detected, it is easy to know if it is due to misconfiguration on the 158 LISP overlay, or rather from a physical problem on the underlay. 159 Second, the underlay information can be used to influence policy 160 decisions such as dynamically adapting the locators' priority and 161 weight values based on the network state observed on the underlay. 162 Finally, it can serve to automate the configuration of certain parts 163 of the overlay deployment. 165 This is the case when underlay topological information is used to 166 automatically select on a xTR which PxTR to use. Nowadays, PxTRs are 167 generally manually configured, PITRs are provisioned with the EID 168 prefixes they announce and the PETR to use is fixed on xTR boxes. 169 With the proper overlay-underlay information exchange, these settings 170 can be adapted over time. For instance, the PITR that is announcing 171 an EID prefix can change to a secondary PITR in order to reduce 172 round-trip time (RTT) if the EID prefix moves to a different RLOC, or 173 the PETR used by a certain xTR can be replaced with a new one when 174 the PETR goes down or the underlay network conditions change (e.g. 175 the delay increases or the throughput decreases). 177 In order to provide the ability to operate with knowledge of the 178 underlay, the LISP protocol could be extended to allow collection of 179 underlay metrics that could then be pushed to the overlay. In terms 180 of collected metrics, there are a few that would improve LISP 181 operations. Some of these metrics could be extracted from the 182 network state, by passive measurement or active probing, such as 183 locator reachability, delay and throughput for a path, packet loss 184 and MTU for a link, etc. Those metrics can be directly applied to 185 the LISP policies (e.g. announcing a locator as down if it is not 186 reachable anymore), can incrementally modify the policies (e.g. 187 changing dynamically LISP weight values based on the observed delay 188 or throughput), or can be applied after a threshold has been reached 189 (e.g. setting a locator as down if the packet loss goes above a 190 certain value). In addition to network state, it would be useful to 191 keep track of LISP operation statistics, such as the size of the Map 192 Cache or the last time a locator status changed. This would give 193 more context of the underlay state and help the overlay to make 194 better decisions. 196 3.2. MPTCP 198 Multipath TCP (MPTCP) [RFC6824] introduces several sub-flows in a 199 single end-to-end TCP session while keeping a legacy TCP interface to 200 the applications. This provides both resilience and bandwidth 201 aggregation to hosts with multiple interfaces. MPTCP capabilities 202 are negotiated between end-systems, which includes the capability of 203 falling back to legacy TCP if negotiation is not possible. If the 204 other end supports MPTCP, the original TCP flow is split into several 205 sub-flows which are then forwarded over the different available 206 links. [RFC6824] states that MPTCP "should achieve no worse 207 throughput" and "must be no less resilient" than a single TCP 208 connection, beyond that baseline the room for optimization of MPTCP 209 is limited by the network conditions over the different paths used 210 for the sub-flows. 212 As a consequence of this, MPTCP is really sensitive to non-optimal 213 conditions on different links. Moreover, in an ideal deployment, the 214 multiple sub-flows should follow disjoint paths to ensure best link 215 backup scenario, and/or avoid bottle-neck paths to achieve increased 216 throughput. Another possible desirable scenario would be to forward 217 a sub-flow, or a set of sub-flows, over a secured path to prevent a 218 potential attacker from rebuilding the stream of data. However, 219 there is no way to ensure that the sub-flows will follow optimal 220 paths beyond sending them through different interfaces from the end- 221 point. On the other hand, legacy hosts do not support MPTCP and, in 222 that case, proxies should be provisioned for them. All of these 223 constraints make the overlay architecture proposed by LISP a suitable 224 scenario for MPTCP deployments. Assuming the appropriate LISP-OAM 225 mechanisms in place, MPTCP traffic over LISP should work as follows. 226 Consider that a MPTCP capable source sends traffic towards a non- 227 MPTCP capable destination. The LISP overlay has relevant information 228 about the underlay and thus knows the best topology to deliver the 229 traffic. It enforces this topology on the underlay by defining the 230 points the flows will go through and where the flows will just be 231 forwarded or balanced over different links. Since the destination is 232 not MPTCP capable, all the flows will be eventually be gathered at a 233 proxy that will collapse them into a single flow that is forwarded to 234 the destination. To handle the reply traffic, the single flow will 235 first go through the proxy MPTCP and then the MPTCP subflows will be 236 balanced again on the underlay via overlay management. 238 With LISP in place, and the MPTCP sub-flows being routed on the 239 overlay, it is possible to adapt the overlay topology to match one 240 that offers better performance for the MPTCP session. Optimal paths 241 may be enforced by means of using RTRs on the underlay. MPTCP 242 proxies can be deployed at xTRs or RTRs and the traffic then routed 243 to/from them using LISP. In order to compute this suitable topology, 244 the Mapping System needs to be provided with several pieces of 245 information regarding the network components themselves: which 246 prefixes should use MPTCP for their communications, which among them 247 are not MPTCP enabled and thus have to go through a proxy, where are 248 these proxies located and which RTRs can be used to create the 249 topology. The Mapping System would need to know the state of the 250 underlay network to create the best paths among the devices. Some 251 metrics that would be of interest to retrieve, in terms of MPTCP, are 252 the bandwidth among the xTRs, the RTRs and the proxies, the latency 253 observed on their connections, etc. Finally, the Mapping System 254 needs a way to tell the participants of the overlay what to do with 255 the traffic, i.e. it needs to tell a MPTCP proxy which EID prefixes 256 flows should be split or merged, it needs to indicate an RTR how to 257 balance the different sub-flows it receives among the different paths 258 that are available, etc. 260 3.3. Multicast 262 LISP defines several options to handle multicast operation between 263 LISP sites. [RFC6831] describes how LISP interacts with traditional 264 multicast protocols, i.e. how multicast traffic generated and managed 265 by multicast specific protocols are handled by LISP devices. The 266 multicast distribution tree creation and the multicast interaction 267 with the network is leveraged on those legacy multicast protocols. 268 "LISP Control-Plane Multicast Signaling" 269 [I-D.farinacci-lisp-mr-signaling] proposes an alternative method to 270 support multicast operation among LISP sites fully supported by the 271 LISP control-plane. It covers the signaling to build the multicast 272 distribution tree, however how it computes the tree topology is not 273 within the scope of the document. "Signal-Free LISP Multicast" 274 [I-D.farinacci-lisp-signal-free-multicast] proposes to connect 275 multicast capable LISP sites through a non-multicast capable transit 276 network. The replication is done at the LISP edge devices and the 277 packets are forwarded via unicast on the core network. In that 278 proposal, there is no multicast tree built on the transit network. 279 Finally, "LISP Replication Engineering" [I-D.coras-lisp-re] describes 280 a mechanism to build multicast distribution trees over a unicast-only 281 transit network by means of using RTRs as multicast replication 282 points. 284 In general, multicast traffic management relies on building a 285 multicast distribution tree where the multicast source is the root 286 and the multicast receivers are the leaves. The multicast traffic is 287 forwarded according to that distribution tree and replicated when 288 needed. The topology of the tree impacts both the performance of the 289 multicast deployment and the quality of service of multicast traffic 290 delivery. In order to provide the best service, the multicast 291 algorithm can use the overlay capabilities of LISP to build an 292 optimized tree for the multicast participants based on their underlay 293 topological location and the dynamic network conditions. 295 LISP-OAM mechanisms can be applied to build and maintain an optimized 296 multicast tree. In a similar fashion to what is done in LISP-RE, 297 underlay information can be pushed to the overlay management. In 298 LISP-RE, the RTRs involved in the multicast process register 299 themselves in the Mapping System, letting it know that they may be 300 used to build the distribution tree. Beyond multicast-capable device 301 discovery, a LISP-OAM architecture could potentially feed the Mapping 302 System with underlay information relevant to the multicast tree 303 computation, such as the replication capacity in the underlay devices 304 or the latency among them. Also, the multicast policies can be 305 enforced in detail from the Mapping System, for instance setting up 306 some nodes for only forwarding while keeping others for both 307 forwarding and replication. 309 3.4. NFV/SFC 311 Network Function Virtualization (NFV) is a methodology that brings 312 the advantages of traditional server virtualization to network 313 functions. Virtual Network Functions (VNFs) are no longer tied to 314 the hardware and can be dynamically instantiated, moved, and modified 315 on demand. On the other hand, Service Function Chaining (SFC) is a 316 proposal to provide a framework to manage and orchestrate chains of 317 service functions that are applied to traffic across the network. In 318 both proposals, LISP can play a role, since the overlay it provides 319 can be used to deploy or improve deployments of NFV and/or SFC. An 320 architecture of LISP for NFV is already described in 321 [I-D.barkai-lisp-nfv]. The applicability of LISP to support SFC is 322 discussed in [I-D.farinacci-lisp-te] and in [RFC7498] 324 The network functions (virtualized or not), of a LISP-based NFV or 325 SFC deployment, will be deployed on LISP devices on the underlay 326 (either xTRs or RTRs) and the data traffic will be managed over the 327 overlay. The Mapping System will store the functions chains that 328 should be applied to specific traffic and traffic engineering 329 policies, such as the ones described in [I-D.farinacci-lisp-te], will 330 be used to ensure that traffic goes through the network functions. 332 Deploying NFV or SFC solutions on top of LISP, in order to leverage 333 its overlay, requires a bi-directional communication among the 334 underlay devices and the overlay. The overlay must discover the 335 underlay devices that provide network functions and understand how 336 they are connected. It also needs to know the state of both the 337 underlay network and the underlay devices in terms of latency or 338 bandwidth among the devices as well as current load per device. In 339 the NFV/SFC use-case, it is particularly important that the devices 340 are able to announce the functions (virtual or not) that they 341 provide, or that they are capable of providing. On the other hand, a 342 LISP-OAM architecture for NFV/SFC must be able to program the 343 appropriate service chains in the Mapping System and to instantiate 344 and manage on demand VNFs in the capable devices. 346 4. Requirements 348 The use-cases presented in Section 3 show the importance of including 349 OAM mechanisms into the LISP protocol to make a better use of the 350 overlay-underlay architecture. Based on those use-cases, this 351 section proposes a set of requirements that should be fulfilled by a 352 LISP-OAM solution. These requirements may be modified and/or 353 extended in the future based on further use-cases discussion or 354 experimental experience. Note that each requirement is meant to 355 cover a specific need, all of them are independent and can be 356 individually added to LISP. However, the more requirements 357 addressed, the better the overlay can leverage the underlay. 359 o Device discovery: The overlay needs to know the LISP devices (ITR, 360 ETR, PxTR and RTR) that are available and that can be used to 361 handle traffic. This is solved for ETRs by sending Map Register 362 messages, that implicitly serve to announce the availability of 363 the ETRs to the Mapping System. A similar approach can be 364 followed to automatically discover other LISP devices. 366 o Capability discovery: The overlay must be aware of the 367 capabilities of the nodes participating in the overlay, although 368 LISP functionality is assumed in all LISP devices, the OAM 369 mechanisms need further information. Based on the use-cases 370 discussed in this document the capabilities to be announced by the 371 devices are: 373 * Support for MPTCP flow balancing 375 * Network functions implemented on the device 377 * VNFs that the device can instantiate 379 * Capacity to replicate packets 381 The capabilities should be encoded on a specific format (e.g a 382 YANG [RFC6020] model in XML, a new LCAF, JSON [RFC7159] data, etc) 383 and submitted to the overlay using LISP signaling (e.g. including 384 capabilities information on the Map Registers) or leveraging on 385 other existing protocols. 387 o Underlay state access: The overlay needs as much underlay 388 information as possible to make the best topology and policy 389 decisions. Underlay devices have to implement ways to collect, 390 store and offer this information to the overlay. According to the 391 use-cases described in this document the metrics to be collected 392 are: 394 * Latency 396 * Packet loss 398 * Path length (IP/AS hops) 400 * MTU 402 * LISP state (map-cache, locator status, etc) 404 * System load 406 * Replication capacity 408 * VNFs instantiated 410 The metrics have to be encoded (e.g. YANG, LCAF, JSON, etc) and 411 communicated to the overlay. The way to communicate them can be 412 either a push mechanism (e.g. Map Register) that would simplify 413 operation but requires a central administration entry, or a pull 414 approach (e.g Map Request) that would allow the overlay to 415 retrieve only on-demand information. The pull mechanism also 416 serves as a way to specify which information is relevant for the 417 overlay and to trigger metric collection if it was not already 418 ongoing. In any case, the underlay device may decide to limit the 419 information that it shares with the overlay. 421 o Forwarding actions: Some use-cases require that the overlay 422 defines actions on how to process packets. According to the use- 423 cases analyzed in this document the actions are: 425 * Forwarding: the basic forwarding action as defined in LISP. 427 * Replicate: Replicate an EID packet and forward it to a set of 428 RLOCs. 430 * Balance flows: Distribute EID flows across different RLOCs. 431 The flows are identified by a source/destination tuple, a 432 5-tuple, etc. 434 * Apply NF: Apply a (virtual or not) network function to the EID 435 traffic. 437 These actions can be implemented as extensions to the current 438 specifications of LISP-TE or LISP-SR, leverage on reusing existing 439 LCAF types or be defined by means of a new LCAF. Some use-cases 440 will narrow down actions via options, i.e. to define the algorithm 441 to balance flows, the specific network function to be applied, 442 etc. 444 Some of the required LISP extensions to support OAM may be offloaded 445 to existing solutions, for instance using configuration protocols 446 such NETCONF [RFC6241] to get the PETR address on an xTR, build a 447 YANG model to express devices capabilities or instantiate VNFs via 448 NFV specific protocols. 450 5. Acknowledgements 452 The authors would like to thank Matthieu Coudron and Stefano Secci 453 for their feedback and helpful suggestions. 455 6. IANA Considerations 457 This memo includes no request to IANA. 459 7. Security Considerations 461 In certain environments, multiple components of the LISP architecture 462 may be managed in a distributed fashion (i.e., a Map Server, an ITR, 463 and an ETR may be managed each individually by three separate 464 organizations). When including capabilities to allow for the 465 discovery of devices and its capabilities, as well as the collection 466 of metrics regarding the underlay and the local device itself, it 467 should be taken into consideration that proper controls are put in 468 place to enforce strict policies as to which devices can access what 469 type(s) of information. 471 8. Informative References 473 [I-D.barkai-lisp-nfv] 474 Barkai, S., Farinacci, D., Meyer, D., Maino, 475 F., Ermagan, V., Rodriguez-Natal, A., and A. Cabellos- 476 Aparicio, "LISP Based FlowMapping for Scaling NFV", draft- 477 barkai-lisp-nfv-09 (work in progress), December 2016. 479 [I-D.brockners-lisp-sr] 480 Brockners, F., Bhandari, S., Maino, F., and D. Lewis, 481 "LISP Extensions for Segment Routing", draft-brockners- 482 lisp-sr-01 (work in progress), February 2014. 484 [I-D.coras-lisp-re] 485 Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., 486 Maino, F., and D. Farinacci, "LISP Replication 487 Engineering", draft-coras-lisp-re-08 (work in progress), 488 November 2015. 490 [I-D.farinacci-lisp-mr-signaling] 491 Farinacci, D. and M. Napierala, "LISP Control-Plane 492 Multicast Signaling", draft-farinacci-lisp-mr-signaling-06 493 (work in progress), February 2015. 495 [I-D.farinacci-lisp-signal-free-multicast] 496 Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", 497 draft-farinacci-lisp-signal-free-multicast-04 (work in 498 progress), December 2015. 500 [I-D.farinacci-lisp-te] 501 Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic 502 Engineering Use-Cases", draft-farinacci-lisp-te-11 (work 503 in progress), September 2016. 505 [I-D.ietf-lisp-lcaf] 506 Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 507 Address Format (LCAF)", draft-ietf-lisp-lcaf-22 (work in 508 progress), November 2016. 510 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 511 the Network Configuration Protocol (NETCONF)", RFC 6020, 512 DOI 10.17487/RFC6020, October 2010, 513 . 515 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 516 and A. Bierman, Ed., "Network Configuration Protocol 517 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 518 . 520 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 521 "TCP Extensions for Multipath Operation with Multiple 522 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 523 . 525 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 526 Locator/ID Separation Protocol (LISP)", RFC 6830, 527 DOI 10.17487/RFC6830, January 2013, 528 . 530 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 531 Locator/ID Separation Protocol (LISP) for Multicast 532 Environments", RFC 6831, DOI 10.17487/RFC6831, January 533 2013, . 535 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 536 "Interworking between Locator/ID Separation Protocol 537 (LISP) and Non-LISP Sites", RFC 6832, 538 DOI 10.17487/RFC6832, January 2013, 539 . 541 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 542 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 543 2014, . 545 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 546 Service Function Chaining", RFC 7498, 547 DOI 10.17487/RFC7498, April 2015, 548 . 550 Authors' Addresses 552 Alberto Rodriguez-Natal 553 Cisco Systems 554 California 555 USA 557 Email: albrodr2@cisco.com 559 Albert Cabellos-Aparicio 560 Technical University of Catalonia 561 Barcelona 562 Spain 564 Email: acabello@ac.upc.edu 565 Marc Portoles-Comeras 566 Cisco Systems 567 170 Tasman Drive 568 San Jose, CA 569 USA 571 Email: mportole@cisco.com 573 Michael Kowal 574 Cisco Systems 575 111 Wood Avenue South 576 ISELIN, NJ 577 USA 579 Email: mikowal@cisco.com 581 Darrel Lewis 582 Cisco Systems 583 170 Tasman Drive 584 San Jose, CA 585 USA 587 Email: darlewis@cisco.com 589 Fabio Maino 590 Cisco Systems 591 170 Tasman Drive 592 San Jose, CA 593 USA 595 Email: fmaino@cisco.com