idnits 2.17.1 draft-ietf-teas-use-cases-sf-aware-topo-model-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 4, 2018) is 2146 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-sfc-hierarchical' is defined on line 534, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-15 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-14 == Outdated reference: A later version (-11) exists of draft-ietf-sfc-hierarchical-08 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I. Bryskin 3 Internet-Draft Huawei Technologies 4 Intended status: Informational X. Liu 5 Expires: December 6, 2018 Jabil 6 J. Guichard 7 Y. Lee 8 Huawei Technologies 9 L. Contreras 10 Telefonica 11 D. Ceccarelli 12 Ericsson 13 J. Tantsura 14 Nuage Networks 15 June 4, 2018 17 Use Cases for SF Aware Topology Models 18 draft-ietf-teas-use-cases-sf-aware-topo-model-00 20 Abstract 22 This document describes some use cases that benefit from the network 23 topology models that are service and network function aware. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 6, 2018. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Exporting SF/NF Information to Network Clients and Other 62 Network SDN Controllers . . . . . . . . . . . . . . . . . . . 4 63 4. Flat End-to-end SFCs Managed on Multi-domain Networks . . . 5 64 5. Managing SFCs with TE Constraints . . . . . . . . . . . . . . 6 65 6. SFC Protection and Load Balancing . . . . . . . . . . . . . . 7 66 7. Network Clock Synchronization . . . . . . . . . . . . . . . . 10 67 8. Client - Provider Network Slicing Interface . . . . . . . . . 11 68 9. Dynamic Assignment of Regenerators for L0 Services . . . . . 11 69 10. Dynamic Assignment of OAM Functions for L1 Services . . . . . 12 70 11. SFC Abstraction and Scaling . . . . . . . . . . . . . . . . . 13 71 12. Dynamic Compute/VM/Storage Resource Assignment . . . . . . . 13 72 13. Application-aware Resource Operations and Management . . . . 14 73 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 74 15. Security Considerations . . . . . . . . . . . . . . . . . . . 15 75 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 76 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 17.1. Normative References . . . . . . . . . . . . . . . . . . 16 78 17.2. Informative References . . . . . . . . . . . . . . . . . 16 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 81 1. Introduction 83 Normally network connectivity services are discussed as a means to 84 inter-connect various abstract or physical network topological 85 elements, such as ports, link termination points and nodes 86 [I-D.ietf-teas-yang-te-topo] [I-D.ietf-teas-yang-te]. However, the 87 connectivity services, strictly speaking, interconnect not the 88 network topology elements per-se, rather, located on/associated with 89 the various network and service functions [RFC7498] [RFC7665]. In 90 many scenarios it is beneficial to decouple the service/network 91 functions from the network topology elements hosting them, describe 92 them in some unambiguous and identifiable way (so that it would be 93 possible, for example, to auto-discover on the network topology 94 service/network functions with identical or similar functionality and 95 characteristics) and engineer the connectivity between the service/ 96 network functions, rather than between their current topological 97 locations. The purpose of this document is to describe some use 98 cases that could benefit from such an approach. 100 2. Terminology 102 o Network Function (NF): A functional block within a network 103 infrastructure that has well-defined external interfaces and well- 104 defined functional behaviour [ETSI-NFV-TERM]. Such functions 105 include message router, CDN, session border controller, WAN 106 cceleration, DPI, firewall, NAT, QoE monitor, PE router, BRAS, and 107 radio/fixed access network nodes. 109 o Network Service: Composition of Network Functions and defined by 110 its functional and behavioural specification. The Network Service 111 contributes to the behaviour of the higher layer service, which is 112 characterized by at least performance, dependability, and security 113 specifications. The end-to-end network service behaviour is the 114 result of the combination of the individual network function 115 behaviours as well as the behaviours of the network infrastructure 116 composition mechanism [ETSI-NFV-TERM]. 118 o Service Function (SF): A function that is responsible for specific 119 treatment of received packets. A service function can act at 120 various layers of a protocol stack (e.g., at the network layer or 121 other OSI layers). As a logical component, a service function can 122 be realized as a virtual element or be embedded in a physical 123 network element. One or more service functions can be embedded in 124 the same network element. Multiple occurrences of the service 125 function can exist in the same administrative domain. A non- 126 exhaustive list of service functions includes: firewalls, WAN and 127 application acceleration, Deep Packet Inspection (DPI), server 128 load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HTTP header 129 enrichment functions, and TCP optimizers. The generic term "L4-L7 130 services" is often used to describe many service functions 131 [RFC7498]. 133 o Service Function Chain (SFC): A service function chain defines an 134 ordered or partially ordered set of abstract service functions and 135 ordering constraints that must be applied to packets, frames, and/ 136 or flows selected as a result of classification. An example of an 137 abstract service function is a firewall. The implied order may 138 not be a linear progression as the architecture allows for SFCs 139 that copy to more than one branch, and also allows for cases where 140 there is flexibility in the order in which service functions need 141 to be applied. The term "service chain" is often used as 142 shorthand for "service function chain" [RFC7498]. 144 o Connectivity Service: Any service between layer 0 and layer 3 145 aiming at delivering traffic among two or more end customer edge 146 nodes connected to provider edge nodes. Examples include L3VPN, 147 L2VPN etc. 149 o Link Termination Point (LTP): A conceptual point of connection of 150 a TE node to one of the TE links, terminated by the TE node. 151 Cardinality between an LTP and the associated TE link is 1:0..1 152 [I-D.ietf-teas-yang-te-topo]. 154 o Tunnel Termination Point (TTP): An element of TE topology 155 representing one or several of potential transport service 156 termination points (i.e. service client adaptation points such as 157 WDM/OCh transponder). TTP is associated with (hosted by) exactly 158 one TE node. TTP is assigned with the TE node scope unique ID. 159 Depending on the TE node's internal constraints, a given TTP 160 hosted by the TE node could be accessed via one, several or all TE 161 links terminated by the TE node [I-D.ietf-teas-yang-te-topo]. 163 3. Exporting SF/NF Information to Network Clients and Other Network SDN 164 Controllers 166 In the context of Service Function Chain (SFC) orchestration one 167 existing problem is that there is no way to formally describe a 168 Service or Network Function in a standard way (recognizable/ 169 understood by a third party) as a resource of a network topology 170 node. 172 One implication of this is that there is no way for the orchestrator 173 to give a network client even a ball-park idea as to which network's 174 SFs/NFs are available for the client's use/control and where they are 175 located in the network even in terms of abstract topologies/virtual 176 networks configured and managed specifically for the client. 177 Consequently, the client has no say on how the SFCs provided for the 178 client by the network should be set up and managed (which SFs are to 179 be used and how they should be chained together, optimized, 180 manipulated, protected, etc.). 182 Likewise, there is no way for the orchestrator to export SF/NF 183 information to other network controllers. The SFC orchestrator may 184 serve, for example, a higher level controller (such as Network 185 Slicing Orchestrator), with the latter wanting at least some level of 186 control as to which SFs/NFs it wants on its SFCs and how the Service 187 Function Paths (SFPs) are to be routed and provisioned, especially, 188 if it uses services of more than one SFC orchestrator. 190 The issue of exporting of SF/NF information could be addressed by 191 defining a model, in which formally described/recognizable SF/NF 192 instances are presented as topological elements, for example, hosted 193 by TE, L3 or L2 topology nodes (see Figure 1). The model could 194 describe whether, how and at what costs the SFs/NFs hosted by a given 195 node could be chained together, how these intra-node SFCs could be 196 connected to the node's Service Function Forwarders (SFFs, entities 197 dealing with SFC NSHs and metadata), and how the SFFs could be 198 connected to the node's Tunnel and Link Termination Points (TTPs and 199 LTPs) to chain the intra-node SFCs across the network topology. 201 The figure is available in the PDF format. 203 Figure 1: SF/NF aware TE topology 205 4. Flat End-to-end SFCs Managed on Multi-domain Networks 207 SFCs may span multiple administrative domains, each of which 208 controlled by a separate SFC controller. The usual solution for such 209 a scenario is the Hierarchical SFCs (H-SFCs), in which the higher 210 level orchestrator controls only SFs located on domain border nodes. 211 Said higher level SFs are chained together into higher level SFCs via 212 lower level (intra-domain) SFCs provisioned and controlled 213 independently by respective domain controllers. The decision as to 214 which higher level SFCs are connected to which lower level SFCs is 215 driven by packet re-classification every time the packet enters a 216 given domain. Said packet re-classification is a very time-consuming 217 operation. Furthermore, the independent nature of higher and lower 218 level SFC control is prone to configuration errors, which may lead to 219 long lasting loops and congestions. It is highly desirable to be 220 able to set up and manage SFCs spanning multiple domains in a flat 221 way as far as the data plane is concerned (i.e. with a single packet 222 classification at the ingress into the multi-domain network but 223 without re-classifications on domain ingress nodes). 225 One way to achieve this is to have the domain controllers expose SF/ 226 NF- aware topologies, and have the higher level orchestrator operate 227 on the network-wide topology, the product of merging of the 228 topologies catered by the domain controllers. This is similar in 229 spirit to setting up, coordinating and managing the transport 230 connectivity (TE tunnels) on a multi-domain multi-vendor transport 231 network. 233 5. Managing SFCs with TE Constraints 235 Some SFCs require per SFC link/element and end-to-end TE constrains 236 (bandwidth, delay/jitter, fate sharing/diversity. etc.). Said 237 constraints could be ensured via carrying SFPs inside overlays that 238 are traffic engineered with the constrains in mind. A good analogy 239 would be orchestrating delay constrained L3 VPNs. One way to support 240 such L3 VPNs is to carry MPLS LSPs interconnecting per-VPN VRFs 241 inside delay constrained TE tunnels interconnecting the PEs hosting 242 the VRFs. 244 _ 246 Figure 2: L3 VPN with delay constraints 248 Planning, computing and provisioning of TE overlays to constrain 249 arbitrary SFCs, especially those that span multiple administrative 250 domains with each domain controlled by a separate controller, is a 251 very difficult challenge. Currently it is addressed by pre- 252 provisioning on the network of multiple TE tunnels with various TE 253 characteristics, and "nailing down" SFs/NFs to "strategic" locations 254 (e.g. nodes terminating many of such tunnels) in a hope that an 255 adequate set of tunnels could be found to carry the SFP of a given 256 TE-constrained SFC. Such an approach is especially awkward in the 257 case when some or all of the SFs/NFs are VNFs (i.e. could be 258 instantiated at multiple network locations). 260 SF/NF-aware TE topology model in combination with TE tunnel model 261 will allow for the network orchestrator (or a client controller) to 262 compute, set up and manipulate the TE overlays in the form of TE 263 tunnel chains (see Figure 3). 265 Said chains could be duel-optimized compromising on optimal SF/NF 266 locations with optimal TE tunnels interconnecting them. The TE 267 tunnel chains (carrying multiple similarly constrained SFPs) could be 268 adequately constrained both at individual TE tunnel level and at the 269 chain end-to-end level. 271 _ 273 Figure 3: SFC with TE constraints 275 6. SFC Protection and Load Balancing 277 Currently the combination of TE topology & tunnel models offers to a 278 network controller various capabilities to recover an individual TE 279 tunnel from network failures occurred on one or more network links or 280 transit nodes on the TE paths taken by the TE tunnel's connection(s). 281 However, there is no simple way to recover a TE tunnel from a failure 282 affecting its source or destination node. SF/NF-aware TE topology 283 model can decouple the association of a given SF/NF with its location 284 on the network topology by presenting multiple, identifiable as 285 mutually substitutable SFs/NFs hosted by different TE topology nodes. 286 So, for example, if it is detected that a given TE tunnel destination 287 node is malfunctioning or has gone out of service, the TE tunnel 288 could be re-routed to terminate on a different node hosting 289 functionally the same SFs/NFs as ones hosted by the failed node (see 290 Figures 6). 292 This is in line with the ACTN edge migration and function mobility 293 concepts [I-D.ietf-teas-actn-framework]. It is important to note 294 that the described strategy works much better for the stateless SFs/ 295 NFs. This is because getting the alternative stateful SFs/NFs into 296 the same respective states as the current (i.e. active, affected by 297 failure) are is a very difficult challenge. 299 _ 301 Figure 4: SFC recovery: SF2 on node NE1 fails 303 At the SFC level the SF/NF-aware TE topology model can offer SFC 304 dynamic restoration capabilities against failed/malfunctioning SFs/ 305 NFs by identifying and provisioning detours to a TE tunnel chain, so 306 that it starts carrying the SFC's SFPs towards healthy SFs/NFs that 307 are functionally the same as the failed ones. Furthermore, multiple 308 parallel TE tunnel chains could be pre-provisioned for the purpose of 309 SFC load balancing and end-to-end protection. In the latter case 310 said parallel TE tunnel chains could be placed to be sufficiently 311 disjoint from each other. 313 _ 315 Figure 5: SFC recovery: SFC SF1-SF2-SF6 is recovered after SF2 on 316 node N1 has failed 317 _ 319 Figure 6: SFC recovery: SFC SF1-SF2-SF6 is recovered after node N1 320 has failed 322 7. Network Clock Synchronization 324 Many current and future network applications (including 5g and IoT 325 applications) require very accurate time services (PTP level, ns 326 resolution). One way to implement the adequate network clock 327 synchronization for such services is via describing network clocks as 328 NFs on an NF-aware TE topology optimized to have best possible delay 329 variation characteristics. Because such a topology will contain 330 delay/delay variation metrics of topology links and node cross- 331 connects, as well as costs in terms of delay/delay variation of 332 connecting clocks to hosting them node link and tunnel termination 333 points, it will be possible to dynamically select and provision bi- 334 directional time-constrained deterministic paths or trees connecting 335 clocks (e.g. grand master and boundary clocks) for the purpose of 336 exchange of clock synchronization information. Note that network 337 clock aware TE topologies separately provided by domain controllers 338 will enable multi-domain network orchestrator to set up and 339 manipulate the clock synchronization paths/trees spanning multiple 340 network domains. 342 8. Client - Provider Network Slicing Interface 344 3GPP defines network slice as "a set of network functions and the 345 resources for these network functions which are arranged and 346 configured, forming a complete logical network to meet certain 347 network characteristics" [I-D.defoy-netslices-3gpp-network-slicing] 348 [_3GPP.28.801]. Network slice could be also defined as a logical 349 partition of a provider's network that is owned and managed by a 350 tenant. SF/NF-aware TE topology model has a potential to support a 351 very important interface between network slicing clients and 352 providers because, on the one hand, the model can describe 353 holistically and hierarchically the client's requirements and 354 preferences with respect to a network slice functional, topological 355 and traffic engineering aspects, as well as of the degree of resource 356 separation/ sharing between the slices, thus allowing for the client 357 (up to agreed upon extent) to dynamically (re-)configure the slice or 358 (re-)schedule said (re-)configurations in time, while, on the other 359 hand, allowing for the provider to convey to the client the slice's 360 operational state information and telemetry the client has expressed 361 interest in. 363 9. Dynamic Assignment of Regenerators for L0 Services 365 On large optical networks, some of provided to their clients L0 366 services could not be provisioned as single OCh trails, rather, as 367 chains of such trails interconnected via regenerators, such as 3R 368 regenerators. Current practice of the provisioning of such services 369 requires configuration of explicit paths (EROs) describing identity 370 and location of regenerators to be used. A solution is highly 371 desirable that could: 373 o Identify such services based, for example, on optical impairment 374 computations; 376 o Assign adequate for the services regenerators dynamically out of 377 the regenerators that are grouped together in pools and 378 strategically scattered over the network topology nodes; 380 o Compute and provision supporting the services chains of optical 381 trails interconnected via so selected regenerators, optimizing the 382 chains to use minimal number of regenerators, their optimal 383 locations, as well as optimality of optical paths interconnecting 384 them; 386 o Ensure recovery of such chains from any failures that could happen 387 on links, nodes or regenerators along the chain path. 389 NF-aware TE topology model (in this case L1 NF-aware L0 topology 390 model) is just the model that could provide a network controller (or 391 even a client controller operating on abstract NF-aware topologies 392 provided by the network) to realize described above computations and 393 orchestrate the service provisioning and network failure recovery 394 operations (see Figure 7). 396 _ 398 Figure 7: Optical tunnel as TE-constrained SFC of 3R regenerators. 399 Red trail (not regenerated) is not optically reachable, but blue 400 trail (twice regenerated) is 402 10. Dynamic Assignment of OAM Functions for L1 Services 404 OAM functionality is normally managed by configuring and manipulating 405 TCM/MEP functions on network ports terminating connections or their 406 segments over which OAM operations, such as performance monitoring, 407 are required to be performed. In some layer networks (e.g. 408 Ethernet) said TCMs/MEPs could be configured on any network ports. 409 In others (e.g. OTN/ODUk) the TCMs/MEPs could be configured on some 410 (but not all network ports) due to the fact that the OAM 411 functionality (i.e. recognizing and processing of OAM messages, 412 supporting OAM protocols and FSMs) requires in these layer networks 413 certain support in the data plane, which is not available on all 414 network nodes. This makes TCMs/MEPs good candidates to be modeled as 415 NFs. This also makes TCM/MEP aware topology model a good basis for 416 placing dynamically an ODUk connection to pass through optimal OAM 417 locations without mandating the client to specify said locations 418 explicitly. 420 _ 422 Figure 8: Compute/storage resource aware topology 424 11. SFC Abstraction and Scaling 426 SF/NF-aware topology may contain information on native SFs/NFs (i.e. 427 SFs/NFs as known to the provider itself) and/or abstract SFs/NFs 428 (i.e. logical/macro SFs/NFs representing one or more SFCs each made 429 of native and/or lower level abstract SFs/NFs). As in the case of 430 abstracting topology nodes, abstracting SFs/NFs is hierarchical in 431 nature - the higher level of SF/NF-aware topology, the "larger" 432 abstract SFs/NFs are, i.e. the larger data plane SFCs they represent. 433 This allows for managing large scale networks with great number of 434 SFs/NFs (such as Data Center interconnects) in a hierarchical, highly 435 scalable manner resulting in control of very large number of flat in 436 the data plane SFCs that span multiple domains. 438 12. Dynamic Compute/VM/Storage Resource Assignment 440 In a distributed data center network, virtual machines for compute 441 resources may need to be dynamically re-allocated due to various 442 reasons such as DCI network failure, compute resource load balancing, 443 etc. In many cases, the DCI connectivity for the source and the 444 destination is not predetermined. There may be a pool of sources and 445 a pool of destination data centers associated with re-allocation of 446 compute/VM/storage resources. There is no good mechanism to date to 447 capture this dynamicity nature of compute/VM/storage resource 448 reallocation. Generic Compute/VM/Storage resources can be described 449 and announced as a SF, where a DC hosting these resources can be 450 modeled as an abstract node. Topology interconnecting these abstract 451 nodes (DCs) in general is of multi-domain nature. Thus, SF-aware 452 topology model can facilitate a joint optimization of TE network 453 resources and Compute/VM/Storage resources and solve Compute/VM/ 454 Storage mobility problem within and between DCs (see Figure 8). 456 13. Application-aware Resource Operations and Management 458 Application stratum is the functional grouping which encompasses 459 application resources and the control and management of these 460 resources. These application resources are used along with network 461 services to provide an application service to clients/end-users. 462 Application resources are non-network resources critical to achieving 463 the application service functionality. Examples of application 464 resources include: caches, mirrors, application specific servers, 465 content, large data sets, and computing power. Application service 466 is a networked application offered to a variety of clients (e.g., 467 server backup, VM migration, video cache, virtual network on-demand, 468 5G network slicing, etc.). The application servers that host these 469 application resources can be modeled as an abstract node. There may 470 be a variety of server types depending on the resources they host. 471 Figure 9 shows one example application aware topology for video cache 472 server distribution. 474 _ 476 Figure 9: Application aware topology 478 14. IANA Considerations 480 This document has no actions for IANA. 482 15. Security Considerations 484 This document does not define networking protocols and data, hence is 485 not directly responsible for security risks. 487 16. Acknowledgements 489 The authors would like to thank Maarten Vissers, Joel Halpern, and 490 Greg Mirsky for their helpful comments and valuable contributions. 492 17. References 493 17.1. Normative References 495 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 496 Service Function Chaining", RFC 7498, 497 DOI 10.17487/RFC7498, April 2015, . 500 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 501 Chaining (SFC) Architecture", RFC 7665, 502 DOI 10.17487/RFC7665, October 2015, . 505 [ETSI-NFV-TERM] 506 ETSI, "Network Functions Virtualisation (NFV); Terminology 507 for Main Concepts in NFV", ETSI GS NFV 003 V1.2.1, 508 December 2014. 510 [I-D.ietf-teas-yang-te-topo] 511 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 512 O. Dios, "YANG Data Model for Traffic Engineering (TE) 513 Topologies", draft-ietf-teas-yang-te-topo-15 (work in 514 progress), February 2018. 516 [I-D.ietf-teas-yang-te] 517 Saad, T., Gandhi, R., Liu, X., Beeram, V., Shah, H., and 518 I. Bryskin, "A YANG Data Model for Traffic Engineering 519 Tunnels and Interfaces", draft-ietf-teas-yang-te-14 (work 520 in progress), March 2018. 522 17.2. Informative References 524 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 525 Address Translator (Traditional NAT)", RFC 3022, 526 DOI 10.17487/RFC3022, January 2001, . 529 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 530 NAT64: Network Address and Protocol Translation from IPv6 531 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 532 April 2011, . 534 [I-D.ietf-sfc-hierarchical] 535 Dolson, D., Homma, S., Lopez, D., and M. Boucadair, 536 "Hierarchical Service Function Chaining (hSFC)", draft- 537 ietf-sfc-hierarchical-08 (work in progress), April 2018. 539 [I-D.defoy-netslices-3gpp-network-slicing] 540 Foy, X. and A. Rahman, "Network Slicing - 3GPP Use Case", 541 draft-defoy-netslices-3gpp-network-slicing-02 (work in 542 progress), October 2017. 544 [_3GPP.28.801] 545 3GPP, "Study on management and orchestration of network 546 slicing for next generation network", 3GPP TR 28.801 547 V2.0.0, September 2017, 548 . 550 [I-D.ietf-teas-actn-framework] 551 Ceccarelli, D. and Y. Lee, "Framework for Abstraction and 552 Control of Traffic Engineered Networks", draft-ietf-teas- 553 actn-framework-15 (work in progress), May 2018. 555 Authors' Addresses 557 Igor Bryskin 558 Huawei Technologies 560 EMail: Igor.Bryskin@huawei.com 562 Xufeng Liu 563 Jabil 565 EMail: xufeng.liu.ietf@gmail.com 567 Jim Guichard 568 Huawei Technologies 570 EMail: james.n.guichard@huawei.com 572 Young Lee 573 Huawei Technologies 575 EMail: leeyoung@huawei.com 577 Luis Miguel Contreras Murillo 578 Telefonica 580 EMail: luismiguel.contrerasmurillo@telefonica.com 581 Daniele Ceccarelli 582 Ericsson 584 EMail: daniele.ceccarelli@ericsson.com 586 Jeff Tantsura 587 Nuage Networks 589 EMail: jefftant.ietf@gmail.com