idnits 2.17.00 (12 Aug 2021) /tmp/idnits53382/draft-ietf-teas-sf-aware-topo-model-04.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 == Line 767 has weird spacing: '...hecksum str...' == Line 782 has weird spacing: '...hecksum str...' == Line 814 has weird spacing: '...address ine...' -- The document date (November 4, 2019) is 929 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-teas-yang-te-topo has been published as RFC 8795 == Outdated reference: A later version (-29) exists of draft-ietf-teas-yang-te-22 == Outdated reference: A later version (-14) exists of draft-ietf-teas-actn-vn-yang-07 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I. Bryskin 3 Internet-Draft Individual 4 Intended status: Informational X. Liu 5 Expires: May 7, 2020 Volta Networks 6 Y. Lee 7 Sung Kyun Kwan University 8 J. Guichard 9 Huawei Technologies 10 L. Contreras 11 Telefonica 12 D. Ceccarelli 13 Ericsson 14 J. Tantsura 15 Apstra Networks 16 November 4, 2019 18 SF Aware TE Topology YANG Model 19 draft-ietf-teas-sf-aware-topo-model-04 21 Abstract 23 This document describes a YANG data model for TE network topologies 24 that are network service and function aware. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 7, 2020. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 5 63 1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 6 64 2. Modeling Considerations . . . . . . . . . . . . . . . . . . . 6 65 3. SF Aware TE Topology Model Structure . . . . . . . . . . . . 7 66 4. SF Aware TE Topology YANG Module . . . . . . . . . . . . . . 9 67 5. CSO Data Center Model Structure . . . . . . . . . . . . . . . 16 68 6. CSO Data Center YANG Module . . . . . . . . . . . . . . . . . 18 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 24 73 9.2. Informative References . . . . . . . . . . . . . . . . . 26 74 Appendix A. Companion YANG Model for Non-NMDA Compliant 75 Implementations . . . . . . . . . . . . . . . . . . 27 76 A.1. SF Aware TE Topology State Module . . . . . . . . . . . . 27 77 Appendix B. Data Examples . . . . . . . . . . . . . . . . . . . 30 78 B.1. A Topology with Multiple Connected Network Functions . . 30 79 B.2. A Topology with an Encapsulated Network Service . . . . . 34 80 Appendix C. Use Cases for SF Aware Topology Models . . . . . . . 38 81 C.1. Exporting SF/NF Information to Network Clients and Other 82 Network SDN Controllers . . . . . . . . . . . . . . . . . 38 83 C.2. Flat End-to-end SFCs Managed on Multi-domain Networks . 39 84 C.3. Managing SFCs with TE Constraints . . . . . . . . . . . . 40 85 C.4. SFC Protection and Load Balancing . . . . . . . . . . . . 41 86 C.5. Network Clock Synchronization . . . . . . . . . . . . . . 44 87 C.6. Client - Provider Network Slicing Interface . . . . . . . 44 88 C.7. Dynamic Assignment of Regenerators for L0 Services . . . 44 89 C.8. Dynamic Assignment of OAM Functions for L1 Services . . . 46 90 C.9. SFC Abstraction and Scaling . . . . . . . . . . . . . . . 47 91 C.10. Dynamic Compute/VM/Storage Resource Assignment . . . . . 47 92 C.11. Application-aware Resource Operations and Management . . 48 93 C.12. IANA Considerations . . . . . . . . . . . . . . . . . . . 49 94 C.13. Security Considerations . . . . . . . . . . . . . . . . . 49 95 C.14. Acknowledgements . . . . . . . . . . . . . . . . . . . . 49 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 99 1. Introduction 101 RFC Ed.: In this document, please replace all occurrences of 'XXXX' 102 with the actual RFC number (and remove this note). 104 Normally network connectivity services are discussed as a means to 105 inter-connect various abstract or physical network topological 106 elements, such as ports, link termination points and nodes 107 [I-D.ietf-teas-yang-te-topo] [I-D.ietf-teas-yang-te]. However, the 108 connectivity services, strictly speaking, interconnect not the 109 network topology elements per-se, rather, located on/associated with 110 the various network and service functions [RFC7498] [RFC7665]. In 111 many scenarios it is beneficial to decouple the service/network 112 functions from the network topology elements hosting them, describe 113 them in some unambiguous and identifiable way (so that it would be 114 possible, for example, to auto-discover on the network topology 115 service/network functions with identical or similar functionality and 116 characteristics) and engineer the connectivity between the service/ 117 network functions, rather than between their current topological 118 locations. 120 Today a network offers to its clients far more services than just 121 connectivity across the network. Large variety of physical, logical 122 and/or virtual service functions, network functions and transport 123 functions (collectively named in this document as SFs) could be 124 allocated for and assigned to a client. As described in the appendix 125 of this document, there are some important use cases, in which the 126 network needs to represent to the client SFs at the client's disposal 127 as topological elements in relation to other elements of a topology 128 (i.e. nodes, links, link and tunnel termination points) used by the 129 network to describe itself to the client. Not only would such 130 information allow for the client to auto-discover the network's SFs 131 available for the services provisioned for the client, it would also 132 allow for the client selecting the SFs, duel-optimizing the selection 133 on the SF location on the network and connectivity means (e.g. TE 134 tunnels) to inter-connect the SFs. Consequently thus would give to 135 both the network and the client powerful means for the service 136 function chain (SFC [RFC7498] [RFC7665]) negotiation to achieve most 137 efficient and cost effective (from the network point of view) and 138 most optimal yet satisfying all necessary constraints of SFCs (from 139 the client's point of view). 141 This document defines a YANG [RFC7950] data model that allows service 142 functions to be represented along with TE topology elements. 144 The YANG data model in this document conforms to the Network 145 Management Datastore Architecture (NMDA) [RFC8342]. 147 1.1. Terminology 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 151 "OPTIONAL" in this document are to be interpreted as described in BCP 152 14, [RFC2119] [RFC8174] when, and only when, they appear in all 153 capitals, as shown here. 155 o Network Function (NF): A functional block within a network 156 infrastructure that has well-defined external interfaces and well- 157 defined functional behaviour [ETSI-NFV-TERM]. Such functions 158 include message router, CDN, session border controller, WAN 159 cceleration, DPI, firewall, NAT, QoE monitor, PE router, BRAS, and 160 radio/fixed access network nodes. 162 o Network Service: Composition of Network Functions and defined by 163 its functional and behavioural specification. The Network Service 164 contributes to the behaviour of the higher layer service, which is 165 characterized by at least performance, dependability, and security 166 specifications. The end-to-end network service behaviour is the 167 result of the combination of the individual network function 168 behaviours as well as the behaviours of the network infrastructure 169 composition mechanism [ETSI-NFV-TERM]. 171 o Service Function (SF): A function that is responsible for specific 172 treatment of received packets. A service function can act at 173 various layers of a protocol stack (e.g., at the network layer or 174 other OSI layers). As a logical component, a service function can 175 be realized as a virtual element or be embedded in a physical 176 network element. One or more service functions can be embedded in 177 the same network element. Multiple occurrences of the service 178 function can exist in the same administrative domain. A non- 179 exhaustive list of service functions includes: firewalls, WAN and 180 application acceleration, Deep Packet Inspection (DPI), server 181 load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HTTP header 182 enrichment functions, and TCP optimizers. The generic term "L4-L7 183 services" is often used to describe many service functions 184 [RFC7498]. 186 o Service Function Chain (SFC): A service function chain defines an 187 ordered or partially ordered set of abstract service functions and 188 ordering constraints that must be applied to packets, frames, and/ 189 or flows selected as a result of classification. An example of an 190 abstract service function is a firewall. The implied order may 191 not be a linear progression as the architecture allows for SFCs 192 that copy to more than one branch, and also allows for cases where 193 there is flexibility in the order in which service functions need 194 to be applied. The term "service chain" is often used as 195 shorthand for "service function chain" [RFC7498]. 197 o Connectivity Service: Any service between layer 0 and layer 3 198 aiming at delivering traffic among two or more end customer edge 199 nodes connected to provider edge nodes. Examples include L3VPN, 200 L2VPN etc. 202 o Link Termination Point (LTP): A conceptual point of connection of 203 a TE node to one of the TE links, terminated by the TE node. 204 Cardinality between an LTP and the associated TE link is 1:0..1 205 [I-D.ietf-teas-yang-te-topo]. 207 o Tunnel Termination Point (TTP): An element of TE topology 208 representing one or several of potential transport service 209 termination points (i.e. service client adaptation points such as 210 WDM/OCh transponder). TTP is associated with (hosted by) exactly 211 one TE node. TTP is assigned with the TE node scope unique ID. 212 Depending on the TE node's internal constraints, a given TTP 213 hosted by the TE node could be accessed via one, several or all TE 214 links terminated by the TE node [I-D.ietf-teas-yang-te-topo]. 216 o Topology and Orchestration Specification for Cloud Applications 217 (TOSCA): A language standard specified by OASIS, to describe 218 service components and their relationships using a service 219 topology, and management procedures using orchestration processes. 220 OASIS is a nonprofit consortium that drives the development, 221 convergence and adoption of open standards for the global 222 information society. 224 The following terms are defined in [RFC7950] and are not redefined 225 here: 227 o augment 229 o data model 231 o data node 233 1.2. Tree Diagrams 235 A simplified graphical representation of the data model is presented 236 in this document, by using the tree format defined in [RFC8340]. 238 1.3. Prefixes in Data Node Names 240 In this document, names of data nodes, actions, and other data model 241 objects are often used without a prefix, as long as it is clear from 242 the context in which YANG module each name is defined. Otherwise, 243 names are prefixed using the standard prefix associated with the 244 corresponding YANG module, as shown in Table 1. 246 +---------+------------------+------------------------------+ 247 | Prefix | YANG module | Reference | 248 +---------+------------------+------------------------------+ 249 | inet | ietf-inet-types | [RFC6991] | 250 | nw | ietf-network | [RFC8345] | 251 | nt | ietf-network- | [RFC8345] | 252 | | topology | | 253 | tet | ietf-te-topology | [I-D.ietf-teas-yang-te-topo] | 254 | actn-vn | ietf-actn-vn | [I-D.ietf-teas-actn-vn-yang] | 255 +---------+------------------+------------------------------+ 257 Table 1: Prefixes and Corresponding YANG Modules 259 2. Modeling Considerations 261 The model introduced in this document is an augmentation of the TE 262 Topology model defined in [I-D.ietf-teas-yang-te-topo]. SFs are 263 modeled as child elements of a TE node similarly to how Link 264 Termination Points (LTPs) and Tunnel Termination Points (TTPs) are 265 modeled in the TE Topology model. The SFs are defined as opaque 266 objects identified via topology unique service-function-id's. Each 267 SF has one or more Connection Points (CPs) identified via SF-unique 268 sf-connection-point-id's, over which the SF could be connected to 269 other SFs resided on the same TE node, as well as to other elements 270 of the TE node, in particular, to the node's LTPs and/or TTPs. An 271 interested client may use service-function-id's to look up the SFs in 272 TOSCA or YANG data store(s) defined by [ETSI-NFV-MAN] to retrieve the 273 details of the SFs, for example, to understand the SF's mutual 274 substitutability. 276 The TE Topology model introduces a concept of Connectivity Matrix 277 (CM), and uses the CM to describe which and at what costs a TE node's 278 LTPs could be inter-connected internally across the TE node. The 279 model defined in this document heavily uses the same concept to 280 describe the SF connectivity via introducing 3 additional CMs: 282 1. SF2SF CM (SF to SF Connectivity Matrix). This CM describes which 283 pairs of SFs could be locally inter-connected, and, if yes, in 284 which direction, via which CPs and at what costs. In other 285 words, the SF2SF CM describes how SFs residing on the same TE 286 node could be inter-connected into local from the TE node's 287 perspective SFCs; 289 2. SF2LTP CM (SF to LTP Connectivity Matrix). This CM describes 290 how, in which direction and at what costs the TE node's SFs could 291 be connected to the TE node's LTPs and hence to SFs residing on 292 neighboring TE nodes that are connected to LTPs at the remote 293 ends of corresponding TE links; 295 3. SF2TTP CM (SF to TTP Connectivity Matrix). This CM describes 296 how, in which direction and at what costs the TE node's SFs could 297 be connected to the TE node's TTPs and hence to SFs residing on 298 other TE nodes on the topology that could be inter-connected with 299 the TE node in question via TE tunnels terminated by the 300 corresponding TTPs. 302 In addition to SF2SF CM, the local SF chaining could be described 303 with the help of ETSI models Virtual Links (VLs) [ETSI-NFV-MAN]. 304 This option is especially useful when the costs of the local chaining 305 are negligible as compared to ones of the end-to-end SFCs said local 306 SFCs are part of. 308 Section 3 and 4 provide the YANG model structure and the YANG module 309 for SF-aware Topology. Section 5 and 6 provide the YANG model 310 structure and the YANG module for Data Center Compute Node resource 311 abstraction. This provides an example of SF2LTP CM where DC compute 312 nodes are connected to LTPs at the remote ends of the corresponding 313 TE links. This use-case is described in Section 10 of Appendix C. 315 3. SF Aware TE Topology Model Structure 317 module: ietf-te-topology-sf 318 augment /nw:networks/nw:network/nw:network-types/tet:te-topology: 319 +--rw sf! 320 augment /nw:networks/nw:network/nw:node/tet:te 321 /tet:te-node-attributes: 322 +--rw service-function 323 +--rw connectivity-matrices 324 | +--rw connectivity-matrix* [id] 325 | +--rw id uint32 326 | +--rw from 327 | | +--rw service-function-id? string 328 | | +--rw sf-connection-point-id? string 329 | +--rw to 330 | | +--rw service-function-id? string 331 | | +--rw sf-connection-point-id? string 332 | +--rw enabled? boolean 333 | +--rw direction? connectivity-direction 334 | +--rw virtual-link-id? string 335 +--rw link-terminations 336 +--rw link-termination* [id] 337 +--rw id uint32 338 +--rw from 339 | +--rw tp-ref? -> ../../../../../../.. 340 /nt:termination-point/tp-id 341 +--rw to 342 | +--rw service-function-id? string 343 | +--rw sf-connection-point-id? string 344 +--rw enabled? boolean 345 +--rw direction? connectivity-direction 346 augment /nw:networks/nw:network/nw:node/tet:te 347 /tet:information-source-entry: 348 +--ro service-function 349 +--ro connectivity-matrices 350 | +--ro connectivity-matrix* [id] 351 | +--ro id uint32 352 | +--ro from 353 | | +--ro service-function-id? string 354 | | +--ro sf-connection-point-id? string 355 | +--ro to 356 | | +--ro service-function-id? string 357 | | +--ro sf-connection-point-id? string 358 | +--ro enabled? boolean 359 | +--ro direction? connectivity-direction 360 | +--ro virtual-link-id? string 361 +--ro link-terminations 362 +--ro link-termination* [id] 363 +--ro id uint32 364 +--ro from 365 +--ro to 366 | +--ro service-function-id? string 367 | +--ro sf-connection-point-id? string 368 +--ro enabled? boolean 369 +--ro direction? connectivity-direction 370 augment /nw:networks/nw:network/nw:node/tet:te 371 /tet:tunnel-termination-point: 372 +--rw service-function 373 +--rw tunnel-terminations 374 +--rw tunnel-termination* [id] 375 +--rw id uint32 376 +--rw service-function-id? string 377 +--rw sf-connection-point-id? string 378 +--rw enabled? boolean 379 +--rw direction? connectivity-direction 381 4. SF Aware TE Topology YANG Module 383 file "ietf-te-topology-sf@2019-11-03.yang" 384 module ietf-te-topology-sf { 385 yang-version 1.1; 386 namespace "urn:ietf:params:xml:ns:yang:ietf-te-topology-sf"; 388 prefix "tet-sf"; 390 import ietf-network { 391 prefix "nw"; 392 reference "RFC 8345: A YANG Data Model for Network Topologies"; 393 } 395 import ietf-network-topology { 396 prefix "nt"; 397 reference "RFC 8345: A YANG Data Model for Network Topologies"; 398 } 400 import ietf-te-topology { 401 prefix "tet"; 402 reference 403 "I-D.ietf-teas-yang-te-topo: YANG Data Model for Traffic 404 Engineering (TE) Topologies"; 405 } 407 organization 408 "Traffic Engineering Architecture and Signaling (TEAS) 409 Working Group"; 411 contact 412 "WG Web: 413 WG List: 415 Editors: Igor Bryskin 416 418 Xufeng Liu 419 "; 421 description 422 "Network service and function aware aware TE topology model. 424 Copyright (c) 2019 IETF Trust and the persons identified as 425 authors of the code. All rights reserved. 427 Redistribution and use in source and binary forms, with or 428 without modification, is permitted pursuant to, and subject to 429 the license terms contained in, the Simplified BSD License set 430 forth in Section 4.c of the IETF Trust's Legal Provisions 431 Relating to IETF Documents 432 (http://trustee.ietf.org/license-info). 434 This version of this YANG module is part of RFC XXXX; see the 435 RFC itself for full legal notices."; 437 revision 2019-11-03 { 438 description "Initial revision"; 439 reference "RFC XXXX: SF Aware TE Topology YANG Model"; 440 } 442 /* 443 * Typedefs 444 */ 445 typedef connectivity-direction { 446 type enumeration { 447 enum "to" { 448 description 449 "The direction is uni-directional, towards the 'to' 450 entity direction."; 451 } 452 enum "from" { 453 description 454 "The direction is uni-directional, from the 'to' 455 entity direction."; 456 } 457 enum "bidir" { 458 description 459 "The direction is bi-directional."; 460 } 461 } 462 description 463 "A type used to indicates whether a connectivity is 464 uni-directional, or bi-directional. If the relation is 465 uni-directional, the value of this type indicates the 466 direction."; 467 } // connectivity-direction 469 /* 470 * Groupings 471 */ 472 grouping service-function-node-augmentation { 473 description 474 "Augmenting a TE node to be network service and function 475 aware."; 477 container service-function { 478 description 479 "Containing attributes related to network services and 480 network functions"; 481 container connectivity-matrices { 482 description 483 "Connectivity relations between network services/functions 484 on a TE node, which can be either abstract or physical."; 485 reference 486 "ETSI GS NFV-MAN 01: Network Functions Virtualisation 487 (NFV); Management and Orchestration. 488 RFC7665: Service Function Chaining (SFC) Architecture."; 489 list connectivity-matrix { 490 key "id"; 491 description 492 "Represents the connectivity relations between network 493 services/functions on a TE node."; 494 leaf id { 495 type uint32; 496 description "Identifies the connectivity-matrix entry."; 497 } 499 container from { 500 description 501 "Reference to the source network service or 502 network function."; 503 leaf service-function-id { 504 type string; 505 description 506 "Reference to a network service or a network 507 function."; 508 } 509 leaf sf-connection-point-id { 510 type string; 511 description 512 "Reference to a connection point on a network 513 service or a network function."; 514 } 515 } // from 516 container to { 517 description 518 "Reference to the destination network service or 519 network function."; 520 leaf service-function-id { 521 type string; 522 description 523 "Reference to a network service or a network 524 function."; 526 } 527 leaf sf-connection-point-id { 528 type string; 529 description 530 "Reference to a connection point on a network 531 service or a network function."; 532 } 533 } // to 534 leaf enabled { 535 type boolean; 536 description 537 "'true' if this connectivity entry is enabled."; 538 } 539 leaf direction { 540 type connectivity-direction; 541 description 542 "Indicates whether this connectivity is 543 uni-directional, or bi-directional. If the 544 relation is uni-directional, the value of 545 this leaf indicates the direction."; 546 } 547 leaf virtual-link-id { 548 type string; 549 description 550 "Reference to a virtual link that models this 551 conectivity relation in the network function 552 model."; 553 } 554 } // connectivity-matrix 555 } // connectivity-matrices 557 container link-terminations { 558 description 559 "Connectivity relations between network services/functions 560 and link termination points on a TE node, which can be 561 either abstract or physical."; 562 reference 563 "ETSI GS NFV-MAN 01: Network Functions Virtualisation 564 (NFV); Management and Orchestration. 565 RFC7665: Service Function Chaining (SFC) Architecture."; 566 list link-termination { 567 key "id"; 568 description 569 "Each entry of the list represents the connectivity 570 relation between a network service/function and 571 a link termination point on a TE node."; 572 leaf id { 573 type uint32; 574 description "Identifies the termination entry."; 575 } 577 container from { 578 description 579 "Reference to the link termination point."; 580 } // from 581 container to { 582 description 583 "Reference to the network service or network 584 function."; 585 leaf service-function-id { 586 type string; 587 description 588 "Reference to a network service or a network 589 function."; 590 } 591 leaf sf-connection-point-id { 592 type string; 593 description 594 "Reference to a connection point on a network 595 service or a network function."; 596 } 597 } // to 598 leaf enabled { 599 type boolean; 600 description 601 "'true' if this connectivity entry is enabled."; 602 } 603 leaf direction { 604 type connectivity-direction; 605 description 606 "Indicates whether this connectivity is 607 uni-directional, or bi-directional. If the 608 relation is uni-directional, the value of 609 this leaf indicates the direction."; 610 } 611 } // link-termination 612 } 613 } 614 } // service-function-node-augmentation 616 grouping service-function-ttp-augmentation { 617 description 618 "Augmenting a tunnel termination point to be network service 619 aware."; 620 container service-function { 621 description 622 "Containing attributes related to network services and 623 network functions"; 624 container tunnel-terminations { 625 description 626 "Connectivity relations between network services/functions 627 and tunnel termination points on a TE node, which can be 628 either abstract or physical."; 629 reference 630 "ETSI GS NFV-MAN 01: Network Functions Virtualisation 631 (NFV); Management and Orchestration. 632 RFC7665: Service Function Chaining (SFC) Architecture."; 633 list tunnel-termination { 634 key "id"; 635 description 636 "Each entry of the list represents the connectivity 637 relation between a network service/function and 638 a tunnel termination point on a TE node."; 639 leaf id { 640 type uint32; 641 description "Identifies the termination entry."; 642 } 644 leaf service-function-id { 645 type string; 646 description 647 "Reference to a network service or a network 648 function."; 649 } 650 leaf sf-connection-point-id { 651 type string; 652 description 653 "Reference to a connection point on a network 654 service or a network function."; 655 } 656 leaf enabled { 657 type boolean; 658 description 659 "'true' if this connectivity entry is enabled."; 660 } 661 leaf direction { 662 type connectivity-direction; 663 description 664 "Indicates whether this connectivity is 665 uni-directional, or bi-directional. If the 666 relation is uni-directional, the value of 667 this leaf indicates the direction."; 668 } 669 } // link-termination 671 } 672 } 673 } // service-function-ttp-augmentation 675 grouping sf-topology-type { 676 description 677 "Identifies the SF aware TE topology type."; 678 container sf { 679 presence "Indidates that the TE topology is SF aware."; 680 description 681 "Its presence identifies that the TE topology is SF aware."; 682 } 683 } // sf-topology-type 685 /* 686 * Augmentations 687 */ 688 /* Augmentations to network-types/te-topology */ 689 augment "/nw:networks/nw:network/nw:network-types/" 690 + "tet:te-topology" { 691 description 692 "Defines the SF aware TE topology type."; 693 uses sf-topology-type; 694 } 696 /* Augmentations to te-node-attributes */ 697 augment "/nw:networks/nw:network/nw:node/tet:te/" 698 + "tet:te-node-attributes" { 699 description 700 "Parameters for SF aware TE topology."; 701 uses service-function-node-augmentation; 702 } 704 augment "/nw:networks/nw:network/nw:node/tet:te/" 705 + "tet:information-source-entry" { 706 description 707 "Parameters for SF aware TE topology."; 708 uses service-function-node-augmentation; 709 } 711 /* Augmentations to tunnel-termination-point */ 712 augment "/nw:networks/nw:network/nw:node/tet:te/" 713 + "tet:tunnel-termination-point" { 714 description 715 "Parameters for SF aware TE topology."; 716 uses service-function-ttp-augmentation; 717 } 718 /* Augmentations to connectivity-matrix */ 719 augment "/nw:networks/nw:network/nw:node/tet:te/" 720 + "tet:te-node-attributes/tet-sf:service-function/" 721 + "tet-sf:link-terminations/tet-sf:link-termination/" 722 + "tet-sf:from" { 723 description 724 "Add reference to the link termination point. 725 This portion cannot be shared with the state module."; 726 leaf tp-ref { 727 type leafref { 728 path "../../../../../../../nt:termination-point/" 729 + "nt:tp-id"; 730 } 731 description 732 "Reference to the link termination point."; 733 } 734 } 735 } 736 738 5. CSO Data Center Model Structure 740 module: ietf-cso-dc 741 +--rw cso 742 +--rw dc* [id] 743 | +--rw hypervisor* [id] 744 | | +--rw ram 745 | | | +--rw total? uint32 746 | | | +--rw used? uint32 747 | | | +--rw free? uint32 748 | | +--rw disk 749 | | | +--rw total? uint32 750 | | | +--rw used? uint32 751 | | | +--rw free? uint32 752 | | +--rw vcpu 753 | | | +--rw total? uint16 754 | | | +--rw used? uint16 755 | | | +--rw free? uint16 756 | | +--rw instance* -> /cso/dc/instance/id 757 | | +--rw id string 758 | | +--rw name? string 759 | +--rw instance* [id] 760 | | +--rw flavor 761 | | | +--rw disk? uint32 762 | | | +--rw ram? uint32 763 | | | +--rw vcpus? uint16 764 | | | +--rw id? string 765 | | | +--rw name? string 766 | | +--rw image 767 | | | +--rw checksum string 768 | | | +--rw size uint32 769 | | | +--rw format 770 | | | | +--rw container? enumeration 771 | | | | +--rw disk? enumeration 772 | | | +--rw id? string 773 | | | +--rw name? string 774 | | +--rw hypervisor? -> /cso/dc/hypervisor/id 775 | | +--rw port* -> /cso/dc/network/subnetwork/port 776 /id 777 | | +--rw project? string 778 | | +--rw status? enumeration 779 | | +--rw id string 780 | | +--rw name? string 781 | +--rw image* [id] 782 | | +--rw checksum string 783 | | +--rw size uint32 784 | | +--rw format 785 | | | +--rw container? enumeration 786 | | | +--rw disk? enumeration 787 | | +--rw id string 788 | | +--rw name? string 789 | +--rw flavor* [id] 790 | | +--rw disk? uint32 791 | | +--rw ram? uint32 792 | | +--rw vcpus? uint16 793 | | +--rw id string 794 | | +--rw name? string 795 | +--rw dc-monitoring-param* [name] 796 | | +--rw name string 797 | | +--rw value-string? string 798 | +--rw network* [id] 799 | | +--rw subnetwork* [id] 800 | | | +--rw port* [id] 801 | | | | +--rw ip-address? inet:ip-address 802 | | | | +--rw instance? -> /cso/dc/instance/id 803 | | | | +--rw project? string 804 | | | | +--rw status? enumeration 805 | | | | +--rw id string 806 | | | | +--rw name? string 807 | | | +--rw project? string 808 | | | +--rw status? enumeration 809 | | | +--rw id string 810 | | | +--rw name? string 811 | | +--rw dhcp-agent* [id] 812 | | | +--rw enabled? boolean 813 | | | +--rw pools* [ip-address] 814 | | | | +--rw ip-address inet:ip-address 815 | | | +--rw project? string 816 | | | +--rw status? enumeration 817 | | | +--rw id string 818 | | | +--rw name? string 819 | | +--rw project? string 820 | | +--rw status? enumeration 821 | | +--rw id string 822 | | +--rw name? string 823 | | +--rw cso-ref? -> /cso/cso-id 824 | +--rw ap* -> /actn-vn:actn/ap 825 /access-point-list/access-point-id 826 | +--rw cso-ref? -> /cso/cso-id 827 | +--rw id string 828 | +--rw name? string 829 +--rw cso-id? string 831 6. CSO Data Center YANG Module 833 file "ietf-cso-dc@2017-01-16.yang" 834 module ietf-cso-dc 835 { 836 namespace "urn:ietf:params:xml:ns:yang:ietf-cso-dc"; 837 prefix "dc"; 839 import ietf-inet-types { 840 prefix "inet"; 841 } 843 import ietf-actn-vn { 844 prefix "actn-vn"; 845 } 847 revision 2017-01-16 { 848 description 849 "Initial revision. This YANG file defines 850 the reusable base types for CSO DC description."; 851 reference 852 "Derived from earlier versions of base YANG files"; 853 } 855 // Abstract models 856 grouping resource-element { 857 leaf id { type string; } 858 leaf name { type string; } 859 } 861 grouping resource-instance { 862 leaf project{ type string; } 863 leaf status { 864 type enumeration { 865 enum active; 866 enum inactive; 867 enum pending; 868 } 869 } 870 uses resource-element; 871 } 873 // Compute models 874 grouping format { 875 leaf container { 876 type enumeration { 877 enum ami; 878 enum ari; 879 enum aki; 880 enum bare; 881 enum ovf; 882 } 883 default bare; 884 } 885 leaf disk { 886 type enumeration { 887 enum ami; 888 enum ari; 889 enum aki; 890 enum vhd; 891 enum vmdk; 892 enum raw; 893 enum qcow2; 894 enum vdi; 895 enum iso; 896 } 897 default qcow2; 898 } 899 } 901 grouping image { 902 leaf checksum { type string; mandatory true; } 903 leaf size { type uint32; units 'Bytes'; mandatory true; } 905 container format { 906 uses format; 907 } 909 uses resource-element; 910 } 912 grouping flavor { 913 leaf disk { type uint32; units 'GB'; default 0; } 914 leaf ram { type uint32; units 'MB'; default 0; } 915 leaf vcpus { type uint16; default 0; } 916 uses resource-element; 917 } 919 grouping ram { 920 leaf total { type uint32; units 'MB'; } 921 leaf used { type uint32; units 'MB'; } 922 leaf free { type uint32; units 'MB'; } 923 } 925 grouping disk { 926 leaf total { type uint32; units 'GB'; } 927 leaf used { type uint32; units 'GB'; } 928 leaf free { type uint32; units 'GB'; } 929 } 931 grouping vcpu { 932 leaf total { type uint16; } 933 leaf used { type uint16; } 934 leaf free { type uint16; } 935 } 937 grouping hypervisor { 939 container ram { 940 uses ram; 941 } 943 container disk { 944 uses disk; 945 } 947 container vcpu { 948 uses vcpu; 949 } 951 leaf-list instance { 952 type leafref { path '/cso/dc/instance/id'; } } 953 uses resource-element; 955 } 957 grouping instance { 958 container flavor { uses flavor; } 959 container image { uses image; } 960 leaf hypervisor { 961 type leafref { path '/cso/dc/hypervisor/id'; } } 962 leaf-list port { type leafref { 963 path '/cso/dc/network/subnetwork/port/id'; } } 964 uses resource-instance; 965 } 967 grouping dc-monitoring-param { 968 leaf name { 969 description "dc-monitoring-param identifier"; type string; } 970 leaf value-string { 971 description 972 "Current value for a string parameter"; 973 type string; 974 } 975 } 977 grouping dc { 979 list hypervisor { 980 key id; 981 uses hypervisor; 982 } 984 list instance { 985 key id; 986 uses instance; 987 } 989 list image { 990 key id; 991 uses image; 992 } 994 list flavor { 995 key id; 996 uses flavor; 997 } 999 list dc-monitoring-param { 1000 key "name"; 1001 uses dc-monitoring-param; 1002 } 1003 list network { 1004 key id; 1005 uses network; 1006 } 1008 leaf-list ap { type leafref { 1009 path 1010 '/actn-vn:actn/actn-vn:ap/actn-vn:access-point-list/' 1011 + 'actn-vn:access-point-id'; 1012 } 1013 } 1014 leaf cso-ref { type leafref { path "/cso/cso-id"; } } 1015 uses resource-element; 1016 } 1018 container cso { 1019 list dc { 1020 key id; 1021 uses dc; 1022 } 1024 leaf cso-id { type string; } 1025 } 1027 // Network models 1028 grouping ip-address { 1029 leaf ip-address { type inet:ip-address; } 1030 } 1032 grouping dhcp-agent { 1033 leaf enabled { type boolean; } 1034 list pools { 1035 key ip-address; 1036 uses ip-address; 1037 } 1038 uses resource-instance; 1039 } 1041 grouping network { 1042 list subnetwork { 1043 key id; 1044 uses subnetwork; 1045 } 1046 list dhcp-agent { 1047 key id; 1048 uses dhcp-agent; 1050 } 1051 uses resource-instance; 1052 leaf cso-ref { type leafref { path "/cso/cso-id"; } } 1053 } 1055 grouping subnetwork { 1056 list port { 1057 key id; 1058 uses port; 1059 } 1060 uses resource-instance; 1061 } 1063 grouping port { 1064 leaf ip-address { type inet:ip-address; } 1065 leaf instance { type leafref { path '/cso/dc/instance/id'; } } 1066 uses resource-instance; 1067 } 1069 } 1070 1072 7. IANA Considerations 1074 This document registers the following namespace URIs in the IETF XML 1075 registry [RFC3688]: 1077 -------------------------------------------------------------------- 1078 URI: urn:ietf:params:xml:ns:yang:ietf-te-topology-sf 1079 Registrant Contact: The IESG. 1080 XML: N/A, the requested URI is an XML namespace. 1081 -------------------------------------------------------------------- 1083 -------------------------------------------------------------------- 1084 URI: urn:ietf:params:xml:ns:yang:ietf-te-topology-sf-state 1085 Registrant Contact: The IESG. 1086 XML: N/A, the requested URI is an XML namespace. 1087 -------------------------------------------------------------------- 1089 This document registers the following YANG modules in the YANG Module 1090 Names registry [RFC6020]: 1092 -------------------------------------------------------------------- 1093 name: ietf-te-topology-sf 1094 namespace: urn:ietf:params:xml:ns:yang:ietf-te-topology-packet 1095 prefix: tet-sf 1096 reference: RFC XXXX 1097 -------------------------------------------------------------------- 1099 -------------------------------------------------------------------- 1100 name: ietf-te-topology-sf-state 1101 namespace: urn:ietf:params:xml:ns:yang:ietf-te-topology-packet-state 1102 prefix: tet-sf-s 1103 reference: RFC XXXX 1104 -------------------------------------------------------------------- 1106 8. Security Considerations 1108 The configuration, state, action and notification data defined in 1109 this document are designed to be accessed via the NETCONF protocol 1110 [RFC6241]. The data-model by itself does not create any security 1111 implications. The security considerations for the NETCONF protocol 1112 are applicable. The NETCONF protocol used for sending the data 1113 supports authentication and encryption. 1115 9. References 1117 9.1. Normative References 1119 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1120 Requirement Levels", BCP 14, RFC 2119, 1121 DOI 10.17487/RFC2119, March 1997, 1122 . 1124 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1125 DOI 10.17487/RFC3688, January 2004, 1126 . 1128 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1129 the Network Configuration Protocol (NETCONF)", RFC 6020, 1130 DOI 10.17487/RFC6020, October 2010, 1131 . 1133 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1134 and A. Bierman, Ed., "Network Configuration Protocol 1135 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1136 . 1138 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1139 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1140 . 1142 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1143 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1144 . 1146 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1147 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1148 May 2017, . 1150 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1151 and R. Wilton, "Network Management Datastore Architecture 1152 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1153 . 1155 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 1156 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 1157 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 1158 2018, . 1160 [I-D.ietf-teas-yang-te-topo] 1161 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1162 O. Dios, "YANG Data Model for Traffic Engineering (TE) 1163 Topologies", draft-ietf-teas-yang-te-topo-22 (work in 1164 progress), June 2019. 1166 [I-D.ietf-teas-yang-te] 1167 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 1168 "A YANG Data Model for Traffic Engineering Tunnels and 1169 Interfaces", draft-ietf-teas-yang-te-22 (work in 1170 progress), November 2019. 1172 [I-D.ietf-teas-actn-vn-yang] 1173 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. 1174 Yoon, "A Yang Data Model for VN Operation", draft-ietf- 1175 teas-actn-vn-yang-07 (work in progress), October 2019. 1177 [ETSI-NFV-MAN] 1178 ETSI, "Network Functions Virtualisation (NFV); Management 1179 and Orchestration", ETSI GS NFV-MAN 001 V1.1.1, December 1180 2014. 1182 [ETSI-NFV-TERM] 1183 ETSI, "Network Functions Virtualisation (NFV); Terminology 1184 for Main Concepts in NFV", ETSI GS NFV 003 V1.2.1, 1185 December 2014. 1187 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1188 Address Translator (Traditional NAT)", RFC 3022, 1189 DOI 10.17487/RFC3022, January 2001, 1190 . 1192 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1193 NAT64: Network Address and Protocol Translation from IPv6 1194 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 1195 April 2011, . 1197 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 1198 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 1199 DOI 10.17487/RFC8453, August 2018, 1200 . 1202 [RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair, 1203 "Hierarchical Service Function Chaining (hSFC)", RFC 8459, 1204 DOI 10.17487/RFC8459, September 2018, 1205 . 1207 [I-D.defoy-netslices-3gpp-network-slicing] 1208 Foy, X. and A. Rahman, "Network Slicing - 3GPP Use Case", 1209 draft-defoy-netslices-3gpp-network-slicing-02 (work in 1210 progress), October 2017. 1212 [_3GPP.28.801] 1213 3GPP, "Study on management and orchestration of network 1214 slicing for next generation network", 3GPP TR 28.801 1215 V2.0.0, September 2017, 1216 . 1218 9.2. Informative References 1220 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 1221 Service Function Chaining", RFC 7498, 1222 DOI 10.17487/RFC7498, April 2015, 1223 . 1225 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1226 Chaining (SFC) Architecture", RFC 7665, 1227 DOI 10.17487/RFC7665, October 2015, 1228 . 1230 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1231 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1232 . 1234 Appendix A. Companion YANG Model for Non-NMDA Compliant Implementations 1236 The YANG module ietf-te-topology-sf defined in this document is 1237 designed to be used in conjunction with implementations that support 1238 the Network Management Datastore Architecture (NMDA) defined in 1239 [RFC8342]. In order to allow implementations to use the model even 1240 in cases when NMDA is not supported, the following companion module, 1241 ietf-te-topology-sf-state, is defined as state model, which mirrors 1242 the module ietf-te-topology-sf defined earlier in this document. 1243 However, all data nodes in the companion module are non-configurable, 1244 to represent the applied configuration or the derived operational 1245 states. 1247 The companion module, ietf-te-topology-sf-state, is redundant and 1248 SHOULD NOT be supported by implementations that support NMDA. 1250 As the structure of the companion module mirrors that of the 1251 coorespinding NMDA model, the YANG tree of the companion module is 1252 not depicted separately. 1254 A.1. SF Aware TE Topology State Module 1256 file "ietf-te-topology-sf-state@2019-11-03.yang" 1257 module ietf-te-topology-sf-state { 1258 yang-version 1.1; 1259 namespace "urn:ietf:params:xml:ns:yang:ietf-te-topology-sf-state"; 1261 prefix "tet-sf-s"; 1263 import ietf-te-topology-sf { 1264 prefix "tet-sf"; 1265 reference "RFC XXXX: SF Aware TE Topology YANG Model"; 1266 } 1268 import ietf-network-state { 1269 prefix "nw-s"; 1270 reference "RFC 8345: A YANG Data Model for Network Topologies"; 1271 } 1273 import ietf-network-topology-state { 1274 prefix "nt-s"; 1275 reference "RFC 8345: A YANG Data Model for Network Topologies"; 1276 } 1278 import ietf-te-topology-state { 1279 prefix "tet-s"; 1280 reference 1281 "I-D.ietf-teas-yang-te-topo: YANG Data Model for Traffic 1282 Engineering (TE) Topologies"; 1283 } 1285 organization 1286 "Traffic Engineering Architecture and Signaling (TEAS) 1287 Working Group"; 1289 contact 1290 "WG Web: 1291 WG List: 1293 Editors: Igor Bryskin 1294 1296 Xufeng Liu 1297 "; 1299 description 1300 "Network service and function aware aware TE topology operational 1301 state model for non-NMDA compliant implementations. 1303 Copyright (c) 2019 IETF Trust and the persons identified as 1304 authors of the code. All rights reserved. 1306 Redistribution and use in source and binary forms, with or 1307 without modification, is permitted pursuant to, and subject to 1308 the license terms contained in, the Simplified BSD License set 1309 forth in Section 4.c of the IETF Trust's Legal Provisions 1310 Relating to IETF Documents 1311 (http://trustee.ietf.org/license-info). 1313 This version of this YANG module is part of RFC XXXX; see the 1314 RFC itself for full legal notices."; 1316 revision 2019-11-03 { 1317 description "Initial revision"; 1318 reference "RFC XXXX: SF Aware TE Topology YANG Model"; 1319 } 1321 /* 1322 * Augmentations 1323 */ 1324 /* Augmentations to network-types/te-topology */ 1325 augment "/nw-s:networks/nw-s:network/nw-s:network-types/" 1326 + "tet-s:te-topology" { 1327 description 1328 "Defines the SF aware TE topology type."; 1330 uses tet-sf:sf-topology-type; 1331 } 1333 /* Augmentations to connectivity-matrix */ 1334 augment "/nw-s:networks/nw-s:network/nw-s:node/tet-s:te/" 1335 + "tet-s:te-node-attributes" { 1336 description 1337 "Parameters for SF aware TE topology."; 1338 uses tet-sf:service-function-node-augmentation; 1339 } 1341 augment "/nw-s:networks/nw-s:network/nw-s:node/tet-s:te/" 1342 + "tet-s:information-source-entry" { 1343 description 1344 "Parameters for SF aware TE topology."; 1345 uses tet-sf:service-function-node-augmentation; 1346 } 1348 /* Augmentations to tunnel-termination-point */ 1349 augment "/nw-s:networks/nw-s:network/nw-s:node/tet-s:te/" 1350 + "tet-s:tunnel-termination-point" { 1351 description 1352 "Parameters for SF aware TE topology."; 1353 uses tet-sf:service-function-ttp-augmentation; 1354 } 1356 /* Augmentations to connectivity-matrix */ 1357 augment "/nw-s:networks/nw-s:network/nw-s:node/tet-s:te/" 1358 + "tet-s:te-node-attributes/tet-sf-s:service-function/" 1359 + "tet-sf-s:link-terminations/tet-sf-s:link-termination/" 1360 + "tet-sf-s:from" { 1361 description 1362 "Add reference to the link termination point. 1363 This portion cannot be shared with the state module."; 1364 leaf tp-ref { 1365 type leafref { 1366 path "../../../../../../../nt-s:termination-point/" 1367 + "nt-s:tp-id"; 1368 } 1369 description 1370 "Reference to the link termination point."; 1371 } 1372 } 1373 } 1374 1376 Appendix B. Data Examples 1378 B.1. A Topology with Multiple Connected Network Functions 1380 Node-1 1381 +----o--o--------------------------o-------+ 1382 | | | | | 1383 | \__/ \__ | 1384 | *\/ TTP-1 * * * * * * * * * *\/* | 1385 LTP-4 |* * * * TTP-2 * | LTP-1 1386 o------------*-----------------------------o 1387 | * * | 1388 LTP-3 |* * * * * *| LTP-2 1389 o--- -----o 1390 | \ / | 1391 | \ / | 1392 | \ CP01 CP02/ | 1393 | +----o--------------------------o------+ | 1394 | | VL1| VL4| | | 1395 | | |CP11 |CP33 | | 1396 | | +-o--+ +----+ +-o--+ | | 1397 | | |VNF1| |VNF2| |VNF3| | | 1398 | | +-o-o+ VL2 +--o-+ VL2 +-o-o+ | | 1399 | |CP12| |\----------/ \---------/| |CP32| | 1400 | | | |CP13 CP21 CP31| | | | 1401 | | | | VL2 | | | | 1402 | | | +------------------------+ | | | 1403 | | +----------------------------+ | | 1404 | | VL3 | | 1405 | | Network Service 1 | | 1406 | +--------------------------------------+ | 1407 +------------------------------------------+ 1409 The configuration instance data for Node-1 in the above figure could 1410 be as follows: 1412 { 1413 "networks": { 1414 "network": [ 1415 { 1416 "network-types": { 1417 "te-topology": { 1418 "sf": {} 1419 } 1420 }, 1421 "network-id": "network-sf-aware", 1422 "provider-id": 201, 1423 "client-id": 300, 1424 "te-topology-id": "te-topology:network-sf-aware", 1425 "node": [ 1426 { 1427 "node-id": "Node-1", 1428 "te-node-id": "2.0.1.1", 1429 "te": { 1430 "te-node-attributes": { 1431 "domain-id": 1, 1432 "is-abstract": [null], 1433 "connectivity-matrices": { 1434 }, 1435 "service-function": { 1436 "connectivity-matrices": { 1437 "connectivity-matrix": [ 1438 { 1439 "id": 10, 1440 "from": { 1441 "service-function-id": "Network Service 1", 1442 "sf-connection-point-id": "CP01" 1443 }, 1444 "to": { 1445 "service-function-id": "VNF1", 1446 "sf-connection-point-id": "CP11" 1447 } 1448 "direction": "bidir", 1449 "virtual-link-id": "VL1" 1450 }, 1451 { 1452 "id": 13, 1453 "from": { 1454 "service-function-id": "VNF1", 1455 "sf-connection-point-id": "CP12" 1456 }, 1457 "to": { 1458 "service-function-id": "VNF3", 1459 "sf-connection-point-id": "CP32" 1460 } 1461 "direction": "bidir", 1462 "virtual-link-id": "VL3" 1463 }, 1464 { 1465 "id": 12, 1466 "from": { 1467 "service-function-id": "VNF1", 1468 "sf-connection-point-id": "CP13" 1469 }, 1470 "to": { 1471 "service-function-id": "VNF2", 1472 "sf-connection-point-id": "CP21" 1473 } 1474 "direction": "bidir", 1475 "virtual-link-id": "VL2" 1476 }, 1477 { 1478 "id": 23, 1479 "from": { 1480 "service-function-id": "VNF2", 1481 "sf-connection-point-id": "CP21" 1482 }, 1483 "to": { 1484 "service-function-id": "VNF3" 1485 "sf-connection-point-id": "CP31" 1486 } 1487 "direction": "bidir", 1488 "virtual-link-id": "VL2" 1489 }, 1490 { 1491 "id": 30, 1492 "from": { 1493 "service-function-id": "Network Service 1", 1494 "sf-connection-point-id": "CP02" 1495 }, 1496 "to": { 1497 "service-function-id": "VNF3", 1498 "sf-connection-point-id": "CP33" 1499 } 1500 "direction": "bidir", 1501 "virtual-link-id": "VL4" 1502 } 1503 ] 1504 }, 1505 "link-terminations": { 1506 "link-termination": [ 1507 { 1508 "id": 2, 1509 "from": { 1510 "tp-ref": "LTP-2" 1511 }, 1512 "to": { 1513 "service-function-id": "Network Service 1", 1514 "sf-connection-point-id": "CP02" 1515 } 1516 "direction": "bidir" 1517 }, 1518 { 1519 "id": 3, 1520 "from": { 1521 "tp-ref": "LTP-3" 1522 }, 1523 "to": { 1524 "service-function-id": "Network Service 1", 1525 "sf-connection-point-id": "CP01" 1526 } 1527 "direction": "bidir" 1528 } 1529 ] 1530 } 1531 } 1532 } 1533 "tunnel-termination-point": [ 1534 { 1535 "tunnel-tp-id": 10001, 1536 "name": "TTP-1", 1537 "service-function-terminations": { 1538 } 1539 }, 1540 { 1541 "tunnel-tp-id": 10002, 1542 "name": "TTP-2", 1543 "service-function-terminations": { 1544 } 1545 } 1546 ] 1547 }, 1548 "termination-point": [ 1549 { 1550 "tp-id": "LTP-1", 1551 "te-tp-id": 10001 1552 "te": { 1553 "interface-switching-capability": [ 1554 { 1555 "switching-capability": "switching-l2sc", 1556 "encoding": "lsp-encoding-ethernet" 1557 } 1558 ] 1559 } 1560 }, 1561 { 1562 "tp-id": "LTP-2", 1563 "te-tp-id": 10002 1564 "te": { 1565 "interface-switching-capability": [ 1566 { 1567 "switching-capability": "switching-l2sc", 1568 "encoding": "lsp-encoding-ethernet" 1569 } 1570 ] 1571 } 1572 }, 1573 { 1574 "tp-id": "LTP-3", 1575 "te-tp-id": 10003 1576 "te": { 1577 "interface-switching-capability": [ 1578 { 1579 "switching-capability": "switching-l2sc", 1580 "encoding": "lsp-encoding-ethernet" 1581 } 1582 ] 1583 } 1584 }, 1585 { 1586 "tp-id": "LTP-4", 1587 "te-tp-id": 10004 1588 "te": { 1589 "interface-switching-capability": [ 1590 { 1591 "switching-capability": "switching-l2sc", 1592 "encoding": "lsp-encoding-ethernet" 1593 } 1594 ] 1595 } 1596 } 1597 ] 1598 } 1599 ] 1600 } 1601 ] 1602 } 1603 } 1605 B.2. A Topology with an Encapsulated Network Service 1607 In this example, a network service consists of several inter- 1608 connected network functions (NFs), and is represented by this model 1609 as an encapsulated opaque object without the details between its 1610 internals. 1612 Node-1 1613 +----o--o--------------------------o-------+ 1614 | | | | | 1615 | \__/ \__ | 1616 | *\/ TTP-1 * * * * * * * * * *\/* | 1617 LTP-4 |* * * * TTP-2 * | LTP-1 1618 o------------*-----------------------------o 1619 | * * | 1620 LTP-3 |* * * * * *| LTP-2 1621 o--- -----o 1622 | \ / | 1623 | \ / | 1624 | \ CP01 CP02/ | 1625 | +----o--------------------------o------+ | 1626 | | | | 1627 | | Network Service 1 | | 1628 | +--------------------------------------+ | 1629 +------------------------------------------+ 1631 The configuration instance data for Node-1 in the above figure could 1632 be as follows: 1634 { 1635 "networks": { 1636 "network": [ 1637 { 1638 "network-types": { 1639 "te-topology": { 1640 "sf": {} 1641 } 1642 }, 1643 "network-id": "network-sf-aware", 1644 "provider-id": 201, 1645 "client-id": 300, 1646 "te-topology-id": "te-topology:network-sf-aware", 1647 "node": [ 1648 { 1649 "node-id": "Node-1", 1650 "te-node-id": "2.0.1.1", 1651 "te": { 1652 "te-node-attributes": { 1653 "domain-id": 1, 1654 "is-abstract": [null], 1655 "connectivity-matrices": { 1656 }, 1657 "service-function": { 1658 "connectivity-matrices": { 1659 }, 1660 "link-terminations": { 1661 "link-termination": [ 1662 { 1663 "id": 2, 1664 "from": { 1665 "tp-ref": "LTP-2" 1666 }, 1667 "to": { 1668 "service-function-id": "Network Service 1", 1669 "sf-connection-point-id": "CP02" 1670 } 1671 "direction": "bidir" 1672 }, 1673 { 1674 "id": 3, 1675 "from": { 1676 "tp-ref": "LTP-3" 1677 }, 1678 "to": { 1679 "service-function-id": "Network Service 1", 1680 "sf-connection-point-id": "CP01" 1681 } 1682 "direction": "bidir" 1683 } 1684 ] 1685 } 1686 } 1687 } 1688 "tunnel-termination-point": [ 1689 { 1690 "tunnel-tp-id": 10001, 1691 "name": "TTP-1", 1692 "service-function-terminations": { 1693 } 1694 }, 1695 { 1696 "tunnel-tp-id": 10002, 1697 "name": "TTP-2", 1698 "service-function-terminations": { 1699 } 1700 } 1701 ] 1702 }, 1703 "termination-point": [ 1704 { 1705 "tp-id": "LTP-1", 1706 "te-tp-id": 10001 1707 "te": { 1708 "interface-switching-capability": [ 1709 { 1710 "switching-capability": "switching-l2sc", 1711 "encoding": "lsp-encoding-ethernet" 1712 } 1713 ] 1714 } 1715 }, 1716 { 1717 "tp-id": "LTP-2", 1718 "te-tp-id": 10002 1719 "te": { 1720 "interface-switching-capability": [ 1721 { 1722 "switching-capability": "switching-l2sc", 1723 "encoding": "lsp-encoding-ethernet" 1724 } 1725 ] 1726 } 1727 }, 1728 { 1729 "tp-id": "LTP-3", 1730 "te-tp-id": 10003 1731 "te": { 1732 "interface-switching-capability": [ 1733 { 1734 "switching-capability": "switching-l2sc", 1735 "encoding": "lsp-encoding-ethernet" 1736 } 1737 ] 1738 } 1739 }, 1740 { 1741 "tp-id": "LTP-4", 1742 "te-tp-id": 10004 1743 "te": { 1744 "interface-switching-capability": [ 1745 { 1746 "switching-capability": "switching-l2sc", 1747 "encoding": "lsp-encoding-ethernet" 1748 } 1749 ] 1750 } 1751 } 1752 ] 1753 } 1754 ] 1755 } 1757 ] 1758 } 1759 } 1761 Appendix C. Use Cases for SF Aware Topology Models 1763 C.1. Exporting SF/NF Information to Network Clients and Other Network 1764 SDN Controllers 1766 In the context of Service Function Chain (SFC) orchestration one 1767 existing problem is that there is no way to formally describe a 1768 Service or Network Function in a standard way (recognizable/ 1769 understood by a third party) as a resource of a network topology 1770 node. 1772 One implication of this is that there is no way for the orchestrator 1773 to give a network client even a ball-park idea as to which network's 1774 SFs/NFs are available for the client's use/control and where they are 1775 located in the network even in terms of abstract topologies/virtual 1776 networks configured and managed specifically for the client. 1777 Consequently, the client has no say on how the SFCs provided for the 1778 client by the network should be set up and managed (which SFs are to 1779 be used and how they should be chained together, optimized, 1780 manipulated, protected, etc.). 1782 Likewise, there is no way for the orchestrator to export SF/NF 1783 information to other network controllers. The SFC orchestrator may 1784 serve, for example, a higher level controller (such as Network 1785 Slicing Orchestrator), with the latter wanting at least some level of 1786 control as to which SFs/NFs it wants on its SFCs and how the Service 1787 Function Paths (SFPs) are to be routed and provisioned, especially, 1788 if it uses services of more than one SFC orchestrator. 1790 The issue of exporting of SF/NF information could be addressed by 1791 defining a model, in which formally described/recognizable SF/NF 1792 instances are presented as topological elements, for example, hosted 1793 by TE, L3 or L2 topology nodes (see Figure 1). The model could 1794 describe whether, how and at what costs the SFs/NFs hosted by a given 1795 node could be chained together, how these intra-node SFCs could be 1796 connected to the node's Service Function Forwarders (SFFs, entities 1797 dealing with SFC NSHs and metadata), and how the SFFs could be 1798 connected to the node's Tunnel and Link Termination Points (TTPs and 1799 LTPs) to chain the intra-node SFCs across the network topology. 1801 The figure is available in the PDF format. 1803 Figure 1: SF/NF aware TE topology 1805 C.2. Flat End-to-end SFCs Managed on Multi-domain Networks 1807 SFCs may span multiple administrative domains, each of which 1808 controlled by a separate SFC controller. The usual solution for such 1809 a scenario is the Hierarchical SFCs (H-SFCs) [RFC8459], in which the 1810 higher level orchestrator controls only SFs located on domain border 1811 nodes. Said higher level SFs are chained together into higher level 1812 SFCs via lower level (intra-domain) SFCs provisioned and controlled 1813 independently by respective domain controllers. The decision as to 1814 which higher level SFCs are connected to which lower level SFCs is 1815 driven by packet re-classification every time the packet enters a 1816 given domain. Said packet re-classification is a very time-consuming 1817 operation. Furthermore, the independent nature of higher and lower 1818 level SFC control is prone to configuration errors, which may lead to 1819 long lasting loops and congestions. It is highly desirable to be 1820 able to set up and manage SFCs spanning multiple domains in a flat 1821 way as far as the data plane is concerned (i.e. with a single packet 1822 classification at the ingress into the multi-domain network but 1823 without re-classifications on domain ingress nodes). 1825 One way to achieve this is to have the domain controllers expose SF/ 1826 NF- aware topologies, and have the higher level orchestrator operate 1827 on the network-wide topology, the product of merging of the 1828 topologies catered by the domain controllers. This is similar in 1829 spirit to setting up, coordinating and managing the transport 1830 connectivity (TE tunnels) on a multi-domain multi-vendor transport 1831 network. 1833 C.3. Managing SFCs with TE Constraints 1835 Some SFCs require per SFC link/element and end-to-end TE constrains 1836 (bandwidth, delay/jitter, fate sharing/diversity. etc.). Said 1837 constraints could be ensured via carrying SFPs inside overlays that 1838 are traffic engineered with the constrains in mind. A good analogy 1839 would be orchestrating delay constrained L3 VPNs. One way to support 1840 such L3 VPNs is to carry MPLS LSPs interconnecting per-VPN VRFs 1841 inside delay constrained TE tunnels interconnecting the PEs hosting 1842 the VRFs. 1844 _ 1846 Figure 2: L3 VPN with delay constraints 1848 Planning, computing and provisioning of TE overlays to constrain 1849 arbitrary SFCs, especially those that span multiple administrative 1850 domains with each domain controlled by a separate controller, is a 1851 very difficult challenge. Currently it is addressed by pre- 1852 provisioning on the network of multiple TE tunnels with various TE 1853 characteristics, and "nailing down" SFs/NFs to "strategic" locations 1854 (e.g. nodes terminating many of such tunnels) in a hope that an 1855 adequate set of tunnels could be found to carry the SFP of a given 1856 TE-constrained SFC. Such an approach is especially awkward in the 1857 case when some or all of the SFs/NFs are VNFs (i.e. could be 1858 instantiated at multiple network locations). 1860 SF/NF-aware TE topology model in combination with TE tunnel model 1861 will allow for the network orchestrator (or a client controller) to 1862 compute, set up and manipulate the TE overlays in the form of TE 1863 tunnel chains (see Figure 3). 1865 Said chains could be duel-optimized compromising on optimal SF/NF 1866 locations with optimal TE tunnels interconnecting them. The TE 1867 tunnel chains (carrying multiple similarly constrained SFPs) could be 1868 adequately constrained both at individual TE tunnel level and at the 1869 chain end-to-end level. 1871 _ 1873 Figure 3: SFC with TE constraints 1875 C.4. SFC Protection and Load Balancing 1877 Currently the combination of TE topology & tunnel models offers to a 1878 network controller various capabilities to recover an individual TE 1879 tunnel from network failures occurred on one or more network links or 1880 transit nodes on the TE paths taken by the TE tunnel's connection(s). 1881 However, there is no simple way to recover a TE tunnel from a failure 1882 affecting its source or destination node. SF/NF-aware TE topology 1883 model can decouple the association of a given SF/NF with its location 1884 on the network topology by presenting multiple, identifiable as 1885 mutually substitutable SFs/NFs hosted by different TE topology nodes. 1886 So, for example, if it is detected that a given TE tunnel destination 1887 node is malfunctioning or has gone out of service, the TE tunnel 1888 could be re-routed to terminate on a different node hosting 1889 functionally the same SFs/NFs as ones hosted by the failed node (see 1890 Figures 6). 1892 This is in line with the ACTN edge migration and function mobility 1893 concepts [RFC8453]. It is important to note that the described 1894 strategy works much better for the stateless SFs/NFs. This is 1895 because getting the alternative stateful SFs/NFs into the same 1896 respective states as the current (i.e. active, affected by failure) 1897 are is a very difficult challenge. 1899 _ 1901 Figure 4: SFC recovery: SF2 on node NE1 fails 1903 At the SFC level the SF/NF-aware TE topology model can offer SFC 1904 dynamic restoration capabilities against failed/malfunctioning SFs/ 1905 NFs by identifying and provisioning detours to a TE tunnel chain, so 1906 that it starts carrying the SFC's SFPs towards healthy SFs/NFs that 1907 are functionally the same as the failed ones. Furthermore, multiple 1908 parallel TE tunnel chains could be pre-provisioned for the purpose of 1909 SFC load balancing and end-to-end protection. In the latter case 1910 said parallel TE tunnel chains could be placed to be sufficiently 1911 disjoint from each other. 1913 _ 1915 Figure 5: SFC recovery: SFC SF1-SF2-SF6 is recovered after SF2 on 1916 node N1 has failed 1918 _ 1920 Figure 6: SFC recovery: SFC SF1-SF2-SF6 is recovered after node N1 1921 has failed 1923 C.5. Network Clock Synchronization 1925 Many current and future network applications (including 5g and IoT 1926 applications) require very accurate time services (PTP level, ns 1927 resolution). One way to implement the adequate network clock 1928 synchronization for such services is via describing network clocks as 1929 NFs on an NF-aware TE topology optimized to have best possible delay 1930 variation characteristics. Because such a topology will contain 1931 delay/delay variation metrics of topology links and node cross- 1932 connects, as well as costs in terms of delay/delay variation of 1933 connecting clocks to hosting them node link and tunnel termination 1934 points, it will be possible to dynamically select and provision bi- 1935 directional time-constrained deterministic paths or trees connecting 1936 clocks (e.g. grand master and boundary clocks) for the purpose of 1937 exchange of clock synchronization information. Note that network 1938 clock aware TE topologies separately provided by domain controllers 1939 will enable multi-domain network orchestrator to set up and 1940 manipulate the clock synchronization paths/trees spanning multiple 1941 network domains. 1943 C.6. Client - Provider Network Slicing Interface 1945 3GPP defines network slice as "a set of network functions and the 1946 resources for these network functions which are arranged and 1947 configured, forming a complete logical network to meet certain 1948 network characteristics" [I-D.defoy-netslices-3gpp-network-slicing] 1949 [_3GPP.28.801]. Network slice could be also defined as a logical 1950 partition of a provider's network that is owned and managed by a 1951 tenant. SF/NF-aware TE topology model has a potential to support a 1952 very important interface between network slicing clients and 1953 providers because, on the one hand, the model can describe 1954 holistically and hierarchically the client's requirements and 1955 preferences with respect to a network slice functional, topological 1956 and traffic engineering aspects, as well as of the degree of resource 1957 separation/ sharing between the slices, thus allowing for the client 1958 (up to agreed upon extent) to dynamically (re-)configure the slice or 1959 (re-)schedule said (re-)configurations in time, while, on the other 1960 hand, allowing for the provider to convey to the client the slice's 1961 operational state information and telemetry the client has expressed 1962 interest in. 1964 C.7. Dynamic Assignment of Regenerators for L0 Services 1966 On large optical networks, some of provided to their clients L0 1967 services could not be provisioned as single OCh trails, rather, as 1968 chains of such trails interconnected via regenerators, such as 3R 1969 regenerators. Current practice of the provisioning of such services 1970 requires configuration of explicit paths (EROs) describing identity 1971 and location of regenerators to be used. A solution is highly 1972 desirable that could: 1974 o Identify such services based, for example, on optical impairment 1975 computations; 1977 o Assign adequate for the services regenerators dynamically out of 1978 the regenerators that are grouped together in pools and 1979 strategically scattered over the network topology nodes; 1981 o Compute and provision supporting the services chains of optical 1982 trails interconnected via so selected regenerators, optimizing the 1983 chains to use minimal number of regenerators, their optimal 1984 locations, as well as optimality of optical paths interconnecting 1985 them; 1987 o Ensure recovery of such chains from any failures that could happen 1988 on links, nodes or regenerators along the chain path. 1990 NF-aware TE topology model (in this case L1 NF-aware L0 topology 1991 model) is just the model that could provide a network controller (or 1992 even a client controller operating on abstract NF-aware topologies 1993 provided by the network) to realize described above computations and 1994 orchestrate the service provisioning and network failure recovery 1995 operations (see Figure 7). 1997 _ 1999 Figure 7: Optical tunnel as TE-constrained SFC of 3R regenerators. 2000 Red trail (not regenerated) is not optically reachable, but blue 2001 trail (twice regenerated) is 2003 C.8. Dynamic Assignment of OAM Functions for L1 Services 2005 OAM functionality is normally managed by configuring and manipulating 2006 TCM/MEP functions on network ports terminating connections or their 2007 segments over which OAM operations, such as performance monitoring, 2008 are required to be performed. In some layer networks (e.g. 2009 Ethernet) said TCMs/MEPs could be configured on any network ports. 2010 In others (e.g. OTN/ODUk) the TCMs/MEPs could be configured on some 2011 (but not all network ports) due to the fact that the OAM 2012 functionality (i.e. recognizing and processing of OAM messages, 2013 supporting OAM protocols and FSMs) requires in these layer networks 2014 certain support in the data plane, which is not available on all 2015 network nodes. This makes TCMs/MEPs good candidates to be modeled as 2016 NFs. This also makes TCM/MEP aware topology model a good basis for 2017 placing dynamically an ODUk connection to pass through optimal OAM 2018 locations without mandating the client to specify said locations 2019 explicitly. 2021 _ 2023 Figure 8: Compute/storage resource aware topology 2025 C.9. SFC Abstraction and Scaling 2027 SF/NF-aware topology may contain information on native SFs/NFs (i.e. 2028 SFs/NFs as known to the provider itself) and/or abstract SFs/NFs 2029 (i.e. logical/macro SFs/NFs representing one or more SFCs each made 2030 of native and/or lower level abstract SFs/NFs). As in the case of 2031 abstracting topology nodes, abstracting SFs/NFs is hierarchical in 2032 nature - the higher level of SF/NF-aware topology, the "larger" 2033 abstract SFs/NFs are, i.e. the larger data plane SFCs they represent. 2034 This allows for managing large scale networks with great number of 2035 SFs/NFs (such as Data Center interconnects) in a hierarchical, highly 2036 scalable manner resulting in control of very large number of flat in 2037 the data plane SFCs that span multiple domains. 2039 C.10. Dynamic Compute/VM/Storage Resource Assignment 2041 In a distributed data center network, virtual machines for compute 2042 resources may need to be dynamically re-allocated due to various 2043 reasons such as DCI network failure, compute resource load balancing, 2044 etc. In many cases, the DCI connectivity for the source and the 2045 destination is not predetermined. There may be a pool of sources and 2046 a pool of destination data centers associated with re-allocation of 2047 compute/VM/storage resources. There is no good mechanism to date to 2048 capture this dynamicity nature of compute/VM/storage resource 2049 reallocation. Generic Compute/VM/Storage resources can be described 2050 and announced as a SF, where a DC hosting these resources can be 2051 modeled as an abstract node. Topology interconnecting these abstract 2052 nodes (DCs) in general is of multi-domain nature. Thus, SF-aware 2053 topology model can facilitate a joint optimization of TE network 2054 resources and Compute/VM/Storage resources and solve Compute/VM/ 2055 Storage mobility problem within and between DCs (see Figure 8). 2057 C.11. Application-aware Resource Operations and Management 2059 Application stratum is the functional grouping which encompasses 2060 application resources and the control and management of these 2061 resources. These application resources are used along with network 2062 services to provide an application service to clients/end-users. 2063 Application resources are non-network resources critical to achieving 2064 the application service functionality. Examples of application 2065 resources include: caches, mirrors, application specific servers, 2066 content, large data sets, and computing power. Application service 2067 is a networked application offered to a variety of clients (e.g., 2068 server backup, VM migration, video cache, virtual network on-demand, 2069 5G network slicing, etc.). The application servers that host these 2070 application resources can be modeled as an abstract node. There may 2071 be a variety of server types depending on the resources they host. 2072 Figure 9 shows one example application aware topology for video cache 2073 server distribution. 2075 _ 2077 Figure 9: Application aware topology 2079 C.12. IANA Considerations 2081 This document has no actions for IANA. 2083 C.13. Security Considerations 2085 This document does not define networking protocols and data, hence is 2086 not directly responsible for security risks. 2088 C.14. Acknowledgements 2090 The authors would like to thank Maarten Vissers, Joel Halpern, and 2091 Greg Mirsky for their helpful comments and valuable contributions. 2093 Authors' Addresses 2095 Igor Bryskin 2096 Individual 2098 EMail: i_bryskin@yahoo.com 2100 Xufeng Liu 2101 Volta Networks 2103 EMail: xufeng.liu.ietf@gmail.com 2105 Young Lee 2106 Sung Kyun Kwan University 2108 EMail: younglee.tx@gmail.com 2110 Jim Guichard 2111 Huawei Technologies 2113 EMail: james.n.guichard@huawei.com 2115 Luis Miguel Contreras Murillo 2116 Telefonica 2118 EMail: luismiguel.contrerasmurillo@telefonica.com 2119 Daniele Ceccarelli 2120 Ericsson 2122 EMail: daniele.ceccarelli@ericsson.com 2124 Jeff Tantsura 2125 Apstra Networks 2127 EMail: jefftant.ietf@gmail.com