idnits 2.17.1 draft-liu-teas-transport-network-slice-yang-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-teas-ietf-network-slices]), 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 9, 2021) is 1014 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'GSMA-NS-Template' == Outdated reference: A later version (-25) exists of draft-ietf-teas-ietf-network-slices-00 ** Downref: Normative reference to an Informational draft: draft-ietf-teas-ietf-network-slices (ref. 'I-D.ietf-teas-ietf-network-slices') == Outdated reference: A later version (-17) exists of draft-ietf-ccamp-otn-topo-yang-12 == Outdated reference: A later version (-11) exists of draft-ietf-teas-actn-yang-07 Summary: 2 errors (**), 0 flaws (~~), 5 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 10, 2022 Microsoft 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 9, 2021 17 IETF Network Slice YANG Data Model 18 draft-liu-teas-transport-network-slice-yang-04 20 Abstract 22 This document describes a YANG data model for managing and 23 controlling IETF network slices, defined in 24 [I-D.ietf-teas-ietf-network-slices]. 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 10, 2022. 43 Copyright Notice 45 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . . 6 68 3.1. Network Slicing by Virtualization . . . . . . . . . . . . 6 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.ietf-teas-ietf-network-slices] 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 | augments 163 +--------------+------+-------+--------------+ 164 | | | | 165 | | | | 166 +-----^----+ +-----^----+ +-----^----+ ......^..... 167 | L2 | | L3 | | TE | : Network : 168 | Topology | | Topology | | Topology | : Slice : 169 | Model | | Model | | Model | : Model : 170 +----------+ +----------+ +-----^----+ '''''''''''' 171 | 172 | 173 +-----^----+ 174 | OTN | 175 | Topology | 176 | Model | 177 +----------+ 179 Figure 1: Model Relationships 181 2.2. Network Slice with TE 183 In many situations, an IETF network slide needs to have TE (Traffic 184 Engineering) capabilities to achieve certain network characteristics. 185 The TE Topology Model defined in [RFC8795] can be used to make an 186 IETF network slice TE capable. To achieve this, an IETF network 187 slice instance will be configured to have both "network-slice" and 188 "te-topology" network types, taking advantage of the multiple 189 inheritance capability featured by the network topology model 190 [RFC8345]. The following diagram shows their relations. 192 +---------------------+ +---------------------+ 193 | Network Slice | | TE Topology | 194 | ietf-network-slice | | ietf-te-topology | 195 +----------^----------+ +----------^----------+ 196 | inherits attributes from | 197 \ / 198 \ / 199 \ / 200 +--------------------------------------------------------+ 201 | Network Slice with TE | 202 +--------------------------------------------------------+ 203 | ietf-network-topology: | 204 | network-id (key) | 205 | network-types: { | 206 | network-slice{} | 207 | te-topology{} | 208 | } | 209 | | 210 +-----------------------------+--------------------------+ 211 | ietf-network-slice: | ietf-te-topology: | 212 | | | 213 +-----------------------------+--------------------------+ 215 Figure 2: Network Slice with TE 217 This method can be applied to other types of network topology models 218 too. For example, when a network topology instance is configured to 219 have the types of "network-slice" defined in this document, "te- 220 topology" defined in [RFC8795], and "l3-unicast-topology" defined in 221 [RFC8346], this network topology instance becomes an IETF network 222 slice instance that can perform layer 3 traffic engineering. 224 2.3. ACTN for Network Slicing 226 Since ACTN topology data models are based on the network topology 227 model defined in [RFC8345], the augmentations defined in this 228 document are effective augmentations to the ACTN topology data 229 models, resulting in making the ACTN framework [RFC8453] and data 230 models [I-D.ietf-teas-actn-yang] capable of slicing networks with the 231 required network characteristics. 233 3. Model Applicability 235 There are many technologies to achieve network slicing. The data 236 model defined in this document can be applied to a wide ranges of 237 cases. This section describes how this data model is applied to a 238 few cases. 240 3.1. Network Slicing by Virtualization 242 In the case shown in Figure 3, node virtualization is used to 243 separate and allocate resources in physical devices. Two virtual 244 routers VR1 and VR2 are created over physical router R1. Each of the 245 virtual routers takes a portion of the resources such as ports and 246 memory in the physical router. Depending on the requirements and the 247 implementations, they may share certain resources such as processors, 248 ASICs, and switch fabric. 250 As an example, Appendix A. shows the JSON encoded data instances of 251 the native topology and the customized topology for Network Slice 252 Blue. 254 Client Topology Client Topology 255 Network Slice Blue Network Slice Red 256 +---+ +---+ +---+ 257 -----|R3 |--- ---|R2 |------|R3 | 258 / +---+ +---+ +---+ 259 +---+ +---+ \ +---+ 260 ---|R1 |------|R2 | -----|R4 |--- 261 +---+ +---+ +---+ 263 Clients 264 --------------------------------------------------------------------- 265 Provider 267 Customized Topology 268 Provider Network with Virtual Devices 270 Network Slice Blue: VR1, VR3, VR5 +---+ 271 ----------|VR5|------ 272 / +---+ 273 +---+ +---+ 274 ------|VR1|---------|VR3| 275 +---+ +---+ 276 ------|VR2|---------|VR4| 277 +---+ +---+ 278 \ +---+ 279 ----------|VR6|------ 280 Network Slice Red: VR2, VR4, VR6 +---+ 282 Virtual Devices 283 --------------------------------------------------------------------- 284 Physical Devices 286 Native Topology 287 Provider Network with Physical Devices 288 +---+ 289 ----------|R3 |------ 290 / +---+ 291 +---+ +---+ 292 ======|R1 |=========|R2 | 293 +---+ +---+ 294 \ +---+ 295 ----------|R4 |------ 296 +---+ 298 Figure 3: Network Slicing by Virtualization 300 3.2. Network Slicing by TE Overlay 302 Figure 4 shows a case where TE (Traffic Engineering) overlay is 303 applied to achieve logically separated client IETF network slices. 304 In the underlay TE capable network, TE tunnels are established to 305 support the TE links in the overlay network. These links and tunnels 306 maintain the characteristics required by the clients. The provider 307 selects the proper logical nodes and links in the overlay network, 308 assigns them to specific IETF network slices, and uses the data model 309 defined in this document to send the results to the clients. 311 Client Topology Client Topology 312 Network Slice Blue Network Slice Red 313 +---+ +---+ +---+ 314 -----|R3 |--- ---|R1 |------|R2 | 315 / +---+ +---+ +---+ 316 +---+ +---+ \ +---+ 317 ---|R1 |------|R2 | -----|R4 |--- 318 +---+ +---+ +---+ 320 Clients 321 --------------------------------------------------------------------- 322 Provider 324 Customized Topology 325 Provider Network with TE Isolation 327 Network Slice Blue: R1, R2, R3 328 +---+ 329 ----------|R3 |------ 330 / +---+ 331 +---+ +---+ 332 ======|R1 |=========|R2 | 333 +---+ +---+ 334 \ +---+ 335 ----------|R4 |------ 336 +---+ 337 Network Slice Red: R1, R2, R4 339 Overlay 340 --------------------------------------------------------------------- 341 Underlay 343 Native Topology 344 Provider Network with TE Tunnels 345 +---+ 346 TE Tunnel for Network Slice Blue ----------|R3 |------ 347 @@@@@@@@@@@@@@ / +---+ 348 +---+ +---+ +---+ 349 ======|R1 |--|R5 |--|R2 | 350 +---+ +---+ +---+ 351 ############## \ +---+ 352 TE Tunnel for Network Slice Red ----------|R4 |------ 353 +---+ 355 Figure 4: Network Slicing by TE Overlay 357 4. Model Tree Structure 359 TODO - Complete IETF network slice attributes that are technology- 360 agnostic and common to all use cases. 362 module: ietf-network-slice 363 augment /nw:networks/nw:network/nw:network-types: 364 +--rw network-slice! 365 augment /nw:networks/nw:network: 366 +--rw network-slice 367 +--rw optimization-criterion? identityref 368 +--rw delay-tolerance? boolean 369 +--rw periodicity* uint64 370 +--rw isolation-level? identityref 371 augment /nw:networks/nw:network/nw:node: 372 +--rw network-slice 373 +--rw isolation-level? identityref 374 +--rw compute-node-id? string 375 +--rw storage-id? string 376 augment /nw:networks/nw:network/nt:link: 377 +--rw network-slice 378 +--rw delay-tolerance? boolean 379 +--rw periodicity* uint64 380 +--rw isolation-level? identityref 382 5. YANG Module 384 This module references [RFC8345], [RFC8776], and [GSMA-NS-Template] 386 file "ietf-network-slice@2020-11-01.yang" 387 module ietf-network-slice { 388 yang-version 1.1; 389 namespace "urn:ietf:params:xml:ns:yang:ietf-network-slice"; 390 prefix "ns"; 392 import ietf-network { 393 prefix "nw"; 394 reference "RFC 8345: A YANG Data Model for Network Topologies"; 395 } 396 import ietf-network-topology { 397 prefix "nt"; 398 reference "RFC 8345: A YANG Data Model for Network Topologies"; 399 } 400 import ietf-te-types { 401 prefix "te-types"; 402 reference 403 "RFC 8776: Traffic Engineering Common YANG Types"; 404 } 406 organization 407 "IETF Traffic Engineering Architecture and Signaling (TEAS) 408 Working Group"; 410 contact 411 "WG Web: 412 WG List: 414 Editor: Xufeng Liu 415 417 Editor: Jeff Tantsura 418 420 Editor: Igor Bryskin 421 423 Editor: Luis Miguel Contreras Murillo 424 426 Editor: Qin Wu 427 429 Editor: Sergio Belotti 430 432 Editor: Reza Rokui 433 434 "; 436 description 437 "YANG data model for representing and managing network 438 slices. 440 Copyright (c) 2020 IETF Trust and the persons identified as 441 authors of the code. All rights reserved. 443 Redistribution and use in source and binary forms, with or 444 without modification, is permitted pursuant to, and subject to 445 the license terms contained in, the Simplified BSD License set 446 forth in Section 4.c of the IETF Trust's Legal Provisions 447 Relating to IETF Documents 448 (http://trustee.ietf.org/license-info). 450 This version of this YANG module is part of RFC XXXX; see the 451 RFC itself for full legal notices."; 453 revision 2020-11-01 { 454 description "Initial revision"; 455 reference 456 "RFC XXXX: YANG Data Model for Network Slices"; 457 } 459 /* 460 * Identities 461 */ 462 identity isolation-level { 463 description 464 "Base identity for the isolation-level."; 465 reference 466 "GSMA-NS-Template: Generic Network Slice Template, 467 Version 3.0."; 468 } 469 identity no-isolation { 470 base isolation-level; 471 description 472 "Network slices are not separated."; 473 } 474 identity physical-isolation { 475 base isolation-level; 476 description 477 "Network slices are physically separated (e.g. different rack, 478 different hardware, different location, etc.)."; 479 } 480 identity logical-isolation { 481 base isolation-level; 482 description 483 "Network slices are logically separated."; 484 } 485 identity process-isolation { 486 base physical-isolation; 487 description 488 "Process and threads isolation."; 489 } 490 identity physical-memory-isolation { 491 base physical-isolation; 492 description 493 "Process and threads isolation."; 494 } 495 identity physical-network-isolation { 496 base physical-isolation; 497 description 498 "Process and threads isolation."; 499 } 500 identity virtual-resource-isolation { 501 base logical-isolation; 502 description 503 "A network slice has access to specific range of resources 504 that do not overlap with other network slices 505 (e.g. VM isolation)."; 506 } 507 identity network-functions-isolation { 508 base logical-isolation; 509 description 510 "NF (Network Function) is dedicated to the network slice, but 511 virtual resources are shared."; 512 } 513 identity service-isolation { 514 base logical-isolation; 515 description 516 "NSC data are isolated from other NSCs, but virtual 517 resources and NFs are shared."; 518 } 520 /* 521 * Groupiings 522 */ 523 grouping network-slice-topology-attributes { 524 description "Network Slice topology scope attributes."; 525 container network-slice { 526 description 527 "Containing Network Slice attributes."; 528 leaf optimization-criterion { 529 type identityref { 530 base te-types:objective-function-type; 531 } 532 description 533 "Optimization criterion applied to this topology."; 534 } 535 leaf delay-tolerance { 536 type boolean; 537 description 538 "'true' if is not too critical how long it takes to deliver 539 the amount of data."; 540 reference 541 "GSMA-NS-Template: Generic Network Slice Template, 542 Version 3.0."; 543 } 544 leaf-list periodicity { 545 type uint64; 546 units seconds; 547 description 548 "A list of periodicities supported by the network slice."; 549 reference 550 "GSMA-NS-Template: Generic Network Slice Template, 551 Version 3.0."; 552 } 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 } // network-slice 564 } // network-slice-topology-attributes 566 grouping network-slice-node-attributes { 567 description "Network Slice node scope attributes."; 568 container network-slice { 569 description 570 "Containing Network Slice attributes."; 571 leaf isolation-level { 572 type identityref { 573 base isolation-level; 574 } 575 description 576 "A network slice instance may be fully or partly, logically 577 and/or physically, isolated from another network slice 578 instance. This attribute describes different types of 579 isolation:"; 580 } 581 leaf compute-node-id { 582 type string; 583 description 584 "Reference to a compute node instance specified in 585 a data model specifying the computing resources."; 586 } 587 leaf storage-id { 588 type string; 589 description 590 "Reference to a storage instance specified in 591 a data model specifying the storage resources."; 593 } 594 } // network-slice 595 } // network-slice-node-attributes 597 grouping network-slice-link-attributes { 598 description "Network Slice link scope attributes"; 599 container network-slice { 600 description 601 "Containing Network Slice attributes."; 602 leaf delay-tolerance { 603 type boolean; 604 description 605 "'true' if is not too critical how long it takes to deliver 606 the amount of data."; 607 reference 608 "GSMA-NS-Template: Generic Network Slice Template, 609 Version 3.0."; 610 } 611 leaf-list periodicity { 612 type uint64; 613 units seconds; 614 description 615 "A list of periodicities supported by the network slice."; 616 reference 617 "GSMA-NS-Template: Generic Network Slice Template, 618 Version 3.0."; 619 } 620 leaf isolation-level { 621 type identityref { 622 base isolation-level; 623 } 624 description 625 "A network slice instance may be fully or partly, logically 626 and/or physically, isolated from another network slice 627 instance. This attribute describes different types of 628 isolation:"; 629 } 630 } // network-slice 631 } // network-slice-link-attributes 633 /* 634 * Data nodes 635 */ 636 augment "/nw:networks/nw:network/nw:network-types" { 637 description 638 "Defines the Network Slice topology type."; 639 container network-slice { 640 presence "Indicates Network Slice topology"; 641 description 642 "Its presence identifies the Network Slice type."; 643 } 644 } 646 augment "/nw:networks/nw:network" { 647 when "nw:network-types/ns:network-slice" { 648 description "Augment only for Network Slice topology."; 649 } 650 description "Augment topology configuration and state."; 651 uses network-slice-topology-attributes; 652 } 654 augment "/nw:networks/nw:network/nw:node" { 655 when "../nw:network-types/ns:network-slice" { 656 description "Augment only for Network Slice topology."; 657 } 658 description "Augment node configuration and state."; 659 uses network-slice-node-attributes; 660 } 662 augment "/nw:networks/nw:network/nt:link" { 663 when "../nw:network-types/ns:network-slice" { 664 description "Augment only for Network Slice topology."; 665 } 666 description "Augment link configuration and state."; 667 uses network-slice-link-attributes; 668 } 670 } 671 673 6. IANA Considerations 675 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 676 actual RFC number (and remove this note). 678 This document registers the following namespace URIs in the IETF XML 679 registry [RFC3688]: 681 -------------------------------------------------------------------- 682 URI: urn:ietf:params:xml:ns:yang:ietf-network-slice 683 Registrant Contact: The IESG. 684 XML: N/A, the requested URI is an XML namespace. 685 -------------------------------------------------------------------- 686 This document registers the following YANG modules in the YANG Module 687 Names registry [RFC6020]: 689 -------------------------------------------------------------------- 690 name: ietf-l3-te-topology 691 namespace: urn:ietf:params:xml:ns:yang:ietf-network-slice 692 prefix: ns 693 reference: RFC XXXX 694 -------------------------------------------------------------------- 696 7. Security Considerations 698 The YANG module specified in this document defines a schema for data 699 that is designed to be accessed via network management protocols such 700 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 701 is the secure transport layer, and the mandatory-to-implement secure 702 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 703 is HTTPS, and the mandatory-to-implement secure transport is TLS 704 [RFC8446]. 706 The Network Configuration Access Control Model (NACM) [RFC8341] 707 provides the means to restrict access for particular NETCONF or 708 RESTCONF users to a preconfigured subset of all available NETCONF or 709 RESTCONF protocol operations and content. 711 There are a number of data nodes defined in this YANG module that are 712 writable/creatable/deletable (i.e., config true, which is the 713 default). These data nodes may be considered sensitive or vulnerable 714 in some network environments. Write operations (e.g., edit-config) 715 to these data nodes without proper protection can have a negative 716 effect on network operations. These are the subtrees and data nodes 717 and their sensitivity/vulnerability: 719 /nw:networks/nw:network/nw:network-types/ns:network-slice 720 This subtree specifies the network slice type. Modifying the 721 configurations can make network slice type invalid and cause 722 interruption to IETF network slices. 724 /nw:networks/nw:network/ns:network-slice 725 This subtree specifies the topology-wide configurations. 726 Modifying the configurations here can cause traffic 727 characteristics changed in this IETF network slice and related 728 networks. 730 /nw:networks/nw:network/nw:node/ns:network-slice 731 This subtree specifies the configurations of the nodes in a IETF 732 network slice. Modifying the configurations in this subtree can 733 change the traffic characteristics on this node and the related 734 networks. 736 /nw:networks/nw:network/nt:link/ns:network-slice 737 This subtree specifies the configurations of the links in a IETF 738 network slice. Modifying the configurations in this subtree can 739 change the traffic characteristics on this link and the related 740 networks. 742 Some of the readable data nodes in this YANG module may be considered 743 sensitive or vulnerable in some network environments. It is thus 744 important to control read access (e.g., via get, get-config, or 745 notification) to these data nodes. These are the subtrees and data 746 nodes and their sensitivity/vulnerability: 748 /nw:networks/nw:network/nw:network-types/ns:network-slice 749 Unauthorized access to this subtree can disclose the network slice 750 type. 752 /nw:networks/nw:network/ns:network-slice 753 Unauthorized access to this subtree can disclose the topology-wide 754 states. 756 /nw:networks/nw:network/nw:node/ns:network-slice 757 Unauthorized access to this subtree can disclose the operational 758 state information of the nodes in a IETF network slice. 760 /nw:networks/nw:network/nt:link/ns:network-slic 761 Unauthorized access to this subtree can disclose the operational 762 state information of the links in a IETF network slice. 764 8. Acknowledgements 766 The TEAS Network Slicing Design Team (NSDT) members included Aijun 767 Wang, Dong Jie, Eric Gray, Jari Arkko, Jeff Tantsura, John E Drake, 768 Luis M. Contreras, Rakesh Gandhi, Ran Chen, Reza Rokui, Ricard 769 Vilalta, Ron Bonica, Sergio Belotti, Tomonobu Niwa, Xuesong Geng, and 770 Xufeng Liu. 772 9. References 774 9.1. Normative References 776 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 777 Requirement Levels", BCP 14, RFC 2119, 778 DOI 10.17487/RFC2119, March 1997, 779 . 781 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 782 DOI 10.17487/RFC3688, January 2004, 783 . 785 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 786 the Network Configuration Protocol (NETCONF)", RFC 6020, 787 DOI 10.17487/RFC6020, October 2010, 788 . 790 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 791 and A. Bierman, Ed., "Network Configuration Protocol 792 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 793 . 795 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 796 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 797 . 799 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 800 RFC 7950, DOI 10.17487/RFC7950, August 2016, 801 . 803 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 804 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 805 . 807 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 808 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 809 May 2017, . 811 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 812 Access Control Model", STD 91, RFC 8341, 813 DOI 10.17487/RFC8341, March 2018, 814 . 816 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 817 and R. Wilton, "Network Management Datastore Architecture 818 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 819 . 821 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 822 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 823 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 824 2018, . 826 [RFC8346] Clemm, A., Medved, J., Varga, R., Liu, X., 827 Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model 828 for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346, 829 March 2018, . 831 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 832 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 833 . 835 [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 836 "Common YANG Data Types for Traffic Engineering", 837 RFC 8776, DOI 10.17487/RFC8776, June 2020, 838 . 840 [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 841 O. Gonzalez de Dios, "YANG Data Model for Traffic 842 Engineering (TE) Topologies", RFC 8795, 843 DOI 10.17487/RFC8795, August 2020, 844 . 846 [GSMA-NS-Template] 847 GSM Association, "Generic Network Slice Template, Version 848 3.0", NG.116, May 2020. 850 [I-D.ietf-teas-ietf-network-slices] 851 Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S., 852 Makhijani, K., Contreras, L. M., and J. Tantsura, 853 "Framework for IETF Network Slices", draft-ietf-teas-ietf- 854 network-slices-00 (work in progress), April 2021. 856 9.2. Informative References 858 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 859 RFC 7951, DOI 10.17487/RFC7951, August 2016, 860 . 862 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 863 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 864 . 866 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 867 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 868 DOI 10.17487/RFC8453, August 2018, 869 . 871 [I-D.ietf-ccamp-otn-topo-yang] 872 Zheng, H., Busi, I., Liu, X., Belotti, S., and O. G. D. 873 Dios, "A YANG Data Model for Optical Transport Network 874 Topology", draft-ietf-ccamp-otn-topo-yang-12 (work in 875 progress), February 2021. 877 [I-D.ietf-i2rs-yang-l2-network-topology] 878 Dong, J., Wei, X., Wu, Q., Boucadair, M., and A. Liu, "A 879 YANG Data Model for Layer 2 Network Topologies", draft- 880 ietf-i2rs-yang-l2-network-topology-18 (work in progress), 881 September 2020. 883 [I-D.ietf-teas-actn-yang] 884 Lee, Y., Zheng, H., Ceccarelli, D., Yoon, B. Y., and S. 885 Belotti, "Applicability of YANG models for Abstraction and 886 Control of Traffic Engineered Networks", draft-ietf-teas- 887 actn-yang-07 (work in progress), February 2021. 889 Appendix A. Data Tree for the Example in Section 3.1. 891 A.1. Native Topology 893 This section contains an example of an instance data tree in the JSON 894 encoding [RFC7951]. The example instantiates "ietf-network" for the 895 native topology depicted in Figure 3. 897 { 898 "ietf-network:networks": { 899 "network": [ 900 { 901 "network-id":"example-native-topology", 902 "network-types": { 903 }, 904 "node": [ 905 { 906 "node-id":"R1", 907 "ietf-network-topology:termination-point": [ 908 { 909 "tp-id":"1-0-1" 910 }, 911 { 912 "tp-id":"1-0-2" 913 }, 914 { 915 "tp-id":"1-2-1" 916 }, 917 { 918 "tp-id":"1-2-2" 919 } 920 ] 921 }, 922 { 923 "node-id":"R2", 924 "ietf-network-topology:termination-point": [ 925 { 926 "tp-id":"2-1-1" 927 }, 928 { 929 "tp-id":"2-1-2" 930 }, 931 { 932 "tp-id":"2-3-1" 933 }, 934 { 935 "tp-id":"2-4-1" 936 } 938 ] 939 }, 940 { 941 "node-id":"R3", 942 "ietf-network-topology:termination-point": [ 943 { 944 "tp-id":"3-0-1" 945 }, 946 { 947 "tp-id":"3-2-1" 948 } 949 ] 950 }, 951 { 952 "node-id":"R4", 953 "ietf-network-topology:termination-point": [ 954 { 955 "tp-id":"4-0-1" 956 }, 957 { 958 "tp-id":"4-2-1" 959 } 960 ] 961 } 962 ], 963 "ietf-network-topology:link": [ 964 { 965 "link-id":"R1,1-0-1,,", 966 "source": { 967 "source-node":"R1", 968 "source-tp":"1-0-1" 969 } 970 }, 971 { 972 "link-id":",,R1,1-0-1", 973 "destination": { 974 "dest-node":"R1", 975 "dest-tp":"1-0-1" 976 } 977 }, 978 { 979 "link-id":"R1,1-0-2,,", 980 "source": { 981 "source-node":"R1", 982 "source-tp":"1-0-2" 983 } 984 }, 985 { 986 "link-id":",,R1,1-0-2", 987 "destination": { 988 "dest-node":"R1", 989 "dest-tp":"1-0-2" 990 } 991 }, 992 { 993 "link-id":"R1,1-2-1,R2,2-1-1", 994 "source": { 995 "source-node":"R1", 996 "source-tp":"1-2-1" 997 }, 998 "destination": { 999 "dest-node":"R2", 1000 "dest-tp":"2-1-1" 1001 } 1002 }, 1003 { 1004 "link-id":"R2,2-1-1,R1,1-2-1", 1005 "source": { 1006 "source-node":"R2", 1007 "source-tp":"2-1-1" 1008 }, 1009 "destination": { 1010 "dest-node":"R1", 1011 "dest-tp":"1-2-1" 1012 } 1013 }, 1014 { 1015 "link-id":"R1,1-2-2,R2,2-1-2", 1016 "source": { 1017 "source-node":"R1", 1018 "source-tp":"1-2-2" 1019 }, 1020 "destination": { 1021 "dest-node":"R2", 1022 "dest-tp":"2-1-2" 1023 } 1024 }, 1025 { 1026 "link-id":"R2,2-1-2,R1,1-2-2", 1027 "source": { 1028 "source-node":"R2", 1029 "source-tp":"2-1-2" 1030 }, 1031 "destination": { 1032 "dest-node":"R1", 1033 "dest-tp":"1-2-2" 1035 } 1036 }, 1037 { 1038 "link-id":"R2,2-3-1,R3,3-2-1", 1039 "source": { 1040 "source-node":"R2", 1041 "source-tp":"2-3-1" 1042 }, 1043 "destination": { 1044 "dest-node":"R3", 1045 "dest-tp":"3-2-1" 1046 } 1047 }, 1048 { 1049 "link-id":"R3,3-2-1,R2,2-3-1", 1050 "source": { 1051 "source-node":"R3", 1052 "source-tp":"3-2-1" 1053 }, 1054 "destination": { 1055 "dest-node":"R2", 1056 "dest-tp":"2-3-1" 1057 } 1058 }, 1059 { 1060 "link-id":"R2,2-4-1,R4,4-2-1", 1061 "source": { 1062 "source-node":"R2", 1063 "source-tp":"2-4-1" 1064 }, 1065 "destination": { 1066 "dest-node":"R4", 1067 "dest-tp":"4-2-1" 1068 } 1069 }, 1070 { 1071 "link-id":"R4,4-2-1,R2,2-4-1", 1072 "source": { 1073 "source-node":"R4", 1074 "source-tp":"4-2-1" 1075 }, 1076 "destination": { 1077 "dest-node":"R2", 1078 "dest-tp":"2-4-1" 1079 } 1080 }, 1081 { 1082 "link-id":"R3,3-0-1,,", 1083 "source": { 1084 "source-node":"R3", 1085 "source-tp":"3-0-1" 1086 } 1087 }, 1088 { 1089 "link-id":",,R3,3-0-1", 1090 "destination": { 1091 "dest-node":"R3", 1092 "dest-tp":"3-0-1" 1093 } 1094 }, 1095 { 1096 "link-id":"R4,4-0-1,,", 1097 "source": { 1098 "source-node":"R4", 1099 "source-tp":"4-0-1" 1100 } 1101 }, 1102 { 1103 "link-id":",,R4,4-0-1", 1104 "destination": { 1105 "dest-node":"R4", 1106 "dest-tp":"4-0-1" 1107 } 1108 } 1109 ] 1110 } 1111 ] 1112 } 1113 } 1115 A.2. Network Slice Blue 1117 This section contains an example of an instance data tree in the JSON 1118 encoding [RFC7951]. The example instantiates "ietf-network-slice" 1119 for the topology customized for Network Slice Blue depicted in 1120 Figure 3. 1122 { 1123 "ietf-network:networks": { 1124 "network": [ 1125 { 1126 "network-id":"example-customized-blue-topology", 1127 "network-types": { 1128 "ietf-network-slice:network-slice": { 1129 } 1130 }, 1131 "supporting-network": [ 1132 { 1133 "network-ref":"example-native-topology" 1134 } 1135 ], 1136 "node": [ 1137 { 1138 "node-id":"VR1", 1139 "supporting-node": [ 1140 { 1141 "network-ref":"example-native-topology", 1142 "node-ref":"R1" 1143 } 1144 ], 1145 "ietf-network-slice:network-slice": { 1146 "isolation-level": 1147 "ietf-network-slice:physical-memory-isolation" 1148 }, 1149 "ietf-network-topology:termination-point": [ 1150 { 1151 "tp-id":"1-0-1" 1152 }, 1153 { 1154 "tp-id":"1-3-1" 1155 } 1156 ] 1157 }, 1158 { 1159 "node-id":"VR3", 1160 "supporting-node": [ 1161 { 1162 "network-ref":"example-native-topology", 1163 "node-ref":"R2" 1164 } 1165 ], 1166 "ietf-network-slice:network-slice": { 1167 "isolation-level": 1168 "ietf-network-slice:physical-memory-isolation" 1169 }, 1170 "ietf-network-topology:termination-point": [ 1171 { 1172 "tp-id":"3-1-1" 1173 }, 1174 { 1175 "tp-id":"3-5-1" 1176 } 1178 ] 1179 }, 1180 { 1181 "node-id":"VR5", 1182 "supporting-node": [ 1183 { 1184 "network-ref":"example-native-topology", 1185 "node-ref":"R3" 1186 } 1187 ], 1188 "ietf-network-slice:network-slice": { 1189 "isolation-level": 1190 "ietf-network-slice:physical-memory-isolation" 1191 }, 1192 "ietf-network-topology:termination-point": [ 1193 { 1194 "tp-id":"5-3-1" 1195 }, 1196 { 1197 "tp-id":"5-0-1" 1198 } 1199 ] 1200 } 1201 ], 1202 "ietf-network-topology:link": [ 1203 { 1204 "link-id":"VR1,1-0-1,,", 1205 "source": { 1206 "source-node":"VR1", 1207 "source-tp":"1-0-1" 1208 }, 1209 "supporting-link": [ 1210 { 1211 "network-ref":"example-native-topology", 1212 "link-ref":"R1,1-0-1,," 1213 } 1214 ], 1215 "ietf-network-slice:network-slice": { 1216 "isolation-level": 1217 "ietf-network-slice:physical-network-isolation" 1218 } 1219 }, 1220 { 1221 "link-id":",,VR1,1-0-1", 1222 "destination": { 1223 "dest-node":"VR1", 1224 "dest-tp":"1-0-1" 1225 }, 1226 "supporting-link": [ 1227 { 1228 "network-ref":"example-native-topology", 1229 "link-ref":",,R1,1-0-1" 1230 } 1231 ], 1232 "ietf-network-slice:network-slice": { 1233 "isolation-level": 1234 "ietf-network-slice:physical-network-isolation" 1235 } 1236 }, 1237 { 1238 "link-id":"VR1,1-3-1,VR3,3-1-1", 1239 "source": { 1240 "source-node":"VR1", 1241 "source-tp":"1-3-1" 1242 }, 1243 "destination": { 1244 "dest-node":"VR3", 1245 "dest-tp":"3-1-1" 1246 }, 1247 "supporting-link": [ 1248 { 1249 "network-ref":"example-native-topology", 1250 "link-ref":"R1,1-2-1,R2,2-1-1" 1251 } 1252 ], 1253 "ietf-network-slice:network-slice": { 1254 "isolation-level": 1255 "ietf-network-slice:physical-network-isolation" 1256 } 1257 }, 1258 { 1259 "link-id":"VR3,3-1-1,VR1,1-3-1", 1260 "source": { 1261 "source-node":"VR3", 1262 "source-tp":"3-1-1" 1263 }, 1264 "destination": { 1265 "dest-node":"R1", 1266 "dest-tp":"1-3-1" 1267 }, 1268 "supporting-link": [ 1269 { 1270 "network-ref":"example-native-topology", 1271 "link-ref":"R2,2-1-1,R1,1-2-1" 1272 } 1273 ], 1274 "ietf-network-slice:network-slice": { 1275 "isolation-level": 1276 "ietf-network-slice:physical-network-isolation" 1277 } 1278 }, 1279 { 1280 "link-id":"VR3,3-5-1,VR5,5-3-1", 1281 "source": { 1282 "source-node":"VR3", 1283 "source-tp":"3-5-1" 1284 }, 1285 "destination": { 1286 "dest-node":"VR5", 1287 "dest-tp":"5-3-1" 1288 }, 1289 "supporting-link": [ 1290 { 1291 "network-ref":"example-native-topology", 1292 "link-ref":"R2,2-3-1,R3,3-2-1" 1293 } 1294 ], 1295 "ietf-network-slice:network-slice": { 1296 "isolation-level": 1297 "ietf-network-slice:physical-network-isolation" 1298 } 1299 }, 1300 { 1301 "link-id":"VR5,5-3-1,VR3,3-5-1", 1302 "source": { 1303 "source-node":"VR5", 1304 "source-tp":"5-3-1" 1305 }, 1306 "destination": { 1307 "dest-node":"VR3", 1308 "dest-tp":"3-5-1" 1309 }, 1310 "supporting-link": [ 1311 { 1312 "network-ref":"example-native-topology", 1313 "link-ref":"R3,3-2-1,R2,2-3-1" 1314 } 1315 ], 1316 "ietf-network-slice:network-slice": { 1317 "isolation-level": 1318 "ietf-network-slice:physical-network-isolation" 1319 } 1320 }, 1321 { 1322 "link-id":"VR5,5-0-1,,", 1323 "source": { 1324 "source-node":"VR5", 1325 "source-tp":"5-0-1" 1326 }, 1327 "supporting-link": [ 1328 { 1329 "network-ref":"example-native-topology", 1330 "link-ref":"R3,3-0-1,," 1331 } 1332 ], 1333 "ietf-network-slice:network-slice": { 1334 "isolation-level": 1335 "ietf-network-slice:physical-network-isolation" 1336 } 1337 }, 1338 { 1339 "link-id":",,VR5,5-0-1", 1340 "destination": { 1341 "dest-node":"VR5", 1342 "dest-tp":"5-0-1" 1343 }, 1344 "supporting-link": [ 1345 { 1346 "network-ref":"example-native-topology", 1347 "link-ref":",,R3,3-0-1" 1348 } 1349 ], 1350 "ietf-network-slice:network-slice": { 1351 "isolation-level": 1352 "ietf-network-slice:physical-network-isolation" 1353 } 1354 } 1355 ], 1356 "ietf-network-slice:network-slice": { 1357 "optimization-criterion": 1358 "ietf-te-types:of-minimize-cost-path", 1359 "isolation-level": 1360 "ietf-network-slice:physical-isolation" 1361 } 1362 } 1363 ] 1364 } 1365 } 1367 Authors' Addresses 1369 Xufeng Liu 1370 Volta Networks 1372 EMail: xufeng.liu.ietf@gmail.com 1374 Jeff Tantsura 1375 Microsoft 1377 EMail: jefftant.ietf@gmail.com 1379 Igor Bryskin 1380 Individual 1382 EMail: i_bryskin@yahoo.com 1384 Luis Miguel Contreras Murillo 1385 Telefonica 1387 EMail: luismiguel.contrerasmurillo@telefonica.com 1389 Qin Wu 1390 Huawei 1392 EMail: bill.wu@huawei.com 1394 Sergio Belotti 1395 Nokia 1397 EMail: sergio.belotti@nokia.com 1399 Reza Rokui 1400 Nokia 1401 Canada 1403 EMail: reza.rokui@nokia.com