idnits 2.17.1 draft-liu-teas-transport-network-slice-yang-02.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-ietf-network-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 (November 2, 2020) is 1270 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 (-02) exists of draft-nsdt-teas-ietf-network-slice-definition-00 ** Downref: Normative reference to an Informational draft: draft-nsdt-teas-ietf-network-slice-definition (ref. 'I-D.nsdt-teas-ietf-network-slice-definition') == Outdated reference: A later version (-18) exists of draft-ietf-ccamp-otn-topo-yang-11 == Outdated reference: A later version (-11) exists of draft-ietf-teas-actn-yang-06 == Outdated reference: A later version (-05) exists of draft-nsdt-teas-ns-framework-04 Summary: 2 errors (**), 0 flaws (~~), 7 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: May 6, 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 November 2, 2020 17 IETF Network Slice YANG Data Model 18 draft-liu-teas-transport-network-slice-yang-02 20 Abstract 22 This document describes a YANG data model for managing and 23 controlling IETF network slices, defined in 24 [I-D.nsdt-teas-ietf-network-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 May 6, 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 IETF network slices, defined 87 in [I-D.nsdt-teas-ietf-network-slice-definition] 89 The defined data model is an interface between clients and providers 90 for configurations and state retrievals, so as to support network 91 slicing as a service. Through this model, a client can learn the 92 slicing capabilities and the available resources of the provider. A 93 client can request or negotiate with a network slicing provider to 94 create an instance. The client can incrementally update its 95 requirements on individual topology elements in the slice instance, 96 and retrieve the operational states of these elements. With the help 97 of other mechanisms and data models defined in IETF, the telemetry 98 information can be published to the client. 100 The YANG data model in this document conforms to the Network 101 Management Datastore Architecture (NMDA) [RFC8342]. 103 1.1. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 107 "OPTIONAL" in this document are to be interpreted as described in BCP 108 14, [RFC2119] [RFC8174] when, and only when, they appear in all 109 capitals, as shown here. 111 The following terms are defined in [RFC7950] and are not redefined 112 here: 114 o augment 116 o data model 118 o data node 120 1.2. Tree Diagrams 122 Tree diagrams used in this document follow the notation defined in 123 [RFC8340]. 125 2. Modeling Considerations 127 An IETF network slice is modeled as network topology defined in 128 [RFC8345], with augmentations. A new network type "network-slice" is 129 defined in this document. When a network topology data instance 130 contains the network-slice network type, it represents an instance of 131 an IETF network slice. 133 2.1. Relationships to Related Topology Models 135 There are several related YANG data models that have been defined in 136 IETF. Some of these are: 138 Network Topology Model: 139 Defined in [RFC8345]. 141 OTN Topology Model: 142 Defined in [I-D.ietf-ccamp-otn-topo-yang]. 144 L2 Topology Model: 145 Defined in [I-D.ietf-i2rs-yang-l2-network-topology]. 147 L3 Topology Model: 148 Defined in [RFC8346]. 150 TE Topology Model: 151 Defined in [RFC8795]. 153 Figure 1 shows the relationships among these models. The box of 154 dotted lines denotes the model defined in this document. 156 +------------------------+ 157 | | 158 | Network Topology Model | 159 | RFC 8345 | 160 +------------------------+ 161 | 162 +-------------+-------------+-------------+-------------+ 163 | | | | | 164 V V V V V 165 +----------+ +----------+ +----------+ +----------+ ............ 166 | OTN | | L2 | | L3 | | TE | : Network : 167 | Topology | | Topology | | Topology | | Topology | : Slice : 168 | Model | | Model | | Model | | Model | : Model : 169 +----------+ +----------+ +----------+ +----------+ '''''''''''' 171 Figure 1: Model Relationships 173 2.2. Network Slice with TE 175 In many situations, an IETF network slide needs to have TE (Traffic 176 Engineering) capabilities to achieve certain network characteristics. 177 The TE Topology Model defined in [RFC8795] can be used to make an 178 IETF network slice TE capable. To achieve this, an IETF network 179 slice instance will be configured to have both "network-slice" and 180 "te-topology" network types, taking advantage of the multiple 181 inheritance capability featured by the network topology model 182 [RFC8345]. The following diagram shows their relations. 184 +--------------------+ +--------------------+ 185 | Network Slice | | TE Topology | 186 | ietf-network-slice | | ietf-te-topology | 187 +--------------------+ +--------------------+ 188 \ / 189 \ / 190 \ / 191 v v 192 +------------------------+ 193 | Network Slice with TE | 194 | | 195 +------------------------+ 197 Figure 2: Network Slice with TE 199 This method can be applied to other types of network topology models 200 too. For example, when a network topology instance is configured to 201 have the types of "network-slice" defined in this document, "te- 202 topology" defined in [RFC8795], and "l3-unicast-topology" defined in 203 [RFC8346], this network topology instance becomes an IETF network 204 slice instance that can perform layer 3 traffic engineering. 206 2.3. ACTN for Network Slicing 208 Since ACTN topology data models are based on the network topology 209 model defined in [RFC8345], the augmentations defined in this 210 document are effective augmentations to the ACTN topology data 211 models, resulting in making the ACTN framework [RFC8453] and data 212 models [I-D.ietf-teas-actn-yang] capable of slicing networks with the 213 required network characteristics. 215 3. Model Applicability 217 There are many technologies to achieve network slicing. The data 218 model defined in this document can be applied to a wide ranges of 219 cases. This section describes how this data model is applied to a 220 few cases. 222 3.1. Network Slicing by Virtualization 224 In the case shown in Figure 3, node virtualization is used to 225 separate and allocate resources in physical devices. Two virtual 226 routers VR1 and VR2 are created over physical router R1. Each of the 227 virtual routers takes a portion of the resources such as ports and 228 memory in the physical router. Depending on the requirements and the 229 implementations, they may share certain resources such as processors, 230 ASICs, and switch fabric. 232 As an example, Appendix A. shows the JSON encoded data instances of 233 the native topology and the customized topology for Network Slice 234 Blue. 236 Client Topology Client Topology 237 Network Slice Blue Network Slice Red 238 +---+ +---+ +---+ 239 -----|R3 |--- ---|R2 |------|R3 | 240 / +---+ +---+ +---+ 241 +---+ +---+ \ +---+ 242 ---|R1 |------|R2 | -----|R4 |--- 243 +---+ +---+ +---+ 245 Clients 246 --------------------------------------------------------------------- 247 Provider 249 Customized Topology 250 Provider Network with Virtual Devices 252 Network Slice Blue: VR1, VR3, VR5 +---+ 253 ----------|VR5|------ 254 / +---+ 255 +---+ +---+ 256 ------|VR1|---------|VR3| 257 +---+ +---+ 258 ------|VR2|---------|VR4| 259 +---+ +---+ 260 \ +---+ 261 ----------|VR6|------ 262 Network Slice Red: VR2, VR4, VR6 +---+ 264 Virtual Devices 265 --------------------------------------------------------------------- 266 Physical Devices 268 Native Topology 269 Provider Network with Physical Devices 270 +---+ 271 ----------|R3 |------ 272 / +---+ 273 +---+ +---+ 274 ======|R1 |=========|R2 | 275 +---+ +---+ 276 \ +---+ 277 ----------|R4 |------ 278 +---+ 280 Figure 3: Network Slicing by Virtualization 282 3.2. Network Slicing by TE Overlay 284 Figure 4 shows a case where TE (Traffic Engineering) overlay is 285 applied to achieve logically separated client IETF network slices. 286 In the underlay TE capable network, TE tunnels are established to 287 support the TE links in the overlay network. These links and tunnels 288 maintain the characteristics required by the clients. The provider 289 selects the proper logical nodes and links in the overlay network, 290 assigns them to specific IETF network slices, and uses the data model 291 defined in this document to send the results to the clients. 293 Client Topology Client Topology 294 Network Slice Blue Network Slice Red 295 +---+ +---+ +---+ 296 -----|R3 |--- ---|R1 |------|R2 | 297 / +---+ +---+ +---+ 298 +---+ +---+ \ +---+ 299 ---|R1 |------|R2 | -----|R4 |--- 300 +---+ +---+ +---+ 302 Clients 303 --------------------------------------------------------------------- 304 Provider 306 Customized Topology 307 Provider Network with TE Isolation 309 Network Slice Blue: R1, R2, R3 310 +---+ 311 ----------|R3 |------ 312 / +---+ 313 +---+ +---+ 314 ======|R1 |=========|R2 | 315 +---+ +---+ 316 \ +---+ 317 ----------|R4 |------ 318 +---+ 319 Network Slice Red: R1, R2, R4 321 Overlay 322 --------------------------------------------------------------------- 323 Underlay 325 Native Topology 326 Provider Network with TE Tunnels 327 +---+ 328 TE Tunnel for Network Slice Blue ----------|R3 |------ 329 @@@@@@@@@@@@@@ / +---+ 330 +---+ +---+ +---+ 331 ======|R1 |--|R5 |--|R2 | 332 +---+ +---+ +---+ 333 ############## \ +---+ 334 TE Tunnel for Network Slice Red ----------|R4 |------ 335 +---+ 337 Figure 4: Network Slicing by TE Overlay 339 4. Model Tree Structure 341 TODO - Complete IETF network slice attributes that are technology- 342 agnostic and common to all use cases. 344 module: ietf-network-slice 345 augment /nw:networks/nw:network/nw:network-types: 346 +--rw network-slice! 347 augment /nw:networks/nw:network: 348 +--rw network-slice 349 +--rw optimization-criterion? identityref 350 +--rw delay-tolerance? boolean 351 +--rw periodicity* uint64 352 +--rw isolation-level? identityref 353 augment /nw:networks/nw:network/nw:node: 354 +--rw network-slice 355 +--rw isolation-level? identityref 356 +--rw compute-node-id? string 357 +--rw storage-id? string 358 augment /nw:networks/nw:network/nt:link: 359 +--rw network-slice 360 +--rw delay-tolerance? boolean 361 +--rw periodicity* uint64 362 +--rw isolation-level? identityref 364 5. YANG Module 366 This module references [RFC8345], [RFC8776], and [GSMA-NS-Template] 368 file "ietf-network-slice@2020-11-01.yang" 369 module ietf-network-slice { 370 yang-version 1.1; 371 namespace "urn:ietf:params:xml:ns:yang:ietf-network-slice"; 372 prefix "ns"; 374 import ietf-network { 375 prefix "nw"; 376 reference "RFC 8345: A YANG Data Model for Network Topologies"; 377 } 378 import ietf-network-topology { 379 prefix "nt"; 380 reference "RFC 8345: A YANG Data Model for Network Topologies"; 381 } 382 import ietf-te-types { 383 prefix "te-types"; 384 reference 385 "RFC 8776: Traffic Engineering Common YANG Types"; 386 } 388 organization 389 "IETF Traffic Engineering Architecture and Signaling (TEAS) 390 Working Group"; 392 contact 393 "WG Web: 394 WG List: 396 Editor: Xufeng Liu 397 399 Editor: Jeff Tantsura 400 402 Editor: Igor Bryskin 403 405 Editor: Luis Miguel Contreras Murillo 406 408 Editor: Qin Wu 409 411 Editor: Sergio Belotti 412 414 Editor: Reza Rokui 415 416 "; 418 description 419 "YANG data model for representing and managing network 420 slices. 422 Copyright (c) 2020 IETF Trust and the persons identified as 423 authors of the code. All rights reserved. 425 Redistribution and use in source and binary forms, with or 426 without modification, is permitted pursuant to, and subject to 427 the license terms contained in, the Simplified BSD License set 428 forth in Section 4.c of the IETF Trust's Legal Provisions 429 Relating to IETF Documents 430 (http://trustee.ietf.org/license-info). 432 This version of this YANG module is part of RFC XXXX; see the 433 RFC itself for full legal notices."; 435 revision 2020-11-01 { 436 description "Initial revision"; 437 reference 438 "RFC XXXX: YANG Data Model for Network Slices"; 439 } 441 /* 442 * Identities 443 */ 444 identity isolation-level { 445 description 446 "Base identity for the isolation-level."; 447 reference 448 "GSMA-NS-Template: Generic Network Slice Template, 449 Version 3.0."; 450 } 451 identity no-isolation { 452 base isolation-level; 453 description 454 "Network slices are not separated."; 455 } 456 identity physical-isolation { 457 base isolation-level; 458 description 459 "Network slices are physically separated (e.g. different rack, 460 different hardware, different location, etc.)."; 461 } 462 identity logical-isolation { 463 base isolation-level; 464 description 465 "Network slices are logically separated."; 466 } 467 identity process-isolation { 468 base physical-isolation; 469 description 470 "Process and threads isolation."; 471 } 472 identity physical-memory-isolation { 473 base physical-isolation; 474 description 475 "Process and threads isolation."; 476 } 477 identity physical-network-isolation { 478 base physical-isolation; 479 description 480 "Process and threads isolation."; 481 } 482 identity virtual-resource-isolation { 483 base logical-isolation; 484 description 485 "A network slice has access to specific range of resources 486 that do not overlap with other network slices 487 (e.g. VM isolation)."; 488 } 489 identity network-functions-isolation { 490 base logical-isolation; 491 description 492 "NF (Network Function) is dedicated to the network slice, but 493 virtual resources are shared."; 494 } 495 identity service-isolation { 496 base logical-isolation; 497 description 498 "NSC data are isolated from other NSCs, but virtual 499 resources and NFs are shared."; 500 } 502 /* 503 * Groupiings 504 */ 505 grouping network-slice-topology-attributes { 506 description "Network Slice topology scope attributes."; 507 container network-slice { 508 description 509 "Containing Network Slice attributes."; 510 leaf optimization-criterion { 511 type identityref { 512 base te-types:objective-function-type; 513 } 514 description 515 "Optimization criterion applied to this topology."; 516 } 517 leaf delay-tolerance { 518 type boolean; 519 description 520 "'true' if is not too critical how long it takes to deliver 521 the amount of data."; 522 reference 523 "GSMA-NS-Template: Generic Network Slice Template, 524 Version 3.0."; 525 } 526 leaf-list periodicity { 527 type uint64; 528 units seconds; 529 description 530 "A list of periodicities supported by the network slice."; 531 reference 532 "GSMA-NS-Template: Generic Network Slice Template, 533 Version 3.0."; 534 } 535 leaf isolation-level { 536 type identityref { 537 base isolation-level; 538 } 539 description 540 "A network slice instance may be fully or partly, logically 541 and/or physically, isolated from another network slice 542 instance. This attribute describes different types of 543 isolation:"; 544 } 545 } // network-slice 546 } // network-slice-topology-attributes 548 grouping network-slice-node-attributes { 549 description "Network Slice node scope attributes."; 550 container network-slice { 551 description 552 "Containing Network Slice attributes."; 553 leaf isolation-level { 554 type identityref { 555 base isolation-level; 556 } 557 description 558 "A network slice instance may be fully or partly, logically 559 and/or physically, isolated from another network slice 560 instance. This attribute describes different types of 561 isolation:"; 562 } 563 leaf compute-node-id { 564 type string; 565 description 566 "Reference to a compute node instance specified in 567 a data model specifying the computing resources."; 568 } 569 leaf storage-id { 570 type string; 571 description 572 "Reference to a storage instance specified in 573 a data model specifying the storage resources."; 575 } 576 } // network-slice 577 } // 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 3.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 3.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 } 628 augment "/nw:networks/nw:network" { 629 when "nw:network-types/ns:network-slice" { 630 description "Augment only for Network Slice topology."; 631 } 632 description "Augment topology configuration and state."; 633 uses network-slice-topology-attributes; 634 } 636 augment "/nw:networks/nw:network/nw:node" { 637 when "../nw:network-types/ns:network-slice" { 638 description "Augment only for Network Slice topology."; 639 } 640 description "Augment node configuration and state."; 641 uses network-slice-node-attributes; 642 } 644 augment "/nw:networks/nw:network/nt:link" { 645 when "../nw:network-types/ns:network-slice" { 646 description "Augment only for Network Slice topology."; 647 } 648 description "Augment link configuration and state."; 649 uses network-slice-link-attributes; 650 } 652 } 653 655 6. IANA Considerations 657 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 658 actual RFC number (and remove this note). 660 This document registers the following namespace URIs in the IETF XML 661 registry [RFC3688]: 663 -------------------------------------------------------------------- 664 URI: urn:ietf:params:xml:ns:yang:ietf-network-slice 665 Registrant Contact: The IESG. 666 XML: N/A, the requested URI is an XML namespace. 667 -------------------------------------------------------------------- 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 IETF 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 IETF network slice and related 710 networks. 712 /nw:networks/nw:network/nw:node/ns:network-slice 713 This subtree specifies the configurations of the nodes in a IETF 714 network slice. Modifying the configurations in this subtree can 715 change the traffic characteristics on this node and the related 716 networks. 718 /nw:networks/nw:network/nt:link/ns:network-slice 719 This subtree specifies the configurations of the links in a IETF 720 network slice. Modifying the configurations in this subtree can 721 change the traffic characteristics on this link and the related 722 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 IETF 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 IETF 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 [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 823 O. Gonzalez de Dios, "YANG Data Model for Traffic 824 Engineering (TE) Topologies", RFC 8795, 825 DOI 10.17487/RFC8795, August 2020, 826 . 828 [GSMA-NS-Template] 829 GSM Association, "Generic Network Slice Template, Version 830 3.0", NG.116, May 2020. 832 [I-D.nsdt-teas-ietf-network-slice-definition] 833 Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. 834 Tantsura, "Definition of IETF Network Slices", draft-nsdt- 835 teas-ietf-network-slice-definition-00 (work in progress), 836 October 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-11 (work in progress), 857 September 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-18 (work in progress), 863 September 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-06 (work in 870 progress), August 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-04 (work in 875 progress), July 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