idnits 2.17.1 draft-liu-teas-transport-network-slice-yang-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.nsdt-teas-transport-slice-definition]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 12, 2020) is 1383 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.nsdt-teas-ns-framework' is defined on line 872, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'GSMA-NS-Template' == Outdated reference: A later version (-04) exists of draft-nsdt-teas-transport-slice-definition-02 ** Downref: Normative reference to an Informational draft: draft-nsdt-teas-transport-slice-definition (ref. 'I-D.nsdt-teas-transport-slice-definition') == Outdated reference: A later version (-18) exists of draft-ietf-ccamp-otn-topo-yang-10 == Outdated reference: A later version (-18) exists of draft-ietf-i2rs-yang-l2-network-topology-14 == Outdated reference: A later version (-11) exists of draft-ietf-teas-actn-yang-05 == Outdated reference: A later version (-05) exists of draft-nsdt-teas-ns-framework-03 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Liu 3 Internet-Draft Volta Networks 4 Intended status: Standards Track J. Tantsura 5 Expires: January 13, 2021 Apstra Networks 6 I. Bryskin 7 Individual 8 L. Contreras 9 Telefonica 10 Q. Wu 11 Huawei 12 S. Belotti 13 R. Rokui 14 Nokia 15 July 12, 2020 17 Transport Network Slice YANG Data Model 18 draft-liu-teas-transport-network-slice-yang-01 20 Abstract 22 This document describes a YANG data model for managing and 23 controlling transport network slices, defined as transport slices in 24 [I-D.nsdt-teas-transport-slice-definition]. 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 January 13, 2021. 43 Copyright Notice 45 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Modeling Considerations . . . . . . . . . . . . . . . . . . . 3 64 2.1. Relationships to Related Topology Models . . . . . . . . 3 65 2.2. Network Slice with TE . . . . . . . . . . . . . . . . . . 4 66 2.3. ACTN for Network Slicing . . . . . . . . . . . . . . . . 5 67 3. Model Applicability . . . . . . . . . . . . . . . . . . . . . 5 68 3.1. Network Slicing by Virtualization . . . . . . . . . . . . 5 69 3.2. Network Slicing by TE Overlay . . . . . . . . . . . . . . 8 70 4. Model Tree Structure . . . . . . . . . . . . . . . . . . . . 10 71 5. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 77 9.2. Informative References . . . . . . . . . . . . . . . . . 20 78 Appendix A. Data Tree for the Example in Section 3.1. . . . . . 22 79 A.1. Native Topology . . . . . . . . . . . . . . . . . . . . . 22 80 A.2. Network Slice Blue . . . . . . . . . . . . . . . . . . . 26 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 83 1. Introduction 85 This document defines a YANG [RFC7950] data model for for 86 representing, managing, and controlling transport network slices, 87 defined as transport slices in 88 [I-D.nsdt-teas-transport-slice-definition] 90 The defined data model is an interface between clients and providers 91 for configurations and state retrievals, so as to support transport 92 network slicing as a service. Through this model, a client can learn 93 the slicing capabilities and the available resources of the provider. 94 A client can request or negotiate with a transport network slicing 95 provider to create an instance. The client can incrementally update 96 its requirements on individual topology elements in the slice 97 instance, and retrieve the operational states of these elements. 98 With the help of other mechanisms and data models defined in IETF, 99 the telemetry information can be published to the client. 101 The YANG data model in this document conforms to the Network 102 Management Datastore Architecture (NMDA) [RFC8342]. 104 1.1. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 108 "OPTIONAL" in this document are to be interpreted as described in BCP 109 14, [RFC2119] [RFC8174] when, and only when, they appear in all 110 capitals, as shown here. 112 The following terms are defined in [RFC7950] and are not redefined 113 here: 115 o augment 117 o data model 119 o data node 121 1.2. Tree Diagrams 123 Tree diagrams used in this document follow the notation defined in 124 [RFC8340]. 126 2. Modeling Considerations 128 A transport slice is modeled as network topology defined in 129 [RFC8345], with augmentations. A new network type "network-slice" is 130 defined in this document. When a network topology data instance 131 contains the network-slice network type, it represents an instance of 132 a transport slice. 134 2.1. Relationships to Related Topology Models 136 There are several related YANG data models that have been defined in 137 IETF. Some of these are: 139 Network Topology Model: 140 Defined in [RFC8345]. 142 OTN Topology Model: 143 Defined in [I-D.ietf-ccamp-otn-topo-yang]. 145 L2 Topology Model: 146 Defined in [I-D.ietf-i2rs-yang-l2-network-topology]. 148 L3 Topology Model: 149 Defined in [RFC8346]. 151 TE Topology Model: 152 Defined in [I-D.ietf-teas-yang-te-topo]. 154 Figure 1 shows the relationships among these models. The box of 155 dotted lines denotes the model defined in this document. 157 +------------------------+ 158 | | 159 | Network Topology Model | 160 | RFC 8345 | 161 +------------------------+ 162 | 163 +-------------+-------------+-------------+-------------+ 164 | | | | | 165 V V V V V 166 +----------+ +----------+ +----------+ +----------+ ............ 167 | OTN | | L2 | | L3 | | TE | : Network : 168 | Topology | | Topology | | Topology | | Topology | : Slice : 169 | Model | | Model | | Model | | Model | : Model : 170 +----------+ +----------+ +----------+ +----------+ '''''''''''' 172 Figure 1: Model Relationships 174 2.2. Network Slice with TE 176 In many situations, a transport network slide needs to have TE 177 (Traffic Engineering) capabilities to achieve certain network 178 characteristics. The TE Topology Model defined in 179 [I-D.ietf-teas-yang-te-topo] can be used to make a transport slice TE 180 capable. To achieve this, a transport slice instance will be 181 configured to have both "network-slice" and "te-topology" network 182 types, taking advantage of the multiple inheritance capability 183 featured by the network topology model [RFC8345]. The following 184 diagram shows their relations. 186 +--------------------+ +--------------------+ 187 | Network Slice | | TE Topology | 188 | ietf-network-slice | | ietf-te-topology | 189 +--------------------+ +--------------------+ 190 \ / 191 \ / 192 \ / 193 v v 194 +------------------------+ 195 | Network Slice with TE | 196 | | 197 +------------------------+ 199 Figure 2: Network Slice with TE 201 This method can be applied to other types of network topology models 202 too. For example, when a network topology instance is configured to 203 have the types of "network-slice" defined in this document, "te- 204 topology" defined in [I-D.ietf-teas-yang-te-topo], and "l3-unicast- 205 topology" defined in [RFC8346], this network topology instance 206 becomes a transport slice instance that can perform layer 3 traffic 207 engineering. 209 2.3. ACTN for Network Slicing 211 Since ACTN topology data models are based on the network topology 212 model defined in [RFC8345], the augmentations defined in this 213 document are effective augmentations to the ACTN topology data 214 models, resulting in making the ACTN framework [RFC8453] and data 215 models [I-D.ietf-teas-actn-yang] capable of slicing networks with the 216 required network characteristics. 218 3. Model Applicability 220 There are many technologies to achieve transport network slicing. 221 The data model defined in this document can be applied to a wide 222 ranges of cases. This section describes how this data model is 223 applied to a few cases. 225 3.1. Network Slicing by Virtualization 227 In the case shown in Figure 3, node virtualization is used to 228 separate and allocate resources in physical devices. Two virtual 229 routers VR1 and VR2 are created over physical router R1. Each of the 230 virtual routers takes a portion of the resources such as ports and 231 memory in the physical router. Depending on the requirements and the 232 implementations, they may share certain resources such as processors, 233 ASICs, and switch fabric. 235 As an example, Appendix A. shows the JSON encoded data instances of 236 the native topology and the customized topology for Network Slice 237 Blue. 239 Client Topology Client Topology 240 Network Slice Blue Network Slice Red 241 +---+ +---+ +---+ 242 -----|R3 |--- ---|R2 |------|R3 | 243 / +---+ +---+ +---+ 244 +---+ +---+ \ +---+ 245 ---|R1 |------|R2 | -----|R4 |--- 246 +---+ +---+ +---+ 248 Clients 249 --------------------------------------------------------------------- 250 Provider 252 Customized Topology 253 Provider Network with Virtual Devices 255 Network Slice Blue: VR1, VR3, VR5 +---+ 256 ----------|VR5|------ 257 / +---+ 258 +---+ +---+ 259 ------|VR1|---------|VR3| 260 +---+ +---+ 261 ------|VR2|---------|VR4| 262 +---+ +---+ 263 \ +---+ 264 ----------|VR6|------ 265 Network Slice Red: VR2, VR4, VR6 +---+ 267 Virtual Devices 268 --------------------------------------------------------------------- 269 Physical Devices 271 Native Topology 272 Provider Network with Physical Devices 273 +---+ 274 ----------|R3 |------ 275 / +---+ 276 +---+ +---+ 277 ======|R1 |=========|R2 | 278 +---+ +---+ 279 \ +---+ 280 ----------|R4 |------ 281 +---+ 283 Figure 3: Network Slicing by Virtualization 285 3.2. Network Slicing by TE Overlay 287 Figure 5 shows a case where TE (Traffic Engineering) overlay is 288 applied to achieve logically separated client transport network 289 slices. In the underlay TE capable network, TE tunnels are 290 established to support the TE links in the overlay network. These 291 links and tunnels maintain the characteristics required by the 292 clients. The provider selects the proper logical nodes and links in 293 the overlay network, assigns them to specific transport network 294 slices, and uses the data model defined in this document to send the 295 results to the clients. 297 Client Topology Client Topology 298 Network Slice Blue Network Slice Red 299 +---+ +---+ +---+ 300 -----|R3 |--- ---|R2 |------|R3 | 301 / +---+ +---+ +---+ 302 +---+ +---+ \ +---+ 303 ---|R1 |------|R2 | -----|R4 |--- 304 +---+ +---+ +---+ 306 Clients 307 --------------------------------------------------------------------- 308 Provider 310 Customized Topology 311 Provider Network with TE Isolation 313 Network Slice Blue: R1, R2, R3 314 +---+ 315 ----------|R3 |------ 316 / +---+ 317 +---+ +---+ 318 ======|R1 |=========|R2 | 319 +---+ +---+ 320 \ +---+ 321 ----------|R4 |------ 322 +---+ 323 Network Slice Red: R1, R2, R4 325 Overlay 326 --------------------------------------------------------------------- 327 Underlay 329 Native Topology 330 Provider Network with TE Tunnels 331 +---+ 332 TE Tunnel for Network Slice Blue ----------|R3 |------ 333 @@@@@@@@@@@@@@ / +---+ 334 +---+ +---+ +---+ 335 ======|R1 |--|R5 |--|R2 | 336 +---+ +---+ +---+ 337 ############## \ +---+ 338 TE Tunnel for Network Slice Red ----------|R4 |------ 339 +---+ 341 Figure 4: Network Slicing by TE Overlay 343 4. Model Tree Structure 345 module: ietf-network-slice 346 augment /nw:networks/nw:network/nw:network-types: 347 +--rw network-slice! 348 augment /nw:networks/nw:network: 349 +--rw network-slice 350 +--rw optimization-criterion? identityref 351 +--rw delay-tolerance? boolean 352 +--rw periodicity* uint64 353 +--rw isolation-level? identityref 354 augment /nw:networks/nw:network/nw:node: 355 +--rw network-slice 356 +--rw isolation-level? identityref 357 +--rw compute-node-id? string 358 +--rw storage-id? string 359 augment /nw:networks/nw:network/nt:link: 360 +--rw network-slice 361 +--rw delay-tolerance? boolean 362 +--rw periodicity* uint64 363 +--rw isolation-level? identityref 365 5. YANG Module 367 This module references [RFC8345], [RFC8776], and [GSMA-NS-Template] 369 file "ietf-network-slice@2020-07-12.yang" 370 module ietf-network-slice { 371 yang-version 1.1; 372 namespace "urn:ietf:params:xml:ns:yang:ietf-network-slice"; 373 prefix "ns"; 375 import ietf-network { 376 prefix "nw"; 377 reference "RFC 8345: A YANG Data Model for Network Topologies"; 378 } 379 import ietf-network-topology { 380 prefix "nt"; 381 reference "RFC 8345: A YANG Data Model for Network Topologies"; 382 } 383 import ietf-te-types { 384 prefix "te-types"; 385 reference 386 "RFC 8776: Traffic Engineering Common YANG Types"; 387 } 389 organization 390 "IETF Traffic Engineering Architecture and Signaling (TEAS) 391 Working Group"; 393 contact 394 "WG Web: 395 WG List: 397 Editor: Xufeng Liu 398 400 Editor: Jeff Tantsura 401 403 Editor: Igor Bryskin 404 406 Editor: Luis Miguel Contreras Murillo 407 409 Editor: Qin Wu 410 412 Editor: Sergio Belotti 413 415 Editor: Reza Rokui 416 417 "; 419 description 420 "YANG data model for representing and managing network 421 slices. 423 Copyright (c) 2019 IETF Trust and the persons identified as 424 authors of the code. All rights reserved. 426 Redistribution and use in source and binary forms, with or 427 without modification, is permitted pursuant to, and subject to 428 the license terms contained in, the Simplified BSD License set 429 forth in Section 4.c of the IETF Trust's Legal Provisions 430 Relating to IETF Documents 431 (http://trustee.ietf.org/license-info). 433 This version of this YANG module is part of RFC XXXX; see the 434 RFC itself for full legal notices."; 436 revision 2020-07-12 { 437 description "Initial revision"; 438 reference 439 "RFC XXXX: YANG Data Model for Network Slices"; 440 } 442 /* 443 * Identities 444 */ 445 identity isolation-level { 446 description 447 "Base identity for the isolation-level."; 448 reference 449 "GSMA-NS-Template: Generic Network Slice Template, 450 Version 1.0."; 451 } 452 identity no-isolation { 453 base isolation-level; 454 description 455 "Network slices are not separated."; 456 } 457 identity physical-isolation { 458 base isolation-level; 459 description 460 "Network slices are physically separated (e.g. different rack, 461 different hardware, different location, etc.)."; 462 } 463 identity logical-isolation { 464 base isolation-level; 465 description 466 "Network slices are logically separated."; 467 } 468 identity process-isolation { 469 base physical-isolation; 470 description 471 "Process and threads isolation."; 472 } 473 identity physical-memory-isolation { 474 base physical-isolation; 475 description 476 "Process and threads isolation."; 477 } 478 identity physical-network-isolation { 479 base physical-isolation; 480 description 481 "Process and threads isolation."; 483 } 484 identity virtual-resource-isolation { 485 base logical-isolation; 486 description 487 "A network slice has access to specific range of resources 488 that do not overlap with other network slices 489 (e.g. VM isolation)."; 490 } 491 identity network-functions-isolation { 492 base logical-isolation; 493 description 494 "NF (Network Function) is dedicated to the network slice, but 495 virtual resources are shared."; 496 } 497 identity service-isolation { 498 base logical-isolation; 499 description 500 "NSC data are isolated from other NSCs, but virtual 501 resources and NFs are shared."; 502 } 504 /* 505 * Groupiings 506 */ 507 grouping network-slice-topology-attributes { 508 description "Network Slice topology scope attributes."; 509 container network-slice { 510 description 511 "Containing Network Slice attributes."; 512 leaf optimization-criterion { 513 type identityref { 514 base te-types:objective-function-type; 515 } 516 description 517 "Optimization criterion applied to this topology."; 518 } 519 leaf delay-tolerance { 520 type boolean; 521 description 522 "'true' if is not too critical how long it takes to deliver 523 the amount of data."; 524 reference 525 "GSMA-NS-Template: Generic Network Slice Template, 526 Version 1.0."; 527 } 528 leaf-list periodicity { 529 type uint64; 530 units seconds; 531 description 532 "A list of periodicities supported by the network slice."; 533 reference 534 "GSMA-NS-Template: Generic Network Slice Template, 535 Version 1.0."; 536 } 537 leaf isolation-level { 538 type identityref { 539 base isolation-level; 540 } 541 description 542 "A network slice instance may be fully or partly, logically 543 and/or physically, isolated from another network slice 544 instance. This attribute describes different types of 545 isolation:"; 546 } 547 } // network-slice 548 } // network-slice-topology-attributes 550 grouping network-slice-node-attributes { 551 description "Network Slice node scope attributes."; 552 container network-slice { 553 description 554 "Containing Network Slice attributes."; 555 leaf isolation-level { 556 type identityref { 557 base isolation-level; 558 } 559 description 560 "A network slice instance may be fully or partly, logically 561 and/or physically, isolated from another network slice 562 instance. This attribute describes different types of 563 isolation:"; 564 } 565 leaf compute-node-id { 566 type string; 567 description 568 "Reference to a compute node instance specified in 569 a data model specifying the computing resources."; 570 } 571 leaf storage-id { 572 type string; 573 description 574 "Reference to a storage instance specified in 575 a data model specifying the storage resources."; 576 } 577 } // network-slice 578 } // network-slice-node-attributes 579 grouping network-slice-link-attributes { 580 description "Network Slice link scope attributes"; 581 container network-slice { 582 description 583 "Containing Network Slice attributes."; 584 leaf delay-tolerance { 585 type boolean; 586 description 587 "'true' if is not too critical how long it takes to deliver 588 the amount of data."; 589 reference 590 "GSMA-NS-Template: Generic Network Slice Template, 591 Version 1.0."; 592 } 593 leaf-list periodicity { 594 type uint64; 595 units seconds; 596 description 597 "A list of periodicities supported by the network slice."; 598 reference 599 "GSMA-NS-Template: Generic Network Slice Template, 600 Version 1.0."; 601 } 602 leaf isolation-level { 603 type identityref { 604 base isolation-level; 605 } 606 description 607 "A network slice instance may be fully or partly, logically 608 and/or physically, isolated from another network slice 609 instance. This attribute describes different types of 610 isolation:"; 611 } 612 } // network-slice 613 } // network-slice-link-attributes 615 /* 616 * Data nodes 617 */ 618 augment "/nw:networks/nw:network/nw:network-types" { 619 description 620 "Defines the Network Slice topology type."; 621 container network-slice { 622 presence "Indicates Network Slice topology"; 623 description 624 "Its presence identifies the Network Slice type."; 625 } 626 } 627 augment "/nw:networks/nw:network" { 628 when "nw:network-types/ns:network-slice" { 629 description "Augment only for Network Slice topology."; 630 } 631 description "Augment topology configuration and state."; 632 uses network-slice-topology-attributes; 633 } 635 augment "/nw:networks/nw:network/nw:node" { 636 when "../nw:network-types/ns:network-slice" { 637 description "Augment only for Network Slice topology."; 638 } 639 description "Augment node configuration and state."; 640 uses network-slice-node-attributes; 641 } 643 augment "/nw:networks/nw:network/nt:link" { 644 when "../nw:network-types/ns:network-slice" { 645 description "Augment only for Network Slice topology."; 646 } 647 description "Augment link configuration and state."; 648 uses network-slice-link-attributes; 649 } 651 } 652 654 6. IANA Considerations 656 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 657 actual RFC number (and remove this note). 659 This document registers the following namespace URIs in the IETF XML 660 registry [RFC3688]: 662 -------------------------------------------------------------------- 663 URI: urn:ietf:params:xml:ns:yang:ietf-network-slice 664 Registrant Contact: The IESG. 665 XML: N/A, the requested URI is an XML namespace. 666 -------------------------------------------------------------------- 668 This document registers the following YANG modules in the YANG Module 669 Names registry [RFC6020]: 671 -------------------------------------------------------------------- 672 name: ietf-l3-te-topology 673 namespace: urn:ietf:params:xml:ns:yang:ietf-network-slice 674 prefix: ns 675 reference: RFC XXXX 676 -------------------------------------------------------------------- 678 7. Security Considerations 680 The YANG module specified in this document defines a schema for data 681 that is designed to be accessed via network management protocols such 682 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 683 is the secure transport layer, and the mandatory-to-implement secure 684 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 685 is HTTPS, and the mandatory-to-implement secure transport is TLS 686 [RFC8446]. 688 The Network Configuration Access Control Model (NACM) [RFC8341] 689 provides the means to restrict access for particular NETCONF or 690 RESTCONF users to a preconfigured subset of all available NETCONF or 691 RESTCONF protocol operations and content. 693 There are a number of data nodes defined in this YANG module that are 694 writable/creatable/deletable (i.e., config true, which is the 695 default). These data nodes may be considered sensitive or vulnerable 696 in some network environments. Write operations (e.g., edit-config) 697 to these data nodes without proper protection can have a negative 698 effect on network operations. These are the subtrees and data nodes 699 and their sensitivity/vulnerability: 701 /nw:networks/nw:network/nw:network-types/ns:network-slice 702 This subtree specifies the network slice type. Modifying the 703 configurations can make network slice type invalid and cause 704 interruption to transport network slices. 706 /nw:networks/nw:network/ns:network-slice 707 This subtree specifies the topology-wide configurations. 708 Modifying the configurations here can cause traffic 709 characteristics changed in this transport network slice and 710 related networks. 712 /nw:networks/nw:network/nw:node/ns:network-slice 713 This subtree specifies the configurations of the nodes in a 714 transport network slice. Modifying the configurations in this 715 subtree can change the traffic characteristics on this node and 716 the related networks. 718 /nw:networks/nw:network/nt:link/ns:network-slice 719 This subtree specifies the configurations of the links in a 720 transport network slice. Modifying the configurations in this 721 subtree can change the traffic characteristics on this link and 722 the related networks. 724 Some of the readable data nodes in this YANG module may be considered 725 sensitive or vulnerable in some network environments. It is thus 726 important to control read access (e.g., via get, get-config, or 727 notification) to these data nodes. These are the subtrees and data 728 nodes and their sensitivity/vulnerability: 730 /nw:networks/nw:network/nw:network-types/ns:network-slice 731 Unauthorized access to this subtree can disclose the network slice 732 type. 734 /nw:networks/nw:network/ns:network-slice 735 Unauthorized access to this subtree can disclose the topology-wide 736 states. 738 /nw:networks/nw:network/nw:node/ns:network-slice 739 Unauthorized access to this subtree can disclose the operational 740 state information of the nodes in a transport network slice. 742 /nw:networks/nw:network/nt:link/ns:network-slic 743 Unauthorized access to this subtree can disclose the operational 744 state information of the links in a transport network slice. 746 8. Acknowledgements 748 The TEAS Network Slicing Design Team (NSDT) members included Aijun 749 Wang, Dong Jie, Eric Gray, Jari Arkko, Jeff Tantsura, John E Drake, 750 Luis M. Contreras, Rakesh Gandhi, Ran Chen, Reza Rokui, Ricard 751 Vilalta, Ron Bonica, Sergio Belotti, Tomonobu Niwa, Xuesong Geng, and 752 Xufeng Liu. 754 9. References 756 9.1. Normative References 758 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 759 Requirement Levels", BCP 14, RFC 2119, 760 DOI 10.17487/RFC2119, March 1997, 761 . 763 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 764 DOI 10.17487/RFC3688, January 2004, 765 . 767 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 768 the Network Configuration Protocol (NETCONF)", RFC 6020, 769 DOI 10.17487/RFC6020, October 2010, 770 . 772 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 773 and A. Bierman, Ed., "Network Configuration Protocol 774 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 775 . 777 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 778 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 779 . 781 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 782 RFC 7950, DOI 10.17487/RFC7950, August 2016, 783 . 785 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 786 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 787 . 789 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 790 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 791 May 2017, . 793 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 794 Access Control Model", STD 91, RFC 8341, 795 DOI 10.17487/RFC8341, March 2018, 796 . 798 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 799 and R. Wilton, "Network Management Datastore Architecture 800 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 801 . 803 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 804 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 805 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 806 2018, . 808 [RFC8346] Clemm, A., Medved, J., Varga, R., Liu, X., 809 Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model 810 for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346, 811 March 2018, . 813 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 814 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 815 . 817 [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 818 "Common YANG Data Types for Traffic Engineering", 819 RFC 8776, DOI 10.17487/RFC8776, June 2020, 820 . 822 [I-D.ietf-teas-yang-te-topo] 823 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 824 O. Dios, "YANG Data Model for Traffic Engineering (TE) 825 Topologies", draft-ietf-teas-yang-te-topo-22 (work in 826 progress), June 2019. 828 [GSMA-NS-Template] 829 GSM Association, "Generic Network Slice Template, Version 830 1.0", NG.116, May 2019. 832 [I-D.nsdt-teas-transport-slice-definition] 833 Rokui, R., Homma, S., Makhijani, K., and L. Contreras, 834 "IETF Definition of Transport Slice", draft-nsdt-teas- 835 transport-slice-definition-02 (work in progress), April 836 2020. 838 9.2. Informative References 840 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 841 RFC 7951, DOI 10.17487/RFC7951, August 2016, 842 . 844 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 845 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 846 . 848 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 849 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 850 DOI 10.17487/RFC8453, August 2018, 851 . 853 [I-D.ietf-ccamp-otn-topo-yang] 854 Zheng, H., Busi, I., Liu, X., Belotti, S., and O. Dios, "A 855 YANG Data Model for Optical Transport Network Topology", 856 draft-ietf-ccamp-otn-topo-yang-10 (work in progress), 857 March 2020. 859 [I-D.ietf-i2rs-yang-l2-network-topology] 860 Dong, J., Wei, X., WU, Q., Boucadair, M., and A. Liu, "A 861 YANG Data Model for Layer 2 Network Topologies", draft- 862 ietf-i2rs-yang-l2-network-topology-14 (work in progress), 863 June 2020. 865 [I-D.ietf-teas-actn-yang] 866 Lee, Y., Zheng, H., Ceccarelli, D., Yoon, B., Dios, O., 867 Shin, J., and S. Belotti, "Applicability of YANG models 868 for Abstraction and Control of Traffic Engineered 869 Networks", draft-ietf-teas-actn-yang-05 (work in 870 progress), February 2020. 872 [I-D.nsdt-teas-ns-framework] 873 Gray, E. and J. Drake, "Framework for Transport Network 874 Slices", draft-nsdt-teas-ns-framework-03 (work in 875 progress), April 2020. 877 Appendix A. Data Tree for the Example in Section 3.1. 879 A.1. Native Topology 881 This section contains an example of an instance data tree in the JSON 882 encoding [RFC7951]. The example instantiates "ietf-network" for the 883 native topology depicted in Figure 3. 885 { 886 "ietf-network:networks": { 887 "network": [ 888 { 889 "network-id":"example-native-topology", 890 "network-types": { 891 }, 892 "node": [ 893 { 894 "node-id":"R1", 895 "ietf-network-topology:termination-point": [ 896 { 897 "tp-id":"1-0-1" 898 }, 899 { 900 "tp-id":"1-0-2" 901 }, 902 { 903 "tp-id":"1-2-1" 904 }, 905 { 906 "tp-id":"1-2-2" 907 } 908 ] 909 }, 910 { 911 "node-id":"R2", 912 "ietf-network-topology:termination-point": [ 913 { 914 "tp-id":"2-1-1" 915 }, 916 { 917 "tp-id":"2-1-2" 918 }, 919 { 920 "tp-id":"2-3-1" 921 }, 922 { 923 "tp-id":"2-4-1" 924 } 926 ] 927 }, 928 { 929 "node-id":"R3", 930 "ietf-network-topology:termination-point": [ 931 { 932 "tp-id":"3-0-1" 933 }, 934 { 935 "tp-id":"3-2-1" 936 } 937 ] 938 }, 939 { 940 "node-id":"R4", 941 "ietf-network-topology:termination-point": [ 942 { 943 "tp-id":"4-0-1" 944 }, 945 { 946 "tp-id":"4-2-1" 947 } 948 ] 949 } 950 ], 951 "ietf-network-topology:link": [ 952 { 953 "link-id":"R1,1-0-1,,", 954 "source": { 955 "source-node":"R1", 956 "source-tp":"1-0-1" 957 } 958 }, 959 { 960 "link-id":",,R1,1-0-1", 961 "destination": { 962 "dest-node":"R1", 963 "dest-tp":"1-0-1" 964 } 965 }, 966 { 967 "link-id":"R1,1-0-2,,", 968 "source": { 969 "source-node":"R1", 970 "source-tp":"1-0-2" 971 } 972 }, 973 { 974 "link-id":",,R1,1-0-2", 975 "destination": { 976 "dest-node":"R1", 977 "dest-tp":"1-0-2" 978 } 979 }, 980 { 981 "link-id":"R1,1-2-1,R2,2-1-1", 982 "source": { 983 "source-node":"R1", 984 "source-tp":"1-2-1" 985 }, 986 "destination": { 987 "dest-node":"R2", 988 "dest-tp":"2-1-1" 989 } 990 }, 991 { 992 "link-id":"R2,2-1-1,R1,1-2-1", 993 "source": { 994 "source-node":"R2", 995 "source-tp":"2-1-1" 996 }, 997 "destination": { 998 "dest-node":"R1", 999 "dest-tp":"1-2-1" 1000 } 1001 }, 1002 { 1003 "link-id":"R1,1-2-2,R2,2-1-2", 1004 "source": { 1005 "source-node":"R1", 1006 "source-tp":"1-2-2" 1007 }, 1008 "destination": { 1009 "dest-node":"R2", 1010 "dest-tp":"2-1-2" 1011 } 1012 }, 1013 { 1014 "link-id":"R2,2-1-2,R1,1-2-2", 1015 "source": { 1016 "source-node":"R2", 1017 "source-tp":"2-1-2" 1018 }, 1019 "destination": { 1020 "dest-node":"R1", 1021 "dest-tp":"1-2-2" 1023 } 1024 }, 1025 { 1026 "link-id":"R2,2-3-1,R3,3-2-1", 1027 "source": { 1028 "source-node":"R2", 1029 "source-tp":"2-3-1" 1030 }, 1031 "destination": { 1032 "dest-node":"R3", 1033 "dest-tp":"3-2-1" 1034 } 1035 }, 1036 { 1037 "link-id":"R3,3-2-1,R2,2-3-1", 1038 "source": { 1039 "source-node":"R3", 1040 "source-tp":"3-2-1" 1041 }, 1042 "destination": { 1043 "dest-node":"R2", 1044 "dest-tp":"2-3-1" 1045 } 1046 }, 1047 { 1048 "link-id":"R2,2-4-1,R4,4-2-1", 1049 "source": { 1050 "source-node":"R2", 1051 "source-tp":"2-4-1" 1052 }, 1053 "destination": { 1054 "dest-node":"R4", 1055 "dest-tp":"4-2-1" 1056 } 1057 }, 1058 { 1059 "link-id":"R4,4-2-1,R2,2-4-1", 1060 "source": { 1061 "source-node":"R4", 1062 "source-tp":"4-2-1" 1063 }, 1064 "destination": { 1065 "dest-node":"R2", 1066 "dest-tp":"2-4-1" 1067 } 1068 }, 1069 { 1070 "link-id":"R3,3-0-1,,", 1071 "source": { 1072 "source-node":"R3", 1073 "source-tp":"3-0-1" 1074 } 1075 }, 1076 { 1077 "link-id":",,R3,3-0-1", 1078 "destination": { 1079 "dest-node":"R3", 1080 "dest-tp":"3-0-1" 1081 } 1082 }, 1083 { 1084 "link-id":"R4,4-0-1,,", 1085 "source": { 1086 "source-node":"R4", 1087 "source-tp":"4-0-1" 1088 } 1089 }, 1090 { 1091 "link-id":",,R4,4-0-1", 1092 "destination": { 1093 "dest-node":"R4", 1094 "dest-tp":"4-0-1" 1095 } 1096 } 1097 ] 1098 } 1099 ] 1100 } 1101 } 1103 A.2. Network Slice Blue 1105 This section contains an example of an instance data tree in the JSON 1106 encoding [RFC7951]. The example instantiates "ietf-network-slice" 1107 for the topology customized for Network Slice Blue depicted in 1108 Figure 3. 1110 { 1111 "ietf-network:networks": { 1112 "network": [ 1113 { 1114 "network-id":"example-customized-blue-topology", 1115 "network-types": { 1116 "ietf-network-slice:network-slice": { 1117 } 1118 }, 1119 "supporting-network": [ 1120 { 1121 "network-ref":"example-native-topology" 1122 } 1123 ], 1124 "node": [ 1125 { 1126 "node-id":"VR1", 1127 "supporting-node": [ 1128 { 1129 "network-ref":"example-native-topology", 1130 "node-ref":"R1" 1131 } 1132 ], 1133 "ietf-network-slice:network-slice": { 1134 "isolation-level": 1135 "ietf-network-slice:physical-memory-isolation" 1136 }, 1137 "ietf-network-topology:termination-point": [ 1138 { 1139 "tp-id":"1-0-1" 1140 }, 1141 { 1142 "tp-id":"1-3-1" 1143 } 1144 ] 1145 }, 1146 { 1147 "node-id":"VR3", 1148 "supporting-node": [ 1149 { 1150 "network-ref":"example-native-topology", 1151 "node-ref":"R2" 1152 } 1153 ], 1154 "ietf-network-slice:network-slice": { 1155 "isolation-level": 1156 "ietf-network-slice:physical-memory-isolation" 1157 }, 1158 "ietf-network-topology:termination-point": [ 1159 { 1160 "tp-id":"3-1-1" 1161 }, 1162 { 1163 "tp-id":"3-5-1" 1164 } 1166 ] 1167 }, 1168 { 1169 "node-id":"VR5", 1170 "supporting-node": [ 1171 { 1172 "network-ref":"example-native-topology", 1173 "node-ref":"R3" 1174 } 1175 ], 1176 "ietf-network-slice:network-slice": { 1177 "isolation-level": 1178 "ietf-network-slice:physical-memory-isolation" 1179 }, 1180 "ietf-network-topology:termination-point": [ 1181 { 1182 "tp-id":"5-3-1" 1183 }, 1184 { 1185 "tp-id":"5-0-1" 1186 } 1187 ] 1188 } 1189 ], 1190 "ietf-network-topology:link": [ 1191 { 1192 "link-id":"VR1,1-0-1,,", 1193 "source": { 1194 "source-node":"VR1", 1195 "source-tp":"1-0-1" 1196 }, 1197 "supporting-link": [ 1198 { 1199 "network-ref":"example-native-topology", 1200 "link-ref":"R1,1-0-1,," 1201 } 1202 ], 1203 "ietf-network-slice:network-slice": { 1204 "isolation-level": 1205 "ietf-network-slice:physical-network-isolation" 1206 } 1207 }, 1208 { 1209 "link-id":",,VR1,1-0-1", 1210 "destination": { 1211 "dest-node":"VR1", 1212 "dest-tp":"1-0-1" 1213 }, 1214 "supporting-link": [ 1215 { 1216 "network-ref":"example-native-topology", 1217 "link-ref":",,R1,1-0-1" 1218 } 1219 ], 1220 "ietf-network-slice:network-slice": { 1221 "isolation-level": 1222 "ietf-network-slice:physical-network-isolation" 1223 } 1224 }, 1225 { 1226 "link-id":"VR1,1-3-1,VR3,3-1-1", 1227 "source": { 1228 "source-node":"VR1", 1229 "source-tp":"1-3-1" 1230 }, 1231 "destination": { 1232 "dest-node":"VR3", 1233 "dest-tp":"3-1-1" 1234 }, 1235 "supporting-link": [ 1236 { 1237 "network-ref":"example-native-topology", 1238 "link-ref":"R1,1-2-1,R2,2-1-1" 1239 } 1240 ], 1241 "ietf-network-slice:network-slice": { 1242 "isolation-level": 1243 "ietf-network-slice:physical-network-isolation" 1244 } 1245 }, 1246 { 1247 "link-id":"VR3,3-1-1,VR1,1-3-1", 1248 "source": { 1249 "source-node":"VR3", 1250 "source-tp":"3-1-1" 1251 }, 1252 "destination": { 1253 "dest-node":"R1", 1254 "dest-tp":"1-3-1" 1255 }, 1256 "supporting-link": [ 1257 { 1258 "network-ref":"example-native-topology", 1259 "link-ref":"R2,2-1-1,R1,1-2-1" 1260 } 1261 ], 1262 "ietf-network-slice:network-slice": { 1263 "isolation-level": 1264 "ietf-network-slice:physical-network-isolation" 1265 } 1266 }, 1267 { 1268 "link-id":"VR3,3-5-1,VR5,5-3-1", 1269 "source": { 1270 "source-node":"VR3", 1271 "source-tp":"3-5-1" 1272 }, 1273 "destination": { 1274 "dest-node":"VR5", 1275 "dest-tp":"5-3-1" 1276 }, 1277 "supporting-link": [ 1278 { 1279 "network-ref":"example-native-topology", 1280 "link-ref":"R2,2-3-1,R3,3-2-1" 1281 } 1282 ], 1283 "ietf-network-slice:network-slice": { 1284 "isolation-level": 1285 "ietf-network-slice:physical-network-isolation" 1286 } 1287 }, 1288 { 1289 "link-id":"VR5,5-3-1,VR3,3-5-1", 1290 "source": { 1291 "source-node":"VR5", 1292 "source-tp":"5-3-1" 1293 }, 1294 "destination": { 1295 "dest-node":"VR3", 1296 "dest-tp":"3-5-1" 1297 }, 1298 "supporting-link": [ 1299 { 1300 "network-ref":"example-native-topology", 1301 "link-ref":"R3,3-2-1,R2,2-3-1" 1302 } 1303 ], 1304 "ietf-network-slice:network-slice": { 1305 "isolation-level": 1306 "ietf-network-slice:physical-network-isolation" 1307 } 1308 }, 1309 { 1310 "link-id":"VR5,5-0-1,,", 1311 "source": { 1312 "source-node":"VR5", 1313 "source-tp":"5-0-1" 1314 }, 1315 "supporting-link": [ 1316 { 1317 "network-ref":"example-native-topology", 1318 "link-ref":"R3,3-0-1,," 1319 } 1320 ], 1321 "ietf-network-slice:network-slice": { 1322 "isolation-level": 1323 "ietf-network-slice:physical-network-isolation" 1324 } 1325 }, 1326 { 1327 "link-id":",,VR5,5-0-1", 1328 "destination": { 1329 "dest-node":"VR5", 1330 "dest-tp":"5-0-1" 1331 }, 1332 "supporting-link": [ 1333 { 1334 "network-ref":"example-native-topology", 1335 "link-ref":",,R3,3-0-1" 1336 } 1337 ], 1338 "ietf-network-slice:network-slice": { 1339 "isolation-level": 1340 "ietf-network-slice:physical-network-isolation" 1341 } 1342 } 1343 ], 1344 "ietf-network-slice:network-slice": { 1345 "optimization-criterion": 1346 "ietf-te-types:of-minimize-cost-path", 1347 "isolation-level": 1348 "ietf-network-slice:physical-isolation" 1349 } 1350 } 1351 ] 1352 } 1353 } 1355 Authors' Addresses 1357 Xufeng Liu 1358 Volta Networks 1360 EMail: xufeng.liu.ietf@gmail.com 1362 Jeff Tantsura 1363 Apstra Networks 1365 EMail: jefftant.ietf@gmail.com 1367 Igor Bryskin 1368 Individual 1370 EMail: i_bryskin@yahoo.com 1372 Luis Miguel Contreras Murillo 1373 Telefonica 1375 EMail: luismiguel.contrerasmurillo@telefonica.com 1377 Qin Wu 1378 Huawei 1380 EMail: bill.wu@huawei.com 1382 Sergio Belotti 1383 Nokia 1385 EMail: sergio.belotti@nokia.com 1387 Reza Rokui 1388 Nokia 1389 Canada 1391 EMail: reza.rokui@nokia.com