idnits 2.17.1 draft-bryskin-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 29, 2017) is 2465 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-sfc-hierarchical' is defined on line 386, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-09 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-06 == Outdated reference: A later version (-11) exists of draft-ietf-sfc-hierarchical-02 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 31, 2017 Jabil 6 J. Guichard 7 Y. Lee 8 Huawei Technologies 9 June 29, 2017 11 Use Cases for SF Aware Topology Models 12 draft-bryskin-teas-use-cases-sf-aware-topo-model-00 14 Abstract 16 This document describes some use cases that benefit from the network 17 topology models that are service and network function aware. 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 December 31, 2017. 36 Copyright Notice 38 Copyright (c) 2017 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. Exporting SF/NF Information to Network Clients and Other 55 Network SDN Controllers . . . . . . . . . . . . . . . . . . . 3 56 3. Flat End-to-end SFCs Managed on Multi-domain Networks . . . 3 57 4. Managing SFCs with TE Constrains . . . . . . . . . . . . . . 4 58 5. SFC Protection and Load Balancing . . . . . . . . . . . . . . 5 59 6. Network Clock Synchronization . . . . . . . . . . . . . . . . 5 60 7. Client - Provider Network Slicing Interface . . . . . . . . . 6 61 8. Dynamic Assignment of Regenerators for L0 Services . . . . . 6 62 9. Dynamic Assignment of OAM Functions for L1 Services . . . . . 7 63 10. SFC Abstraction and Scaling . . . . . . . . . . . . . . . . . 7 64 11. Dynamic Compute/VM/Storage Resource Assignment . . . . . . . 8 65 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 13. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 68 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 15.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 15.2. Informative References . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 Normally network connectivity services are discussed as a means to 76 interconnect various abstract or physical network topological 77 elements, such as ports, link termination points and nodes 78 [I-D.ietf-teas-yang-te-topo] [I-D.ietf-teas-yang-te]. However, the 79 connectivity services, strictly speaking, interconnect not the 80 network topology elements per-se, rather, located on/associated with 81 the various network and service functions [RFC7498] [RFC7665]. In 82 many scenarios it is beneficial to decouple the service/network 83 functions from the network topology elements hosting them, describe 84 them in some unambiguous and identifiable way (so that it would be 85 possible, for example, to auto-discover on the network topology 86 service/network functions with identical or similar functionality and 87 characteristics) and engineer the connectivity between the service/ 88 network functions, rather than between their current topological 89 locations. The purpose of this document is to describe some use 90 cases that could benefit from such an approach. 92 2. Exporting SF/NF Information to Network Clients and Other Network SDN 93 Controllers 95 In the context of Service Function Chain (SFC) orchestration one 96 existing problem is that there is no way to formally describe a 97 Service or Network Function in a standard way (recognizable/ 98 understood by a third party) as a resource of a network topology 99 node. 101 One implication of this is that there is no way for the orchestrator 102 to give a network client even a ball-park idea as to which network's 103 SFs/NFs are available for the client's use/control and where they are 104 located in the network even in terms of abstract topologies/virtual 105 networks configured and managed specifically for the client. 106 Consequently the client has no say on how the SFCs provided for the 107 client by the network should be set up and managed (which SFs are to 108 be used and how they should be chained together, optimized, 109 manipulated, protected, etc.). 111 Likewise, there is no way for the orchestrator to export SF/NF 112 information to other network controllers. The SFC orchestrator may 113 serve, for example, a higher level controller (such as Network 114 Slicing Orchestrator), with the latter wanting at least some level of 115 control as to which SFs/NFs it wants on its SFCs and how the Service 116 Function Paths (SFPs) are to be routed and provisioned, especially, 117 if it uses services of more than one SFC orchestrator. 119 The issue of exporting of SF/NF information could be addressed by 120 defining a model, in which formally described/recognizable SF/NF 121 instances are presented as topological elements, for example, hosted 122 by (associated with) TE, L3 or L2 topology nodes. The model could 123 describe whether, how and at what costs the SFs/NFs hosted by a given 124 node could be chained together, how these intra-node SFCs could be 125 connected to the node's Service Function Forwarders (SFFs, entities 126 dealing with SFC NSHs and metadata), and how the SFFs could be 127 connected to the node's Tunnel and Link Termination Points (TTPs and 128 LTPs) to chain the intra-node SFCs across the network topology. 130 3. Flat End-to-end SFCs Managed on Multi-domain Networks 132 SFCs may span multiple administrative domains, each of which 133 controlled by a separate SFC controller. The usual solution for such 134 q scenario is the Hierarchical SFCs (H-SFCs), in which the higher 135 level orchestrator controls only SFs located on domain border nodes. 136 Said higher level SFs are chained together into higher level SFCs via 137 lower level (intra-domain) SFCs provisioned and controlled 138 independently by respective domain controllers. The decision as to 139 which higher level SFCs are connected to which lower level SFCs is 140 driven by packet re- classification every time the packet enters a 141 given domain. Said packet re-classification is very time-consuming 142 operation. Furthermore, the independent nature of higher and lower 143 level SFC control is prone to configuration errors, which may lead to 144 long lasting loops and congestions. It is highly desirable to be 145 able to set up and manage SFCs spanning multiple domains in a flat 146 way as far as the data plane is concerned (i.e. with a single packet 147 classification at the ingress into the multi-domain network but 148 without re-classifications on domain ingress nodes). 150 One way to achieve this is to have the domain controllers expose SF/ 151 NF- aware topologies, and have the higher level orchestrator operate 152 on the network-wide topology, the product of merging of the 153 topologies catered by the domain controllers. This is similar in 154 spirit to setting up, coordinating and managing the transport 155 connectivity (TE tunnels) on a multi-domain multi-vendor transport 156 network. 158 4. Managing SFCs with TE Constrains 160 Some SFCs require per SFC link/element and end-to-end TE constrains 161 (bandwidth, delay/jitter, fate sharing/diversity. etc.). Said 162 constraints could be ensured via carrying SFPs inside overlays that 163 are traffic engineered with the constrains in mind. A good analogy 164 would be orchestrating delay constrained L3 VPNs. One way to support 165 such L3 VPNs is to carry MPLS LSPs interconnecting per-VPN VRFs 166 inside delay constrained TE tunnels interconnecting the PEs hosting 167 the VRFs. 169 Planning, computing and provisioning of TE overlays to constrain 170 arbitrary SFCs, especially those that span multiple administrative 171 domains with each domain controlled by a separate controller, is a 172 very difficult challenge. Currently it is addressed by pre- 173 provisioning on the network of multiple TE tunnels with various TE 174 characteristics, and "nailing down" SFs/NFs to "strategic" locations 175 (e.g. nodes terminating many of such tunnels) in a hope that an 176 adequate set of tunnels could be found to carry the SFP of a given 177 TE-constrained SFC. Such an approach is especially awkward in the 178 case when some or all of the SFs/NFs are VNFs (i.e. could be 179 instantiated at multiple network locations). 181 SF/NF-aware TE topology model in combination with TE tunnel model 182 will allow for the network orchestrator (or a client controller) to 183 compute, set up and manipulate the TE overlays in the form of TE 184 tunnel chains. Said chains could be duel-optimized compromising on 185 optimal SF/NF locations with optimal TE tunnels interconnecting them. 186 The TE tunnel chains (carrying multiple similarly constrained SFPs) 187 could be adequately constrained both at individual TE tunnel level 188 and at the chain end-to-end level. 190 5. SFC Protection and Load Balancing 192 Currently the combination of TE topology & tunnel models offers to a 193 network controller various capabilities to recover an individual TE 194 tunnel from network failures occurred on one or more network links or 195 transit nodes on the TE paths taken by the TE tunnel's connection(s). 196 However, there is no simple way to recover a TE tunnel from a failure 197 affecting its source or destination node. SF/NF-aware TE topology 198 model can decouple the association of a given SF/NF with its location 199 on the network topology by presenting multiple, identifiable as 200 mutually substitutable SFs/NFs hosted by different TE topology nodes. 201 So, for example, if it is detected that a given TE tunnel destination 202 node is malfunctioning or has gone out of service, the TE tunnel 203 could be re- routed to terminate on a different node hosting 204 functionally the same SFs/NFs as ones hosted by the failed node. 205 This is in line with the ACTN edge migration and function mobility 206 concepts. It is important to note that the described strategy works 207 much better for the stateless SFs/NFs. This is because getting the 208 alternative stateful SFs/MFs into the same respective states as the 209 current (i.e. active, affected by failure) are is a very difficult 210 challenge. 212 At the SFC level the SF/NF-aware TE topology model can offer SFC 213 dynamic restoration capabilities against failed/malfunctioning SFs/ 214 NFs by identifying and provisioning detours to a TE tunnel chain, so 215 that it starts carrying the SFC's SFPs towards healthy SFs/NFs that 216 are functionally the same as the failed ones. Furthermore, multiple 217 parallel TE tunnel chains could be pre-provisioned for the purpose of 218 SFC load balancing and end-to-end protection. In the latter case 219 said parallel TE tunnel chains could be placed to be sufficiently 220 disjoint from each other. 222 6. Network Clock Synchronization 224 Many current and future network applications (including 5g and IoT 225 applications) require very accurate time services (PTP level, ns 226 resolution). One way to implement the adequate network clock 227 synchronization for such services is via describing network clocks as 228 NFs on an NF-aware TE topology optimized to have best possible delay 229 variation characteristics. Because such a topology will contain 230 delay/delay variation metrics of topology links and node cross- 231 connects, as well as costs in terms of delay/delay variation of 232 connecting clocks to hosting them node link and tunnel termination 233 points, it will be possible to dynamically select and provision bi- 234 directional time-constrained deterministic paths or trees connecting 235 clocks (e.g. grand master and boundary clocks) for the purpose of 236 exchange of clock synchronization information. Note that network 237 clock aware TE topologies separately provided by domain controllers 238 will enable multi-domain network orchestrator to set up and 239 manipulate the clock synchronization paths/trees spanning multiple 240 network domains. 242 7. Client - Provider Network Slicing Interface 244 3GPP defines network slice as "a set of network functions and the 245 resources for these network functions which are arranged and 246 configured, forming a complete logical network to meet certain 247 network characteristics.". Network slice could be also defined as a 248 logical partition of a provider's network that is owned and managed 249 by a tenant. SF/NF-aware TE topology model has a potential to 250 support a very important interface between network slicing clients 251 and providers because, on the one hand, the model can describe 252 holistically and hierarchically the client's requirements and 253 preferences with respect to a network slice functional, topological 254 and traffic engineering aspects, as well as of the degree of resource 255 separation/ sharing between the slices, thus allowing for the client 256 (up to agreed upon extent) to dynamically (re-)configure the slice or 257 (re-)schedule said (re-)configurations in time, while, on the other 258 hand, allowing for the provider to convey to the client the slice's 259 operational state information and telemetry the client has expressed 260 interest in. 262 8. Dynamic Assignment of Regenerators for L0 Services 264 On large optical networks some of provided to their clients L0 265 services could not be provisioned as single Och trails, rather, as 266 chains of such trails interconnected via regenerators, such as 3R 267 regenerators. Current practice of the provisioning of such services 268 requires configuration of explicit paths (EROs) describing identity 269 and location of regenerators to be used. A solution is highly 270 desirable that could: 272 o Identify such services based, for example, on optical impairment 273 computations; 275 o Assign adequate for the services regenerators dynamically out of 276 the regenerators that are grouped together in pools and 277 strategically scattered over the network topology nodes; 279 o Compute and provision supporting the services chains of optical 280 trails interconnected via so selected regenerators, optimizing the 281 chains to use minimal number of regenerators, their optimal 282 locations, as well as optimality of optical paths interconnecting 283 them; 285 o Ensure recovery of such chains from any failures that could happen 286 on links, nodes or regenerators along the chain path. 288 NF-aware TE topology model (in this case L1 NF-aware L0 topology 289 model) is just the model that could provide a network controller (or 290 even a client controller operating on abstract NF-aware topologies 291 provided by the network) to realize described above computations and 292 orchestrate the service provisioning and network failure recovery 293 operations. 295 9. Dynamic Assignment of OAM Functions for L1 Services 297 OAM functionality is normally managed by configuring and manipulating 298 TCM/MEP functions on network ports terminating connections or their 299 segments over which OAM operations, such as performance monitoring, 300 are required to be performed. In some layer networks (e.g. 301 Ethernet) said TCMs/MEPs could be configured on any network ports. 302 In others (e.g. OTN/ODUk) the TCMs/MEPs could be configured on some 303 (but not all network ports) due to the fact that the OAM 304 functionality (i.e. recognizing and processing of OAM messages, 305 supporting OAM protocols and FSMs) requires in these layer networks 306 certain support in the data plane, which is not available on all 307 network nodes. This makes TCMs/MEPs good candidates to be modeled as 308 NFs. This also makes TCM/MEP aware topology model a good basis for 309 placing dynamically an ODUk connection to pass through optimal OAM 310 locations without mandating the client to specify said locations 311 explicitly. 313 10. SFC Abstraction and Scaling 315 SF/NF-aware topology may contain information on native SFs/NFs (i.e. 316 SFs/NFs as known to the provider itself) and/or abstract SFs/NFs 317 (i.e. logical/macro SFs/NFs representing one or more SFCs each made 318 of native and/or lower level abstract SFs/NFs). As in the case of 319 abstracting topology nodes, abstracting SFs/NFs is hierarchical in 320 nature - the higher level of SF/NF-aware topology, the "larger" 321 abstract SFs/NFs are, i.e. the larger data plane SFCs they represent. 322 This allows for managing large scale networks with great number of 323 SFs/NFs (such as Data Center interconnects) in a hierarchical, highly 324 scalable manner resulting in control of very large number of flat in 325 the data plane SFCs that span multiple domains. 327 11. Dynamic Compute/VM/Storage Resource Assignment 329 In a distributed data center networks, virtual machines for compute 330 resources may need to be dynamically re-allocated due to various 331 reasons such as DCI network failure, compute resource load balancing, 332 etc. In many cases, the DCI connectivity for the source and the 333 destination is not predetermined. There may be a pool of sources and 334 a pool of destination data centers associated with re-allocation of 335 compute/VM/storage resources. There is no good mechanism to date to 336 capture this dynamicity nature of compute/VM/storage resource 337 reallocation. Generic Compute/VM/Storage resources can be described 338 and announced as a SF where a DC hosting these resources can be 339 modeled as an abstract node. Topology interconnecting these abstract 340 nodes (DCs) in general is of multi-domain nature. Thus, SF-aware 341 topology model can facilitate a joint optimization of TE network 342 resources and Compute/VM/Storage resources and solve Compute/VM/ 343 Storage mobility problem within and between DCs. 345 12. IANA Considerations 347 This document has no actions for IANA. 349 13. Security Considerations 351 This document does not define networking protocols and data, hence 352 are not directly responsible for security risks. 354 14. Acknowledgements 356 The authors would like to thank Maarten Vissers, Joel Halpern, and 357 Greg Mirsky for their helpful comments and valuable contributions. 359 15. References 361 15.1. Normative References 363 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 364 Service Function Chaining", RFC 7498, 365 DOI 10.17487/RFC7498, April 2015, 366 . 368 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 369 Chaining (SFC) Architecture", RFC 7665, 370 DOI 10.17487/RFC7665, October 2015, 371 . 373 [I-D.ietf-teas-yang-te-topo] 374 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 375 O. Dios, "YANG Data Model for TE Topologies", draft-ietf- 376 teas-yang-te-topo-09 (work in progress), June 2017. 378 [I-D.ietf-teas-yang-te] 379 Saad, T., Gandhi, R., Liu, X., Beeram, V., Shah, H., and 380 I. Bryskin, "A YANG Data Model for Traffic Engineering 381 Tunnels and Interfaces", draft-ietf-teas-yang-te-06 (work 382 in progress), March 2017. 384 15.2. Informative References 386 [I-D.ietf-sfc-hierarchical] 387 Dolson, D., Homma, S., Lopez, D., Boucadair, M., Liu, D., 388 Ao, T., and V. Vu, "Hierarchical Service Function Chaining 389 (hSFC)", draft-ietf-sfc-hierarchical-02 (work in 390 progress), January 2017. 392 Authors' Addresses 394 Igor Bryskin 395 Huawei Technologies 397 EMail: Igor.Bryskin@huawei.com 399 Xufeng Liu 400 Jabil 402 EMail: Xufeng_Liu@jabil.com 404 Jim Guichard 405 Huawei Technologies 407 EMail: james.n.guichard@huawei.com 409 Young Lee 410 Huawei Technologies 412 EMail: leeyoung@huawei.com