idnits 2.17.1 draft-ietf-teas-sf-aware-topo-model-01.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 640 has weird spacing: '...hecksum str...' == Line 655 has weird spacing: '...hecksum str...' == Line 687 has weird spacing: '...address ine...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 28, 2018) is 2113 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 ---------------------------------------------------------------------------- == Missing Reference: 'RFC3688' is mentioned on line 949, but not defined == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-16 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 Huawei Technologies 4 Intended status: Informational X. Liu 5 Expires: December 30, 2018 Volta Networks 6 Y. Lee 7 Huawei Technologies 8 June 28, 2018 10 SF Aware TE Topology YANG Model 11 draft-ietf-teas-sf-aware-topo-model-01 13 Abstract 15 This document describes a YANG data model for TE network topologies 16 that are network service and function aware. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 30, 2018. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 55 1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 3 56 2. Modeling Considerations . . . . . . . . . . . . . . . . . . . 4 57 3. Model Structure . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 6 59 5. Model Structure . . . . . . . . . . . . . . . . . . . . . . . 13 60 6. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 15 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 64 9.1. Normative References . . . . . . . . . . . . . . . . . . 21 65 9.2. Informative References . . . . . . . . . . . . . . . . . 23 66 Appendix A. Companion YANG Model for Non-NMDA Compliant 67 Implementations . . . . . . . . . . . . . . . . . . 24 68 A.1. SF Aware TE Topology State Module . . . . . . . . . . . . 24 69 Appendix B. Data Examples . . . . . . . . . . . . . . . . . . . 26 70 B.1. A Topology with Multiple Connected Network Functions . . 26 71 B.2. A Topology with an Encapsulated Network Service . . . . . 31 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 74 1. Introduction 76 Today a network offers to its clients far more services than just 77 connectivity across the network. Large variety of physical, logical 78 and/or virtual service functions, network functions and transport 79 functions (collectively named in this document as SFs) could be 80 allocated for and assigned to a client. As described in 81 [I-D.ietf-teas-use-cases-sf-aware-topo-model], there are some 82 important use cases, in which the network needs to represent to the 83 client SFs at the client's disposal as topological elements in 84 relation to other elements of a topology (i.e. nodes, links, link and 85 tunnel termination points) used by the network to describe itself to 86 the client. Not only would such information allow for the client to 87 auto-discover the network's SFs available for the services 88 provisioned for the client, it would also allow for the client 89 selecting the SFs, duel-optimizing the selection on the SF location 90 on the network and connectivity means (e.g. TE tunnels) to inter- 91 connect the SFs. Consequently thus would give to both the network 92 and the client powerful means for the service function chain (SFC 93 [RFC7498] [RFC7665]) negotiation to achieve most efficient and cost 94 effective (from the network point of view) and most optimal yet 95 satisfying all necessary constraints of SFCs(from the client's point 96 of view). 98 This document defines a YANG data model that allows service functions 99 to be represented along with TE topology elements. 101 1.1. Terminology 103 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in BCP 106 14, [RFC2119]. 108 The following terms are defined in [RFC7950] and are not redefined 109 here: 111 o augment 113 o data model 115 o data node 117 1.2. Tree Diagrams 119 A simplified graphical representation of the data model is presented 120 in this document, by using the tree format defined in 121 [I-D.ietf-netmod-yang-tree-diagrams]. 123 1.3. Prefixes in Data Node Names 125 In this document, names of data nodes, actions, and other data model 126 objects are often used without a prefix, as long as it is clear from 127 the context in which YANG module each name is defined. Otherwise, 128 names are prefixed using the standard prefix associated with the 129 corresponding YANG module, as shown in Table 1. 131 +--------+------------------+-----------------------------------+ 132 | Prefix | YANG module | Reference | 133 +--------+------------------+-----------------------------------+ 134 | inet | ietf-inet-types | [RFC6991] | 135 | nw | ietf-network | [I-D.ietf-i2rs-yang-network-topo] | 136 | nt | ietf-network- | [I-D.ietf-i2rs-yang-network-topo] | 137 | | topology | | 138 | tet | ietf-te-topology | [I-D.ietf-teas-yang-te-topo] | 139 +--------+------------------+-----------------------------------+ 141 Table 1: Prefixes and Corresponding YANG Modules 143 2. Modeling Considerations 145 The model introduced in this document is an augmentation of the TE 146 Topology model defined in [I-D.ietf-teas-yang-te-topo]. SFs are 147 modeled as child elements of a TE node similarly to how Link 148 Termination Points (LTPs) and Tunnel Termination Points (TTPs) are 149 modeled in the TE Topology model. The SFs are defined as opaque 150 objects identified via topology unique service-function-id's. Each 151 SF has one or more Connection Points (CPs) identified via SF-unique 152 sf-connection-point-id's, over which the SF could be connected to 153 other SFs resided on the same TE node, as well as to other elements 154 of the TE node, in particular, to the node's LTPs and/or TTPs. An 155 interested client may use service-function-id's to look up the SFs in 156 TOSCA or YANG data store(s) defined by [ETSI-NFV-MAN] to retrieve the 157 details of the SFs, for example, to understand the SF's mutual 158 substitutability. 160 The TE Topology model introduces a concept of Connectivity Matrix 161 (CM), and uses the CM to describe which and at what costs a TE node's 162 LTPs could be inter-connected internally across the TE node. The 163 model defined in this document heavily uses the same concept to 164 describe the SF connectivity via introducing 3 additional CMs: 166 1. SF2SF CM. This CM describes which pairs of SFs could be locally 167 inter-connected, and, if yes, in which direction, via which CPs 168 and at what costs. In other words, the SF2SF CM describes how 169 SFs residing on the same TE node could be inter-connected into 170 local from the TE node's perspective SFCs; 172 2. SF2LTP CM. This CM describes how, in which direction and at what 173 costs the TE node's SFs could be connected to the TE node's LTPs 174 and hence to SFs residing on neighboring TE nodes that are 175 connected to LTPs at the remote ends of corresponding TE links; 177 3. SF2TTP CM. This CM describes how, in which direction and at what 178 costs the TE node's SFs could be connected to the TE node's TTPs 179 and hence to SFs residing on other TE nodes on the topology that 180 could be inter-connected with the TE node in question via TE 181 tunnels terminated by the corresponding TTPs. 183 In addition to SF2SF CM, the local SF chaining could be described 184 with the help of ETSI models Virtual Links (VLs) [ETSI-NFV-MAN]. 185 This option is especially useful when the costs of the local chaining 186 are negligible as compared to ones of the end-to-end SFCs said local 187 SFCs are part of. 189 Section 3 and 4 provide the YANG model structure and the YANG module 190 for SF-aware Topology. Section 5 and 6 provide the YANG model 191 structure and the YANG module for Data Center Compute Node resource 192 abstraction. This provides an example of SF2LTP CM where DC compute 193 nodes are connected to LTPs at the remote ends of the corresponding 194 TE links. This use-case is described in Section 12 of 195 [I-D.ietf-teas-use-cases-sf-aware-topo-model]. 197 3. Model Structure 199 module: ietf-te-topology-sf 200 augment /nw:networks/nw:network/nw:network-types/tet:te-topology: 201 +--rw sf! 202 augment /nw:networks/nw:network/nw:node/tet:te 203 /tet:te-node-attributes: 204 +--rw service-function 205 +--rw connectivity-matrices 206 | +--rw connectivity-matrix* [id] 207 | +--rw id uint32 208 | +--rw from 209 | | +--rw service-function-id? string 210 | | +--rw sf-connection-point-id? string 211 | +--rw to 212 | | +--rw service-function-id? string 213 | | +--rw sf-connection-point-id? string 214 | +--rw enabled? boolean 215 | +--rw direction? connectivity-direction 216 | +--rw virtual-link-id? string 217 +--rw link-terminations 218 +--rw link-termination* [id] 219 +--rw id uint32 220 +--rw from 221 | +--rw tp-ref? -> ../../../../../../.. 222 /nt:termination-point/tp-id 223 +--rw to 224 | +--rw service-function-id? string 225 | +--rw sf-connection-point-id? string 226 +--rw enabled? boolean 227 +--rw direction? connectivity-direction 228 augment /nw:networks/nw:network/nw:node/tet:te 229 /tet:information-source-entry: 230 +--ro service-function 231 +--ro connectivity-matrices 232 | +--ro connectivity-matrix* [id] 233 | +--ro id uint32 234 | +--ro from 235 | | +--ro service-function-id? string 236 | | +--ro sf-connection-point-id? string 237 | +--ro to 238 | | +--ro service-function-id? string 239 | | +--ro sf-connection-point-id? string 240 | +--ro enabled? boolean 241 | +--ro direction? connectivity-direction 242 | +--ro virtual-link-id? string 243 +--ro link-terminations 244 +--ro link-termination* [id] 245 +--ro id uint32 246 +--ro from 247 +--ro to 248 | +--ro service-function-id? string 249 | +--ro sf-connection-point-id? string 250 +--ro enabled? boolean 251 +--ro direction? connectivity-direction 252 augment /nw:networks/nw:network/nw:node/tet:te 253 /tet:tunnel-termination-point: 254 +--rw service-function 255 +--rw tunnel-terminations 256 +--rw tunnel-termination* [id] 257 +--rw id uint32 258 +--rw service-function-id? string 259 +--rw sf-connection-point-id? string 260 +--rw enabled? boolean 261 +--rw direction? connectivity-direction 263 4. YANG Modules 265 file "ietf-te-topology-sf@2018-02-27.yang" 266 module ietf-te-topology-sf { 267 yang-version 1; 268 namespace "urn:ietf:params:xml:ns:yang:ietf-te-topology-sf"; 270 prefix "tet-sf"; 272 import ietf-network { 273 prefix "nw"; 274 } 276 import ietf-network-topology { 277 prefix "nt"; 278 } 280 import ietf-te-topology { 281 prefix "tet"; 282 } 284 organization 285 "Traffic Engineering Architecture and Signaling (TEAS) 286 Working Group"; 288 contact 289 "WG Web: 290 WG List: 292 Editors: Igor Bryskin 293 295 Xufeng Liu 296 "; 298 description 299 "Network service and function aware aware TE topology model. 301 Copyright (c) 2018 IETF Trust and the persons identified as 302 authors of the code. All rights reserved. 304 Redistribution and use in source and binary forms, with or 305 without modification, is permitted pursuant to, and subject to 306 the license terms contained in, the Simplified BSD License set 307 forth in Section 4.c of the IETF Trust's Legal Provisions 308 Relating to IETF Documents 309 (http://trustee.ietf.org/license-info)."; 311 revision 2018-02-27 { 312 description "Initial revision"; 313 reference "TBD"; 314 } 316 /* 317 * Typedefs 318 */ 319 typedef connectivity-direction { 320 type enumeration { 321 enum "to" { 322 description 323 "The direction is uni-directional, towards the 'to' 324 entity direction."; 325 } 326 enum "from" { 327 description 328 "The direction is uni-directional, from the 'to' 329 entity direction."; 330 } 331 enum "bidir" { 332 description 333 "The direction is bi-directional."; 334 } 335 } 336 description 337 "A type used to indicates whether a connectivity is 338 uni-directional, or bi-directional. If the relation is 339 uni-directional, the value of this type indicates the 340 direction."; 341 } // connectivity-direction 343 /* 344 * Groupings 345 */ 346 grouping service-function-node-augmentation { 347 description 348 "Augmenting a TE node to be network service and function 349 aware."; 350 container service-function { 351 description 352 "Containing attributes related to network services and 353 network functions"; 354 container connectivity-matrices { 355 description 356 "Connectivity relations between network services/functions 357 on a TE node, which can be either abstract or physical."; 358 reference 359 "ETSI GS NFV-MAN 01: Network Functions Virtualisation 360 (NFV); Management and Orchestration. 361 RFC7665: Service Function Chaining (SFC) Architecture."; 362 list connectivity-matrix { 363 key "id"; 364 description 365 "Represents the connectivity relations between network 366 services/functions on a TE node."; 367 leaf id { 368 type uint32; 369 description "Identifies the connectivity-matrix entry."; 370 } 372 container from { 373 description 374 "Reference to the source network service or 375 network function."; 376 leaf service-function-id { 377 type string; 378 description 379 "Reference to a network service or a network 380 function."; 382 } 383 leaf sf-connection-point-id { 384 type string; 385 description 386 "Reference to a connection point on a network 387 service or a network function."; 388 } 389 } // from 390 container to { 391 description 392 "Reference to the destination network service or 393 network function."; 394 leaf service-function-id { 395 type string; 396 description 397 "Reference to a network service or a network 398 function."; 399 } 400 leaf sf-connection-point-id { 401 type string; 402 description 403 "Reference to a connection point on a network 404 service or a network function."; 405 } 406 } // to 407 leaf enabled { 408 type boolean; 409 description 410 "'true' if this connectivity entry is enabled."; 411 } 412 leaf direction { 413 type connectivity-direction; 414 description 415 "Indicates whether this connectivity is 416 uni-directional, or bi-directional. If the 417 relation is uni-directional, the value of 418 this leaf indicates the direction."; 419 } 420 leaf virtual-link-id { 421 type string; 422 description 423 "Reference to a virtual link that models this 424 conectivity relation in the network function 425 model."; 426 } 427 } // connectivity-matrix 428 } // connectivity-matrices 429 container link-terminations { 430 description 431 "Connectivity relations between network services/functions 432 and link termination points on a TE node, which can be 433 either abstract or physical."; 434 reference 435 "ETSI GS NFV-MAN 01: Network Functions Virtualisation 436 (NFV); Management and Orchestration. 437 RFC7665: Service Function Chaining (SFC) Architecture."; 438 list link-termination { 439 key "id"; 440 description 441 "Each entry of the list represents the connectivity 442 relation between a network service/function and 443 a link termination point on a TE node."; 444 leaf id { 445 type uint32; 446 description "Identifies the termination entry."; 447 } 449 container from { 450 description 451 "Reference to the link termination point."; 452 } // from 453 container to { 454 description 455 "Reference to the network service or network 456 function."; 457 leaf service-function-id { 458 type string; 459 description 460 "Reference to a network service or a network 461 function."; 462 } 463 leaf sf-connection-point-id { 464 type string; 465 description 466 "Reference to a connection point on a network 467 service or a network function."; 468 } 469 } // to 470 leaf enabled { 471 type boolean; 472 description 473 "'true' if this connectivity entry is enabled."; 474 } 475 leaf direction { 476 type connectivity-direction; 477 description 478 "Indicates whether this connectivity is 479 uni-directional, or bi-directional. If the 480 relation is uni-directional, the value of 481 this leaf indicates the direction."; 482 } 483 } // link-termination 484 } 485 } 486 } // service-function-node-augmentation 488 grouping service-function-ttp-augmentation { 489 description 490 "Augmenting a tunnel termination point to be network service 491 aware."; 492 container service-function { 493 description 494 "Containing attributes related to network services and 495 network functions"; 496 container tunnel-terminations { 497 description 498 "Connectivity relations between network services/functions 499 and tunnel termination points on a TE node, which can be 500 either abstract or physical."; 501 reference 502 "ETSI GS NFV-MAN 01: Network Functions Virtualisation 503 (NFV); Management and Orchestration. 504 RFC7665: Service Function Chaining (SFC) Architecture."; 505 list tunnel-termination { 506 key "id"; 507 description 508 "Each entry of the list represents the connectivity 509 relation between a network service/function and 510 a tunnel termination point on a TE node."; 511 leaf id { 512 type uint32; 513 description "Identifies the termination entry."; 514 } 516 leaf service-function-id { 517 type string; 518 description 519 "Reference to a network service or a network 520 function."; 521 } 522 leaf sf-connection-point-id { 523 type string; 524 description 525 "Reference to a connection point on a network 526 service or a network function."; 527 } 528 leaf enabled { 529 type boolean; 530 description 531 "'true' if this connectivity entry is enabled."; 532 } 533 leaf direction { 534 type connectivity-direction; 535 description 536 "Indicates whether this connectivity is 537 uni-directional, or bi-directional. If the 538 relation is uni-directional, the value of 539 this leaf indicates the direction."; 540 } 541 } // link-termination 542 } 543 } 544 } // service-function-ttp-augmentation 546 grouping sf-topology-type { 547 description 548 "Identifies the SF aware TE topology type."; 549 container sf { 550 presence "Indidates that the TE topology is SF aware."; 551 description 552 "Its presence identifies that the TE topology is SF aware."; 553 } 554 } // sf-topology-type 556 /* 557 * Augmentations 558 */ 559 /* Augmentations to network-types/te-topology */ 560 augment "/nw:networks/nw:network/nw:network-types/" 561 + "tet:te-topology" { 562 description 563 "Defines the SF aware TE topology type."; 564 uses sf-topology-type; 565 } 567 /* Augmentations to te-node-attributes */ 568 augment "/nw:networks/nw:network/nw:node/tet:te/" 569 + "tet:te-node-attributes" { 570 description 571 "Parameters for SF aware TE topology."; 572 uses service-function-node-augmentation; 574 } 576 augment "/nw:networks/nw:network/nw:node/tet:te/" 577 + "tet:information-source-entry" { 578 description 579 "Parameters for SF aware TE topology."; 580 uses service-function-node-augmentation; 581 } 583 /* Augmentations to tunnel-termination-point */ 584 augment "/nw:networks/nw:network/nw:node/tet:te/" 585 + "tet:tunnel-termination-point" { 586 description 587 "Parameters for SF aware TE topology."; 588 uses service-function-ttp-augmentation; 589 } 591 /* Augmentations to connectivity-matrix */ 592 augment "/nw:networks/nw:network/nw:node/tet:te/" 593 + "tet:te-node-attributes/tet-sf:service-function/" 594 + "tet-sf:link-terminations/tet-sf:link-termination/" 595 + "tet-sf:from" { 596 description 597 "Add reference to the link termination point. 598 This portion cannot be shared with the state module."; 599 leaf tp-ref { 600 type leafref { 601 path "../../../../../../../nt:termination-point/" 602 + "nt:tp-id"; 603 } 604 description 605 "Reference to the link termination point."; 606 } 607 } 608 } 609 611 5. Model Structure 613 module: ietf-cso-dc 614 +--rw cso 615 +--rw dc* [id] 616 | +--rw hypervisor* [id] 617 | | +--rw ram 618 | | | +--rw total? uint32 619 | | | +--rw used? uint32 620 | | | +--rw free? uint32 621 | | +--rw disk 622 | | | +--rw total? uint32 623 | | | +--rw used? uint32 624 | | | +--rw free? uint32 625 | | +--rw vcpu 626 | | | +--rw total? uint16 627 | | | +--rw used? uint16 628 | | | +--rw free? uint16 629 | | +--rw instance* -> /cso/dc/instance/id 630 | | +--rw id string 631 | | +--rw name? string 632 | +--rw instance* [id] 633 | | +--rw flavor 634 | | | +--rw disk? uint32 635 | | | +--rw ram? uint32 636 | | | +--rw vcpus? uint16 637 | | | +--rw id? string 638 | | | +--rw name? string 639 | | +--rw image 640 | | | +--rw checksum string 641 | | | +--rw size uint32 642 | | | +--rw format 643 | | | | +--rw container? enumeration 644 | | | | +--rw disk? enumeration 645 | | | +--rw id? string 646 | | | +--rw name? string 647 | | +--rw hypervisor? -> /cso/dc/hypervisor/id 648 | | +--rw port* -> /cso/dc/network/subnetwork/port 649 /id 650 | | +--rw project? string 651 | | +--rw status? enumeration 652 | | +--rw id string 653 | | +--rw name? string 654 | +--rw image* [id] 655 | | +--rw checksum string 656 | | +--rw size uint32 657 | | +--rw format 658 | | | +--rw container? enumeration 659 | | | +--rw disk? enumeration 660 | | +--rw id string 661 | | +--rw name? string 662 | +--rw flavor* [id] 663 | | +--rw disk? uint32 664 | | +--rw ram? uint32 665 | | +--rw vcpus? uint16 666 | | +--rw id string 667 | | +--rw name? string 668 | +--rw dc-monitoring-param* [name] 669 | | +--rw name string 670 | | +--rw value-string? string 671 | +--rw network* [id] 672 | | +--rw subnetwork* [id] 673 | | | +--rw port* [id] 674 | | | | +--rw ip-address? inet:ip-address 675 | | | | +--rw instance? -> /cso/dc/instance/id 676 | | | | +--rw project? string 677 | | | | +--rw status? enumeration 678 | | | | +--rw id string 679 | | | | +--rw name? string 680 | | | +--rw project? string 681 | | | +--rw status? enumeration 682 | | | +--rw id string 683 | | | +--rw name? string 684 | | +--rw dhcp-agent* [id] 685 | | | +--rw enabled? boolean 686 | | | +--rw pools* [ip-address] 687 | | | | +--rw ip-address inet:ip-address 688 | | | +--rw project? string 689 | | | +--rw status? enumeration 690 | | | +--rw id string 691 | | | +--rw name? string 692 | | +--rw project? string 693 | | +--rw status? enumeration 694 | | +--rw id string 695 | | +--rw name? string 696 | | +--rw cso-ref? -> /cso/cso-id 697 | +--rw ap* -> /actn-vn:actn/ap 698 /access-point-list/access-point-id 699 | +--rw cso-ref? -> /cso/cso-id 700 | +--rw id string 701 | +--rw name? string 702 +--rw cso-id? string 704 6. YANG Modules 706 file "ietf-cso-dc@2017-01-16.yang" 707 module ietf-cso-dc 708 { 709 namespace "urn:ietf:params:xml:ns:yang:ietf-cso-dc"; 710 prefix "dc"; 712 import ietf-inet-types { 713 prefix "inet"; 715 } 717 import ietf-actn-vn { 718 prefix "actn-vn"; 719 } 721 revision 2017-01-16 { 722 description 723 "Initial revision. This YANG file defines 724 the reusable base types for CSO DC description."; 725 reference 726 "Derived from earlier versions of base YANG files"; 727 } 729 // Abstract models 730 grouping resource-element { 731 leaf id { type string; } 732 leaf name { type string; } 733 } 735 grouping resource-instance { 736 leaf project{ type string; } 737 leaf status { 738 type enumeration { 739 enum active; 740 enum inactive; 741 enum pending; 742 } 743 } 744 uses resource-element; 745 } 747 // Compute models 748 grouping format { 749 leaf container { 750 type enumeration { 751 enum ami; 752 enum ari; 753 enum aki; 754 enum bare; 755 enum ovf; 756 } 757 default bare; 758 } 759 leaf disk { 760 type enumeration { 761 enum ami; 762 enum ari; 763 enum aki; 764 enum vhd; 765 enum vmdk; 766 enum raw; 767 enum qcow2; 768 enum vdi; 769 enum iso; 770 } 771 default qcow2; 772 } 773 } 775 grouping image { 776 leaf checksum { type string; mandatory true; } 777 leaf size { type uint32; units 'Bytes'; mandatory true; } 779 container format { 780 uses format; 781 } 783 uses resource-element; 784 } 786 grouping flavor { 787 leaf disk { type uint32; units 'GB'; default 0; } 788 leaf ram { type uint32; units 'MB'; default 0; } 789 leaf vcpus { type uint16; default 0; } 790 uses resource-element; 791 } 793 grouping ram { 794 leaf total { type uint32; units 'MB'; } 795 leaf used { type uint32; units 'MB'; } 796 leaf free { type uint32; units 'MB'; } 797 } 799 grouping disk { 800 leaf total { type uint32; units 'GB'; } 801 leaf used { type uint32; units 'GB'; } 802 leaf free { type uint32; units 'GB'; } 803 } 805 grouping vcpu { 806 leaf total { type uint16; } 807 leaf used { type uint16; } 808 leaf free { type uint16; } 809 } 810 grouping hypervisor { 812 container ram { 813 uses ram; 814 } 816 container disk { 817 uses disk; 818 } 820 container vcpu { 821 uses vcpu; 822 } 824 leaf-list instance { 825 type leafref { path '/cso/dc/instance/id'; } } 826 uses resource-element; 827 } 829 grouping instance { 830 container flavor { uses flavor; } 831 container image { uses image; } 832 leaf hypervisor { 833 type leafref { path '/cso/dc/hypervisor/id'; } } 834 leaf-list port { type leafref { 835 path '/cso/dc/network/subnetwork/port/id'; } } 836 uses resource-instance; 837 } 839 grouping dc-monitoring-param { 840 leaf name { 841 description "dc-monitoring-param identifier"; type string; } 842 leaf value-string { 843 description 844 "Current value for a string parameter"; 845 type string; 846 } 847 } 849 grouping dc { 851 list hypervisor { 852 key id; 853 uses hypervisor; 854 } 856 list instance { 857 key id; 858 uses instance; 859 } 861 list image { 862 key id; 863 uses image; 864 } 866 list flavor { 867 key id; 868 uses flavor; 869 } 871 list dc-monitoring-param { 872 key "name"; 873 uses dc-monitoring-param; 874 } 876 list network { 877 key id; 878 uses network; 879 } 881 leaf-list ap { type leafref { 882 path 883 '/actn-vn:actn/actn-vn:ap/actn-vn:access-point-list/' 884 + 'actn-vn:access-point-id'; 885 } 886 } 887 leaf cso-ref { type leafref { path "/cso/cso-id"; } } 888 uses resource-element; 889 } 891 container cso { 892 list dc { 893 key id; 894 uses dc; 895 } 897 leaf cso-id { type string; } 898 } 900 // Network models 901 grouping ip-address { 902 leaf ip-address { type inet:ip-address; } 903 } 904 grouping dhcp-agent { 905 leaf enabled { type boolean; } 906 list pools { 907 key ip-address; 908 uses ip-address; 909 } 910 uses resource-instance; 911 } 913 grouping network { 914 list subnetwork { 915 key id; 916 uses subnetwork; 917 } 918 list dhcp-agent { 919 key id; 920 uses dhcp-agent; 921 } 922 uses resource-instance; 923 leaf cso-ref { type leafref { path "/cso/cso-id"; } } 924 } 926 grouping subnetwork { 927 list port { 928 key id; 929 uses port; 930 } 931 uses resource-instance; 932 } 934 grouping port { 935 leaf ip-address { type inet:ip-address; } 936 leaf instance { type leafref { path '/cso/dc/instance/id'; } } 937 uses resource-instance; 938 } 940 } 941 943 7. IANA Considerations 945 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 946 actual RFC number (and remove this note). 948 This document registers the following namespace URIs in the IETF XML 949 registry [RFC3688]: 951 -------------------------------------------------------------------- 952 URI: urn:ietf:params:xml:ns:yang:ietf-te-topology-sf 953 Registrant Contact: The IESG. 954 XML: N/A, the requested URI is an XML namespace. 955 -------------------------------------------------------------------- 957 -------------------------------------------------------------------- 958 URI: urn:ietf:params:xml:ns:yang:ietf-te-topology-sf-state 959 Registrant Contact: The IESG. 960 XML: N/A, the requested URI is an XML namespace. 961 -------------------------------------------------------------------- 963 This document registers the following YANG modules in the YANG Module 964 Names registry [RFC7950]: 966 -------------------------------------------------------------------- 967 name: ietf-te-topology-sf 968 namespace: urn:ietf:params:xml:ns:yang:ietf-te-topology-packet 969 prefix: tet-sf 970 reference: RFC XXXX 971 -------------------------------------------------------------------- 973 -------------------------------------------------------------------- 974 name: ietf-te-topology-sf-state 975 namespace: urn:ietf:params:xml:ns:yang:ietf-te-topology-packet-state 976 prefix: tet-sf-s 977 reference: RFC XXXX 978 -------------------------------------------------------------------- 980 8. Security Considerations 982 The configuration, state, action and notification data defined in 983 this document are designed to be accessed via the NETCONF protocol 984 [RFC6241]. The data-model by itself does not create any security 985 implications. The security considerations for the NETCONF protocol 986 are applicable. The NETCONF protocol used for sending the data 987 supports authentication and encryption. 989 9. References 991 9.1. Normative References 993 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 994 Requirement Levels", BCP 14, RFC 2119, 995 DOI 10.17487/RFC2119, March 1997, 996 . 998 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 999 and A. Bierman, Ed., "Network Configuration Protocol 1000 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1001 . 1003 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1004 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1005 . 1007 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1008 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1009 . 1011 [ETSI-NFV-MAN] 1012 ETSI, "Network Functions Virtualisation (NFV); Management 1013 and Orchestration", ETSI GS NFV-MAN 001 V1.1.1, December 1014 2014. 1016 [I-D.ietf-teas-use-cases-sf-aware-topo-model] 1017 Bryskin, I., Liu, X., Guichard, J., Lee, Y., Contreras, 1018 L., Ceccarelli, D., and J. Tantsura, "Use Cases for SF 1019 Aware Topology Models", draft-ietf-teas-use-cases-sf- 1020 aware-topo-model-00 (work in progress), June 2018. 1022 [I-D.ietf-i2rs-yang-network-topo] 1023 Clemm, A., Medved, J., Varga, R., Bahadur, N., 1024 Ananthakrishnan, H., and X. Liu, "A Data Model for Network 1025 Topologies", draft-ietf-i2rs-yang-network-topo-20 (work in 1026 progress), December 2017. 1028 [I-D.ietf-teas-yang-te-topo] 1029 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1030 O. Dios, "YANG Data Model for Traffic Engineering (TE) 1031 Topologies", draft-ietf-teas-yang-te-topo-16 (work in 1032 progress), June 2018. 1034 [I-D.ietf-netmod-revised-datastores] 1035 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1036 and R. Wilton, "Network Management Datastore 1037 Architecture", draft-ietf-netmod-revised-datastores-10 1038 (work in progress), January 2018. 1040 9.2. Informative References 1042 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 1043 Service Function Chaining", RFC 7498, 1044 DOI 10.17487/RFC7498, April 2015, 1045 . 1047 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1048 Chaining (SFC) Architecture", RFC 7665, 1049 DOI 10.17487/RFC7665, October 2015, 1050 . 1052 [I-D.ietf-netmod-yang-tree-diagrams] 1053 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 1054 ietf-netmod-yang-tree-diagrams-06 (work in progress), 1055 February 2018. 1057 Appendix A. Companion YANG Model for Non-NMDA Compliant Implementations 1059 The YANG module ietf-te-topology-sf defined in this document is 1060 designed to be used in conjunction with implementations that support 1061 the Network Management Datastore Architecture (NMDA) defined in 1062 [I-D.ietf-netmod-revised-datastores]. In order to allow 1063 implementations to use the model even in cases when NMDA is not 1064 supported, the following companion module, ietf-te-topology-sf-state, 1065 is defined as state model, which mirrors the module ietf-te-topology- 1066 sf defined earlier in this document. However, all data nodes in the 1067 companion module are non-configurable, to represent the applied 1068 configuration or the derived operational states. 1070 The companion module, ietf-te-topology-sf-state, is redundant and 1071 SHOULD NOT be supported by implementations that support NMDA. 1073 As the structure of the companion module mirrors that of the 1074 coorespinding NMDA model, the YANG tree of the companion module is 1075 not depicted separately. 1077 A.1. SF Aware TE Topology State Module 1079 file "ietf-te-topology-sf-state@2018-02-27.yang" 1080 module ietf-te-topology-sf-state { 1081 yang-version 1; 1082 namespace "urn:ietf:params:xml:ns:yang:ietf-te-topology-sf-state"; 1084 prefix "tet-sf-s"; 1086 import ietf-te-topology-sf { 1087 prefix "tet-sf"; 1088 } 1090 import ietf-network-state { 1091 prefix "nw-s"; 1092 } 1094 import ietf-network-topology-state { 1095 prefix "nt-s"; 1096 } 1098 import ietf-te-topology-state { 1099 prefix "tet-s"; 1100 } 1102 organization 1103 "Traffic Engineering Architecture and Signaling (TEAS) 1104 Working Group"; 1106 contact 1107 "WG Web: 1108 WG List: 1110 Editors: Igor Bryskin 1111 1113 Xufeng Liu 1114 "; 1116 description 1117 "Network service and function aware aware TE topology operational 1118 state model for non-NMDA compliant implementations. 1120 Copyright (c) 2018 IETF Trust and the persons identified as 1121 authors of the code. All rights reserved. 1123 Redistribution and use in source and binary forms, with or 1124 without modification, is permitted pursuant to, and subject to 1125 the license terms contained in, the Simplified BSD License set 1126 forth in Section 4.c of the IETF Trust's Legal Provisions 1127 Relating to IETF Documents 1128 (http://trustee.ietf.org/license-info)."; 1130 revision 2018-02-27 { 1131 description "Initial revision"; 1132 reference "TBD"; 1133 } 1135 /* 1136 * Augmentations 1137 */ 1138 /* Augmentations to network-types/te-topology */ 1139 augment "/nw-s:networks/nw-s:network/nw-s:network-types/" 1140 + "tet-s:te-topology" { 1141 description 1142 "Defines the SF aware TE topology type."; 1143 uses tet-sf:sf-topology-type; 1144 } 1146 /* Augmentations to connectivity-matrix */ 1147 augment "/nw-s:networks/nw-s:network/nw-s:node/tet-s:te/" 1148 + "tet-s:te-node-attributes" { 1149 description 1150 "Parameters for SF aware TE topology."; 1151 uses tet-sf:service-function-node-augmentation; 1153 } 1155 augment "/nw-s:networks/nw-s:network/nw-s:node/tet-s:te/" 1156 + "tet-s:information-source-entry" { 1157 description 1158 "Parameters for SF aware TE topology."; 1159 uses tet-sf:service-function-node-augmentation; 1160 } 1162 /* Augmentations to tunnel-termination-point */ 1163 augment "/nw-s:networks/nw-s:network/nw-s:node/tet-s:te/" 1164 + "tet-s:tunnel-termination-point" { 1165 description 1166 "Parameters for SF aware TE topology."; 1167 uses tet-sf:service-function-ttp-augmentation; 1168 } 1170 /* Augmentations to connectivity-matrix */ 1171 augment "/nw-s:networks/nw-s:network/nw-s:node/tet-s:te/" 1172 + "tet-s:te-node-attributes/tet-sf-s:service-function/" 1173 + "tet-sf-s:link-terminations/tet-sf-s:link-termination/" 1174 + "tet-sf-s:from" { 1175 description 1176 "Add reference to the link termination point. 1177 This portion cannot be shared with the state module."; 1178 leaf tp-ref { 1179 type leafref { 1180 path "../../../../../../../nt-s:termination-point/" 1181 + "nt-s:tp-id"; 1182 } 1183 description 1184 "Reference to the link termination point."; 1185 } 1186 } 1187 } 1188 1190 Appendix B. Data Examples 1192 B.1. A Topology with Multiple Connected Network Functions 1193 Node-1 1194 +----o--o--------------------------o-------+ 1195 | | | | | 1196 | \__/ \__ | 1197 | *\/ TTP-1 * * * * * * * * * *\/* | 1198 LTP-4 |* * * * TTP-2 * | LTP-1 1199 o------------*-----------------------------o 1200 | * * | 1201 LTP-3 |* * * * * *| LTP-2 1202 o--- -----o 1203 | \ / | 1204 | \ / | 1205 | \ CP01 CP02/ | 1206 | +----o--------------------------o------+ | 1207 | | VL1| VL4| | | 1208 | | |CP11 |CP33 | | 1209 | | +-o--+ +----+ +-o--+ | | 1210 | | |VNF1| |VNF2| |VNF3| | | 1211 | | +-o-o+ VL2 +--o-+ VL2 +-o-o+ | | 1212 | |CP12| |\----------/ \---------/| |CP32| | 1213 | | | |CP13 CP21 CP31| | | | 1214 | | | | VL2 | | | | 1215 | | | +------------------------+ | | | 1216 | | +----------------------------+ | | 1217 | | VL3 | | 1218 | | Network Service 1 | | 1219 | +--------------------------------------+ | 1220 +------------------------------------------+ 1222 The configuration instance data for Node-1 in the above figure could 1223 be as follows: 1225 { 1226 "networks": { 1227 "network": [ 1228 { 1229 "network-types": { 1230 "te-topology": { 1231 "sf": {} 1232 } 1233 }, 1234 "network-id": "network-sf-aware", 1235 "provider-id": 201, 1236 "client-id": 300, 1237 "te-topology-id": "te-topology:network-sf-aware", 1238 "node": [ 1239 { 1240 "node-id": "Node-1", 1241 "te-node-id": "2.0.1.1", 1242 "te": { 1243 "te-node-attributes": { 1244 "domain-id": 1, 1245 "is-abstract": [null], 1246 "connectivity-matrices": { 1247 }, 1248 "service-function": { 1249 "connectivity-matrices": { 1250 "connectivity-matrix": [ 1251 { 1252 "id": 10, 1253 "from": { 1254 "service-function-id": "Network Service 1", 1255 "sf-connection-point-id": "CP01" 1256 }, 1257 "to": { 1258 "service-function-id": "VNF1", 1259 "sf-connection-point-id": "CP11" 1260 } 1261 "direction": "bidir", 1262 "virtual-link-id": "VL1" 1263 }, 1264 { 1265 "id": 13, 1266 "from": { 1267 "service-function-id": "VNF1", 1268 "sf-connection-point-id": "CP12" 1269 }, 1270 "to": { 1271 "service-function-id": "VNF3", 1272 "sf-connection-point-id": "CP32" 1273 } 1274 "direction": "bidir", 1275 "virtual-link-id": "VL3" 1276 }, 1277 { 1278 "id": 12, 1279 "from": { 1280 "service-function-id": "VNF1", 1281 "sf-connection-point-id": "CP13" 1282 }, 1283 "to": { 1284 "service-function-id": "VNF2", 1285 "sf-connection-point-id": "CP21" 1286 } 1287 "direction": "bidir", 1288 "virtual-link-id": "VL2" 1290 }, 1291 { 1292 "id": 23, 1293 "from": { 1294 "service-function-id": "VNF2", 1295 "sf-connection-point-id": "CP21" 1296 }, 1297 "to": { 1298 "service-function-id": "VNF3" 1299 "sf-connection-point-id": "CP31" 1300 } 1301 "direction": "bidir", 1302 "virtual-link-id": "VL2" 1303 }, 1304 { 1305 "id": 30, 1306 "from": { 1307 "service-function-id": "Network Service 1", 1308 "sf-connection-point-id": "CP02" 1309 }, 1310 "to": { 1311 "service-function-id": "VNF3", 1312 "sf-connection-point-id": "CP33" 1313 } 1314 "direction": "bidir", 1315 "virtual-link-id": "VL4" 1316 } 1317 ] 1318 }, 1319 "link-terminations": { 1320 "link-termination": [ 1321 { 1322 "id": 2, 1323 "from": { 1324 "tp-ref": "LTP-2" 1325 }, 1326 "to": { 1327 "service-function-id": "Network Service 1", 1328 "sf-connection-point-id": "CP02" 1329 } 1330 "direction": "bidir" 1331 }, 1332 { 1333 "id": 3, 1334 "from": { 1335 "tp-ref": "LTP-3" 1336 }, 1337 "to": { 1338 "service-function-id": "Network Service 1", 1339 "sf-connection-point-id": "CP01" 1340 } 1341 "direction": "bidir" 1342 } 1343 ] 1344 } 1345 } 1346 } 1347 "tunnel-termination-point": [ 1348 { 1349 "tunnel-tp-id": 10001, 1350 "name": "TTP-1", 1351 "service-function-terminations": { 1352 } 1353 }, 1354 { 1355 "tunnel-tp-id": 10002, 1356 "name": "TTP-2", 1357 "service-function-terminations": { 1358 } 1359 } 1360 ] 1361 }, 1362 "termination-point": [ 1363 { 1364 "tp-id": "LTP-1", 1365 "te-tp-id": 10001 1366 "te": { 1367 "interface-switching-capability": [ 1368 { 1369 "switching-capability": "switching-l2sc", 1370 "encoding": "lsp-encoding-ethernet" 1371 } 1372 ] 1373 } 1374 }, 1375 { 1376 "tp-id": "LTP-2", 1377 "te-tp-id": 10002 1378 "te": { 1379 "interface-switching-capability": [ 1380 { 1381 "switching-capability": "switching-l2sc", 1382 "encoding": "lsp-encoding-ethernet" 1383 } 1384 ] 1385 } 1387 }, 1388 { 1389 "tp-id": "LTP-3", 1390 "te-tp-id": 10003 1391 "te": { 1392 "interface-switching-capability": [ 1393 { 1394 "switching-capability": "switching-l2sc", 1395 "encoding": "lsp-encoding-ethernet" 1396 } 1397 ] 1398 } 1399 }, 1400 { 1401 "tp-id": "LTP-4", 1402 "te-tp-id": 10004 1403 "te": { 1404 "interface-switching-capability": [ 1405 { 1406 "switching-capability": "switching-l2sc", 1407 "encoding": "lsp-encoding-ethernet" 1408 } 1409 ] 1410 } 1411 } 1412 ] 1413 } 1414 ] 1415 } 1416 ] 1417 } 1418 } 1420 B.2. A Topology with an Encapsulated Network Service 1422 In this example, a network service consists of several inter- 1423 connected network functions (NFs), and is represented by this model 1424 as an encapsulated opaque object without the details between its 1425 internals. 1427 Node-1 1428 +----o--o--------------------------o-------+ 1429 | | | | | 1430 | \__/ \__ | 1431 | *\/ TTP-1 * * * * * * * * * *\/* | 1432 LTP-4 |* * * * TTP-2 * | LTP-1 1433 o------------*-----------------------------o 1434 | * * | 1435 LTP-3 |* * * * * *| LTP-2 1436 o--- -----o 1437 | \ / | 1438 | \ / | 1439 | \ CP01 CP02/ | 1440 | +----o--------------------------o------+ | 1441 | | | | 1442 | | Network Service 1 | | 1443 | +--------------------------------------+ | 1444 +------------------------------------------+ 1446 The configuration instance data for Node-1 in the above figure could 1447 be as follows: 1449 { 1450 "networks": { 1451 "network": [ 1452 { 1453 "network-types": { 1454 "te-topology": { 1455 "sf": {} 1456 } 1457 }, 1458 "network-id": "network-sf-aware", 1459 "provider-id": 201, 1460 "client-id": 300, 1461 "te-topology-id": "te-topology:network-sf-aware", 1462 "node": [ 1463 { 1464 "node-id": "Node-1", 1465 "te-node-id": "2.0.1.1", 1466 "te": { 1467 "te-node-attributes": { 1468 "domain-id": 1, 1469 "is-abstract": [null], 1470 "connectivity-matrices": { 1471 }, 1472 "service-function": { 1473 "connectivity-matrices": { 1474 }, 1475 "link-terminations": { 1476 "link-termination": [ 1477 { 1478 "id": 2, 1479 "from": { 1480 "tp-ref": "LTP-2" 1481 }, 1482 "to": { 1483 "service-function-id": "Network Service 1", 1484 "sf-connection-point-id": "CP02" 1485 } 1486 "direction": "bidir" 1487 }, 1488 { 1489 "id": 3, 1490 "from": { 1491 "tp-ref": "LTP-3" 1492 }, 1493 "to": { 1494 "service-function-id": "Network Service 1", 1495 "sf-connection-point-id": "CP01" 1496 } 1497 "direction": "bidir" 1498 } 1499 ] 1500 } 1501 } 1502 } 1503 "tunnel-termination-point": [ 1504 { 1505 "tunnel-tp-id": 10001, 1506 "name": "TTP-1", 1507 "service-function-terminations": { 1508 } 1509 }, 1510 { 1511 "tunnel-tp-id": 10002, 1512 "name": "TTP-2", 1513 "service-function-terminations": { 1514 } 1515 } 1516 ] 1517 }, 1518 "termination-point": [ 1519 { 1520 "tp-id": "LTP-1", 1521 "te-tp-id": 10001 1522 "te": { 1523 "interface-switching-capability": [ 1524 { 1525 "switching-capability": "switching-l2sc", 1526 "encoding": "lsp-encoding-ethernet" 1527 } 1528 ] 1529 } 1530 }, 1531 { 1532 "tp-id": "LTP-2", 1533 "te-tp-id": 10002 1534 "te": { 1535 "interface-switching-capability": [ 1536 { 1537 "switching-capability": "switching-l2sc", 1538 "encoding": "lsp-encoding-ethernet" 1539 } 1540 ] 1541 } 1542 }, 1543 { 1544 "tp-id": "LTP-3", 1545 "te-tp-id": 10003 1546 "te": { 1547 "interface-switching-capability": [ 1548 { 1549 "switching-capability": "switching-l2sc", 1550 "encoding": "lsp-encoding-ethernet" 1551 } 1552 ] 1553 } 1554 }, 1555 { 1556 "tp-id": "LTP-4", 1557 "te-tp-id": 10004 1558 "te": { 1559 "interface-switching-capability": [ 1560 { 1561 "switching-capability": "switching-l2sc", 1562 "encoding": "lsp-encoding-ethernet" 1563 } 1564 ] 1565 } 1566 } 1567 ] 1568 } 1569 ] 1570 } 1572 ] 1573 } 1574 } 1576 Authors' Addresses 1578 Igor Bryskin 1579 Huawei Technologies 1581 EMail: Igor.Bryskin@huawei.com 1583 Xufeng Liu 1584 Volta Networks 1586 EMail: xufeng.liu.ietf@gmail.com 1588 Young Lee 1589 Huawei Technologies 1591 EMail: leeyoung@huawei.com