idnits 2.17.1 draft-liu-teas-transport-network-slice-yang-05.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 (March 6, 2022) is 774 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) -- Looks like a reference, but probably isn't: '1' on line 524 -- Looks like a reference, but probably isn't: '2' on line 528 -- Looks like a reference, but probably isn't: '3' on line 524 -- Looks like a reference, but probably isn't: '4' on line 528 -- Possible downref: Non-RFC (?) normative reference: ref. 'GSMA-NS-Template' == Outdated reference: A later version (-25) exists of draft-ietf-teas-ietf-network-slices-07 ** 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-13 == Outdated reference: A later version (-11) exists of draft-ietf-teas-actn-yang-08 == Outdated reference: A later version (-10) exists of draft-ietf-teas-ietf-network-slice-nbi-yang-01 == Outdated reference: A later version (-05) exists of draft-contreras-teas-slice-controller-models-02 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Liu 3 Internet-Draft IBM Corporation 4 Intended status: Standards Track J. Tantsura 5 Expires: September 7, 2022 Microsoft 6 I. Bryskin 7 Individual 8 L. Contreras 9 Telefonica 10 Q. Wu 11 Huawei 12 S. Belotti 13 Nokia 14 R. Rokui 15 Ciena 16 March 6, 2022 18 IETF Network Slice YANG Data Model 19 draft-liu-teas-transport-network-slice-yang-05 21 Abstract 23 This document describes a YANG data model for managing and 24 controlling IETF network slices, defined in 25 [I-D.ietf-teas-ietf-network-slices]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 7, 2022. 44 Copyright Notice 46 Copyright (c) 2022 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Modeling Considerations . . . . . . . . . . . . . . . . . . . 4 65 2.1. Relationships to Related Topology Models . . . . . . . . 4 66 2.2. Network Slice with TE . . . . . . . . . . . . . . . . . . 5 67 2.3. ACTN for Network Slicing . . . . . . . . . . . . . . . . 6 68 3. Model Applicability . . . . . . . . . . . . . . . . . . . . . 6 69 3.1. Network Slicing by Virtualization . . . . . . . . . . . . 7 70 3.2. Network Slicing by TE Overlay . . . . . . . . . . . . . . 9 71 4. Model Communication Types . . . . . . . . . . . . . . . . . . 11 72 4.1. P2P . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 4.2. P2MP . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 4.3. MP2MP . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 4.4. A2A . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 5. Model Tree Structure . . . . . . . . . . . . . . . . . . . . 16 77 5.1. Module ietf-network-slice . . . . . . . . . . . . . . . . 16 78 5.2. Module ietf-network-slice-connectivity . . . . . . . . . 17 79 6. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 17 80 6.1. Module ietf-network-slice . . . . . . . . . . . . . . . . 17 81 6.2. Module ietf-network-slice-connectivity . . . . . . . . . 23 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 84 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 86 10.1. Normative References . . . . . . . . . . . . . . . . . . 29 87 10.2. Informative References . . . . . . . . . . . . . . . . . 30 88 Appendix A. Data Tree for the Example in Section 3.1. . . . . . 32 89 A.1. Native Topology . . . . . . . . . . . . . . . . . . . . . 32 90 A.2. Network Slice Blue . . . . . . . . . . . . . . . . . . . 36 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 93 1. Introduction 95 This document defines a YANG [RFC7950] data model for for 96 representing, managing, and controlling IETF network slices, defined 97 in [I-D.ietf-teas-ietf-network-slices] 99 The defined data model is an interface between customers and 100 providers for configurations and state retrievals, so as to support 101 network slicing as a service. Through this model, a customer can 102 learn the slicing capabilities and the available resources of the 103 provider. A customer can request or negotiate with a network slicing 104 provider to create an instance. The customer can incrementally 105 update its requirements on individual topology elements in the slice 106 instance, and retrieve the operational states of these elements. 107 With the help of other mechanisms and data models defined in IETF, 108 the telemetry information can be published to the customer. 110 As described in Section 3 of 111 [I-D.contreras-teas-slice-controller-models], the data model defined 112 in this document complements the data model defined in 113 [I-D.ietf-teas-ietf-network-slice-nbi-yang]. In addition to the 114 provider's view, the data model defined in this document models the 115 Type 2 service defined in [RFC8453]. 117 The YANG data model in this document conforms to the Network 118 Management Datastore Architecture (NMDA) [RFC8342]. 120 1.1. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 124 "OPTIONAL" in this document are to be interpreted as described in BCP 125 14, [RFC2119] [RFC8174] when, and only when, they appear in all 126 capitals, as shown here. 128 The following terms are defined in [RFC7950] and are not redefined 129 here: 131 o augment 133 o data model 135 o data node 137 1.2. Tree Diagrams 139 Tree diagrams used in this document follow the notation defined in 140 [RFC8340]. 142 2. Modeling Considerations 144 An IETF network slice is modeled as network topology defined in 145 [RFC8345], with augmentations. A new network type "network-slice" is 146 defined in this document. When a network topology data instance 147 contains the network-slice network type, it represents an instance of 148 an IETF network slice. 150 2.1. Relationships to Related Topology Models 152 There are several related YANG data models that have been defined in 153 IETF. Some of these are: 155 Network Topology Model: 156 Defined in [RFC8345]. 158 OTN Topology Model: 159 Defined in [I-D.ietf-ccamp-otn-topo-yang]. 161 L2 Topology Model: 162 Defined in [I-D.ietf-i2rs-yang-l2-network-topology]. 164 L3 Topology Model: 165 Defined in [RFC8346]. 167 TE Topology Model: 168 Defined in [RFC8795]. 170 Figure 1 shows the relationships among these models. The box of 171 dotted lines denotes the model defined in this document. 173 +-------------------------+ 174 | | 175 | Network Topology Model | 176 | RFC 8345 | 177 +------------^------------+ 178 | 179 | augments 180 +--------------+------+-------+--------------+ 181 | | | | 182 | | | | 183 +-----^----+ +-----^----+ +-----^----+ ......^..... 184 | L2 | | L3 | | TE | : Network : 185 | Topology | | Topology | | Topology | : Slice : 186 | Model | | Model | | Model | : Model : 187 +----------+ +----------+ +-----^----+ '''''''''''' 188 | 189 | 190 +-----^----+ 191 | OTN | 192 | Topology | 193 | Model | 194 +----------+ 196 Figure 1: Model Relationships 198 2.2. Network Slice with TE 200 In many situations, an IETF network slide needs to have TE (Traffic 201 Engineering) capabilities to achieve certain network characteristics. 202 The TE Topology Model defined in [RFC8795] can be used to make an 203 IETF network slice TE capable. To achieve this, an IETF network 204 slice instance will be configured to have both "network-slice" and 205 "te-topology" network types, taking advantage of the multiple 206 inheritance capability featured by the network topology model 207 [RFC8345]. The following diagram shows their relations. 209 +---------------------+ +---------------------+ 210 | Network Slice | | TE Topology | 211 | ietf-network-slice | | ietf-te-topology | 212 +----------^----------+ +----------^----------+ 213 | inherits attributes from | 214 \ / 215 \ / 216 \ / 217 +--------------------------------------------------------+ 218 | Network Slice with TE | 219 +--------------------------------------------------------+ 220 | ietf-network-topology: | 221 | network-id (key) | 222 | network-types: { | 223 | network-slice{} | 224 | te-topology{} | 225 | } | 226 | | 227 +-----------------------------+--------------------------+ 228 | ietf-network-slice: | ietf-te-topology: | 229 | | | 230 +-----------------------------+--------------------------+ 232 Figure 2: Network Slice with TE 234 This method can be applied to other types of network topology models 235 too. For example, when a network topology instance is configured to 236 have the types of "network-slice" defined in this document, "te- 237 topology" defined in [RFC8795], and "l3-unicast-topology" defined in 238 [RFC8346], this network topology instance becomes an IETF network 239 slice instance that can perform layer 3 traffic engineering. 241 2.3. ACTN for Network Slicing 243 Since ACTN topology data models are based on the network topology 244 model defined in [RFC8345], the augmentations defined in this 245 document are effective augmentations to the ACTN topology data 246 models, resulting in making the ACTN framework [RFC8453] and data 247 models [I-D.ietf-teas-actn-yang] capable of slicing networks with the 248 required network characteristics. 250 3. Model Applicability 252 There are many technologies to achieve network slicing. The data 253 model defined in this document can be applied to a wide ranges of 254 cases. This section describes how this data model is applied to a 255 few cases. 257 3.1. Network Slicing by Virtualization 259 In the case shown in Figure 3, node virtualization is used to 260 separate and allocate resources in physical devices. Two virtual 261 routers VR1 and VR2 are created over physical router R1. Each of the 262 virtual routers takes a portion of the resources such as ports and 263 memory in the physical router. Depending on the requirements and the 264 implementations, they may share certain resources such as processors, 265 ASICs, and switch fabric. 267 As an example, Appendix A. shows the JSON encoded data instances of 268 the native topology and the customized topology for Network Slice 269 Blue. 271 Customer Topology Customer Topology 272 Network Slice Blue Network Slice Red 273 +---+ +---+ +---+ 274 -----|R3 |--- ---|R2 |------|R3 | 275 / +---+ +---+ +---+ 276 +---+ +---+ \ +---+ 277 ---|R1 |------|R2 | -----|R4 |--- 278 +---+ +---+ +---+ 280 Customers 281 --------------------------------------------------------------------- 282 Provider 284 Customized Topology 285 Provider Network with Virtual Devices 287 Network Slice Blue: VR1, VR3, VR5 +---+ 288 ----------|VR5|------ 289 / +---+ 290 +---+ +---+ 291 ------|VR1|---------|VR3| 292 +---+ +---+ 293 ------|VR2|---------|VR4| 294 +---+ +---+ 295 \ +---+ 296 ----------|VR6|------ 297 Network Slice Red: VR2, VR4, VR6 +---+ 299 Virtual Devices 300 --------------------------------------------------------------------- 301 Physical Devices 303 Native Topology 304 Provider Network with Physical Devices 305 +---+ 306 ----------|R3 |------ 307 / +---+ 308 +---+ +---+ 309 ======|R1 |=========|R2 | 310 +---+ +---+ 311 \ +---+ 312 ----------|R4 |------ 313 +---+ 315 Figure 3: Network Slicing by Virtualization 317 3.2. Network Slicing by TE Overlay 319 Figure 4 shows a case where TE (Traffic Engineering) overlay is 320 applied to achieve logically separated customer IETF network slices. 321 In the underlay TE capable network, TE tunnels are established to 322 support the TE links in the overlay network. These links and tunnels 323 maintain the characteristics required by the customers. The provider 324 selects the proper logical nodes and links in the overlay network, 325 assigns them to specific IETF network slices, and uses the data model 326 defined in this document to send the results to the customers. 328 Customer Topology Customer Topology 329 Network Slice Blue Network Slice Red 330 +---+ +---+ +---+ 331 -----|R3 |--- ---|R1 |------|R2 | 332 / +---+ +---+ +---+ 333 +---+ +---+ \ +---+ 334 ---|R1 |------|R2 | -----|R4 |--- 335 +---+ +---+ +---+ 337 Customers 338 --------------------------------------------------------------------- 339 Provider 341 Customized Topology 342 Provider Network with TE Isolation 344 Network Slice Blue: R1, R2, R3 345 +---+ 346 ----------|R3 |------ 347 / +---+ 348 +---+ +---+ 349 ======|R1 |=========|R2 | 350 +---+ +---+ 351 \ +---+ 352 ----------|R4 |------ 353 +---+ 354 Network Slice Red: R1, R2, R4 356 Overlay 357 --------------------------------------------------------------------- 358 Underlay 360 Native Topology 361 Provider Network with TE Tunnels 362 +---+ 363 TE Tunnel for Network Slice Blue ----------|R3 |------ 364 @@@@@@@@@@@@@@ / +---+ 365 +---+ +---+ +---+ 366 ======|R1 |--|R5 |--|R2 | 367 +---+ +---+ +---+ 368 ############## \ +---+ 369 TE Tunnel for Network Slice Red ----------|R4 |------ 370 +---+ 372 Figure 4: Network Slicing by TE Overlay 374 4. Model Communication Types 376 Section 3.2 of [I-D.ietf-teas-ietf-network-slices] describes various 377 communication types that an IETF network slice may serve, including 378 P2P, P2MP, MP2P, MP2MP, and A2A. The data models specified in 379 [RFC8345] and [RFC8795] support only P2P and A2A. In this document, 380 the YANG module ietf-network-slice-connectivity is defined to extend 381 the capabilities to cover P2MP, MP2P, and MP2MP. 383 The YANG module ietf-network-slice-connectivity is defined in 384 Section 6.2 of this document, with its structure shown in Section 5.2 385 of this document. This YANG module introduces two modeling 386 constructs in each connectivity construct (that is called 387 connectivity matrix entries in [RFC8795]): 389 Replication Group: 390 A replication group contains a list of connectivity constructs 391 (that are called connectivity matrix entries in RFC 8795). When 392 traffic is sent to one entry in this replication group, the 393 traffic is replicated to all other entries in the same replication 394 group. 396 Receiver Constraint Group: 397 A receiver constraint group contains a list of connectivity 398 constructs (that are called connectivity matrix entries in RFC 399 8795). When traffic is sent to one or more entries in this 400 receiver constraint group, the constraints specified in this 401 receiver constraint group are applied to the receiver-side 402 termination points referenced by all entries in this receiver 403 constraint group. 405 The following sections describe some data examples: 407 4.1. P2P 408 NSE3 <-> NSC7 : Bidirectional P2P connectivity 409 NSE4 -> NSE8 : Unidirectional P2P connectivity 411 { 412 "connectivity-matrices": { 413 "connectivity-matrix": [ 414 "id": 1, 415 "from": { 416 "tp-ref": "NSE3" 417 }, 418 "to": { 419 "tp-ref": "NSE7" 420 } 421 ], 422 "connectivity-matrix": [ 423 "id": 2, 424 "from": { 425 "tp-ref": "NSE7" 426 }, 427 "to": { 428 "tp-ref": "NSE3" 429 } 430 ], 431 "connectivity-matrix": [ 432 "id": 3, 433 "from": { 434 "tp-ref": "NSE4" 435 }, 436 "to": { 437 "tp-ref": "NSE8" 438 } 439 ] 440 } 441 } 443 4.2. P2MP 444 NSE5 -> {NSC9, NSE10} 445 { 446 "connectivity-matrices": { 447 "connectivity-matrix": [ 448 "id": 1, 449 "from": { 450 "tp-ref": "NSE5" 451 }, 452 "to": { 453 "tp-ref": "NSE9" 454 } 455 ], 456 "connectivity-matrix": [ 457 "id": 2, 458 "from": { 459 "tp-ref": "NSE5" 460 }, 461 "to": { 462 "tp-ref": "NSE10" 463 } 464 ], 465 "replication-group": [ 466 "id": 1, 467 "entry": [1, 2] 468 ] 469 } 470 } 472 4.3. MP2MP 474 {NSE14, NSE15} -> {NSE16, NSE17} 476 { 477 "connectivity-matrices": { 478 "connectivity-matrix": [ 479 "id": 1, 480 "from": { 481 "tp-ref": "NSE14" 482 }, 483 "to": { 484 "tp-ref": "NSE16" 485 } 486 ], 487 "connectivity-matrix": [ 488 "id": 2, 489 "from": { 490 "tp-ref": "NSE14" 491 }, 492 "to": { 493 "tp-ref": "NSE17" 494 } 495 ], 496 "connectivity-matrix": [ 497 "id": 3, 498 "from": { 499 "tp-ref": "NSE15" 500 }, 501 "to": { 502 "tp-ref": "NSE16" 503 } 504 ], 505 "connectivity-matrix": [ 506 "id": 4, 507 "from": { 508 "tp-ref": "NSE15" 509 }, 510 "to": { 511 "tp-ref": "NSE17" 512 } 513 ], 514 "replication-group": [ 515 "id": 1, 516 "entry": [1, 2] 517 ], 518 "replication-group": [ 519 "id": 2, 520 "entry": [3, 4] 521 ], 522 "receiver-constraint-group": [ 523 "id": 1, 524 "entry": [1, 3] 525 ], 526 "receiver-constraint-group": [ 527 "id": 2, 528 "entry": [2, 4] 529 ] 530 } 531 } 533 4.4. A2A 535 {NSE1, NSE2, NSE6} -> {NSE1, NSE2, NSE6} 537 { 538 "connectivity-matrices": { 539 "connectivity-matrix": [ 540 "id": 1, 541 "from": { 542 "tp-ref": "NSE1" 543 }, 544 "to": { 545 "tp-ref": "NSE2" 546 } 547 ], 548 "connectivity-matrix": [ 549 "id": 2, 550 "from": { 551 "tp-ref": "NSE1" 552 }, 553 "to": { 554 "tp-ref": "NSE6" 555 } 556 ], 557 "connectivity-matrix": [ 558 "id": 3, 559 "from": { 560 "tp-ref": "NSE2" 561 }, 562 "to": { 563 "tp-ref": "NSE1" 564 } 565 ], 566 "connectivity-matrix": [ 567 "id": 4, 568 "from": { 569 "tp-ref": "NSE2" 570 }, 571 "to": { 572 "tp-ref": "NSE6" 573 } 574 ], 575 "connectivity-matrix": [ 576 "id": 5, 577 "from": { 578 "tp-ref": "NSE6" 579 }, 580 "to": { 581 "tp-ref": "NSE1" 582 } 583 ], 584 "connectivity-matrix": [ 585 "id": 6, 586 "from": { 587 "tp-ref": "NSE6" 588 }, 589 "to": { 590 "tp-ref": "NSE2" 591 } 592 ] 593 } 594 } 596 5. Model Tree Structure 598 5.1. Module ietf-network-slice 600 TODO - Complete IETF network slice attributes that are technology- 601 agnostic and common to all use cases. 603 module: ietf-network-slice 604 augment /nw:networks/nw:network/nw:network-types: 605 +--rw network-slice! 606 augment /nw:networks/nw:network: 607 +--rw network-slice 608 +--rw optimization-criterion? identityref 609 +--rw delay-tolerance? boolean 610 +--rw periodicity* uint64 611 +--rw isolation-level? identityref 612 augment /nw:networks/nw:network/nw:node: 613 +--rw network-slice 614 +--rw isolation-level? identityref 615 +--rw compute-node-id? string 616 +--rw storage-id? string 617 augment /nw:networks/nw:network/nt:link: 618 +--rw network-slice 619 +--rw delay-tolerance? boolean 620 +--rw periodicity* uint64 621 +--rw isolation-level? identityref 623 5.2. Module ietf-network-slice-connectivity 625 module: ietf-network-slice-connectivity 626 augment /nw:networks/nw:network/nw:node/tet:te 627 /tet:te-node-attributes/tet:connectivity-matrices 628 /tet:connectivity-matrix: 629 +--rw replication-group* [id] 630 | +--rw id uint32 631 | +--rw entry* -> ../../tet:id 632 +--rw receiver-constraint-group* [id] 633 +--rw id uint32 634 +--rw entry* -> ../../tet:id 635 +--rw te-bandwidth 636 +--rw (technology)? 637 +--:(generic) 638 +--rw generic? te-bandwidth 639 augment /nw:networks/nw:network/nw:node/tet:te 640 /tet:information-source-entry/tet:connectivity-matrices 641 /tet:connectivity-matrix: 642 +--ro replication-group* [id] 643 | +--ro id uint32 644 | +--ro entry* -> ../../tet:id 645 +--ro receiver-constraint-group* [id] 646 +--ro id uint32 647 +--ro entry* -> ../../tet:id 648 +--ro te-bandwidth 649 +--ro (technology)? 650 +--:(generic) 651 +--ro generic? te-bandwidth 653 6. YANG Modules 655 6.1. Module ietf-network-slice 657 This module references [RFC8345], [RFC8776], and [GSMA-NS-Template] 659 file "ietf-network-slice@2020-11-01.yang" 660 module ietf-network-slice { 661 yang-version 1.1; 662 namespace "urn:ietf:params:xml:ns:yang:ietf-network-slice"; 663 prefix "ns"; 665 import ietf-network { 666 prefix "nw"; 667 reference "RFC 8345: A YANG Data Model for Network Topologies"; 669 } 670 import ietf-network-topology { 671 prefix "nt"; 672 reference "RFC 8345: A YANG Data Model for Network Topologies"; 673 } 674 import ietf-te-types { 675 prefix "te-types"; 676 reference 677 "RFC 8776: Traffic Engineering Common YANG Types"; 678 } 680 organization 681 "IETF Traffic Engineering Architecture and Signaling (TEAS) 682 Working Group"; 684 contact 685 "WG Web: 686 WG List: 688 Editor: Xufeng Liu 689 691 Editor: Jeff Tantsura 692 694 Editor: Igor Bryskin 695 697 Editor: Luis Miguel Contreras Murillo 698 700 Editor: Qin Wu 701 703 Editor: Sergio Belotti 704 706 Editor: Reza Rokui 707 708 "; 710 description 711 "YANG data model for representing and managing network 712 slices. 714 Copyright (c) 2020 IETF Trust and the persons identified as 715 authors of the code. All rights reserved. 717 Redistribution and use in source and binary forms, with or 718 without modification, is permitted pursuant to, and subject to 719 the license terms contained in, the Simplified BSD License set 720 forth in Section 4.c of the IETF Trust's Legal Provisions 721 Relating to IETF Documents 722 (http://trustee.ietf.org/license-info). 724 This version of this YANG module is part of RFC XXXX; see the 725 RFC itself for full legal notices."; 727 revision 2020-11-01 { 728 description "Initial revision"; 729 reference 730 "RFC XXXX: YANG Data Model for Network Slices"; 731 } 733 /* 734 * Identities 735 */ 736 identity isolation-level { 737 description 738 "Base identity for the isolation-level."; 739 reference 740 "GSMA-NS-Template: Generic Network Slice Template, 741 Version 3.0."; 742 } 743 identity no-isolation { 744 base isolation-level; 745 description 746 "Network slices are not separated."; 747 } 748 identity physical-isolation { 749 base isolation-level; 750 description 751 "Network slices are physically separated (e.g. different rack, 752 different hardware, different location, etc.)."; 753 } 754 identity logical-isolation { 755 base isolation-level; 756 description 757 "Network slices are logically separated."; 758 } 759 identity process-isolation { 760 base physical-isolation; 761 description 762 "Process and threads isolation."; 763 } 764 identity physical-memory-isolation { 765 base physical-isolation; 766 description 767 "Process and threads isolation."; 768 } 769 identity physical-network-isolation { 770 base physical-isolation; 771 description 772 "Process and threads isolation."; 773 } 774 identity virtual-resource-isolation { 775 base logical-isolation; 776 description 777 "A network slice has access to specific range of resources 778 that do not overlap with other network slices 779 (e.g. VM isolation)."; 780 } 781 identity network-functions-isolation { 782 base logical-isolation; 783 description 784 "NF (Network Function) is dedicated to the network slice, but 785 virtual resources are shared."; 786 } 787 identity service-isolation { 788 base logical-isolation; 789 description 790 "NSC data are isolated from other NSCs, but virtual 791 resources and NFs are shared."; 792 } 794 /* 795 * Groupiings 796 */ 797 grouping network-slice-topology-attributes { 798 description "Network Slice topology scope attributes."; 799 container network-slice { 800 description 801 "Containing Network Slice attributes."; 802 leaf optimization-criterion { 803 type identityref { 804 base te-types:objective-function-type; 805 } 806 description 807 "Optimization criterion applied to this topology."; 808 } 809 leaf delay-tolerance { 810 type boolean; 811 description 812 "'true' if is not too critical how long it takes to deliver 813 the amount of data."; 814 reference 815 "GSMA-NS-Template: Generic Network Slice Template, 816 Version 3.0."; 817 } 818 leaf-list periodicity { 819 type uint64; 820 units seconds; 821 description 822 "A list of periodicities supported by the network slice."; 823 reference 824 "GSMA-NS-Template: Generic Network Slice Template, 825 Version 3.0."; 826 } 827 leaf isolation-level { 828 type identityref { 829 base isolation-level; 830 } 831 description 832 "A network slice instance may be fully or partly, logically 833 and/or physically, isolated from another network slice 834 instance. This attribute describes different types of 835 isolation:"; 836 } 837 } // network-slice 838 } // network-slice-topology-attributes 840 grouping network-slice-node-attributes { 841 description "Network Slice node scope attributes."; 842 container network-slice { 843 description 844 "Containing Network Slice attributes."; 845 leaf isolation-level { 846 type identityref { 847 base isolation-level; 848 } 849 description 850 "A network slice instance may be fully or partly, logically 851 and/or physically, isolated from another network slice 852 instance. This attribute describes different types of 853 isolation:"; 854 } 855 leaf compute-node-id { 856 type string; 857 description 858 "Reference to a compute node instance specified in 859 a data model specifying the computing resources."; 860 } 861 leaf storage-id { 862 type string; 863 description 864 "Reference to a storage instance specified in 865 a data model specifying the storage resources."; 866 } 867 } // network-slice 868 } // network-slice-node-attributes 870 grouping network-slice-link-attributes { 871 description "Network Slice link scope attributes"; 872 container network-slice { 873 description 874 "Containing Network Slice attributes."; 875 leaf delay-tolerance { 876 type boolean; 877 description 878 "'true' if is not too critical how long it takes to deliver 879 the amount of data."; 880 reference 881 "GSMA-NS-Template: Generic Network Slice Template, 882 Version 3.0."; 883 } 884 leaf-list periodicity { 885 type uint64; 886 units seconds; 887 description 888 "A list of periodicities supported by the network slice."; 889 reference 890 "GSMA-NS-Template: Generic Network Slice Template, 891 Version 3.0."; 892 } 893 leaf isolation-level { 894 type identityref { 895 base isolation-level; 896 } 897 description 898 "A network slice instance may be fully or partly, logically 899 and/or physically, isolated from another network slice 900 instance. This attribute describes different types of 901 isolation:"; 902 } 903 } // network-slice 904 } // network-slice-link-attributes 906 /* 907 * Data nodes 908 */ 910 augment "/nw:networks/nw:network/nw:network-types" { 911 description 912 "Defines the Network Slice topology type."; 913 container network-slice { 914 presence "Indicates Network Slice topology"; 915 description 916 "Its presence identifies the Network Slice type."; 917 } 918 } 920 augment "/nw:networks/nw:network" { 921 when "nw:network-types/ns:network-slice" { 922 description "Augment only for Network Slice topology."; 923 } 924 description "Augment topology configuration and state."; 925 uses network-slice-topology-attributes; 926 } 928 augment "/nw:networks/nw:network/nw:node" { 929 when "../nw:network-types/ns:network-slice" { 930 description "Augment only for Network Slice topology."; 931 } 932 description "Augment node configuration and state."; 933 uses network-slice-node-attributes; 934 } 936 augment "/nw:networks/nw:network/nt:link" { 937 when "../nw:network-types/ns:network-slice" { 938 description "Augment only for Network Slice topology."; 939 } 940 description "Augment link configuration and state."; 941 uses network-slice-link-attributes; 942 } 944 } 945 947 6.2. Module ietf-network-slice-connectivity 949 This module references [RFC8345], [RFC8776], and [RFC8795] 951 file "ietf-network-slice-connectivity@2022-03-04.yang" 952 module ietf-network-slice-connectivity { 953 yang-version 1.1; 954 namespace "urn:ietf:params:xml:ns:yang:" 955 + "ietf-network-slice-connectivity"; 956 prefix "ns-con-types"; 958 import ietf-network { 959 prefix "nw"; 960 reference "RFC 8345: A YANG Data Model for Network Topologies"; 961 } 962 import ietf-te-topology { 963 prefix "tet"; 964 reference 965 "RFC 8795: YANG Data Model for Traffic Engineering (TE) 966 Topologies"; 967 } 968 import ietf-te-types { 969 prefix "te-types"; 970 reference 971 "RFC 8776: Traffic Engineering Common YANG Types"; 972 } 974 organization 975 "IETF Traffic Engineering Architecture and Signaling (TEAS) 976 Working Group"; 978 contact 979 "WG Web: 980 WG List: 982 Editor: Xufeng Liu 983 985 Editor: Luis Miguel Contreras Murillo 986 988 Editor: Sergio Belotti 989 990 "; 992 description 993 "YANG augmentations to support various connectivity types for 994 IETF network slices. 996 Copyright (c) 2022 IETF Trust and the persons identified as 997 authors of the code. All rights reserved. 999 Redistribution and use in source and binary forms, with or 1000 without modification, is permitted pursuant to, and subject to 1001 the license terms contained in, the Simplified BSD License set 1002 forth in Section 4.c of the IETF Trust's Legal Provisions 1003 Relating to IETF Documents 1004 (http://trustee.ietf.org/license-info). 1006 This version of this YANG module is part of RFC XXXX; see the 1007 RFC itself for full legal notices."; 1009 revision 2022-03-04 { 1010 description "Initial revision"; 1011 reference 1012 "RFC XXXX: YANG Data Model for Network Slices"; 1013 } 1015 /* 1016 * Groupiings 1017 */ 1018 grouping network-slice-connectivity-types { 1019 description "Network Slice topology scope attributes."; 1020 list replication-group { 1021 key "id"; 1022 description 1023 "A list of replication groups. Each replication group 1024 contains a list of connectivity constructs 1025 (that are called connectivity matrix entries in RFC 8795). 1026 When traffic is sent to one entry in this replication group, 1027 the traffic is replicated to all other entries in the same 1028 replication group."; 1029 leaf id { 1030 type uint32; 1031 description 1032 "Identifies the replication group."; 1033 } 1034 leaf-list entry { 1035 type leafref { 1036 path "../../tet:id"; 1037 } 1038 description 1039 "References a connectivity matrix entry that belongs to 1040 this replication group."; 1041 } 1042 } 1043 list receiver-constraint-group { 1044 key "id"; 1045 description 1046 "A list of receiver constraint groups. Each receiver 1047 constraint group contains a list of connectivity constructs 1048 (that are called connectivity matrix entries in RFC 8795). 1049 When traffic is sent to one or more entries in this 1050 receiver constraint group, the constraints specified in this 1051 receiver constraint group are applied to the receiver-side 1052 termination points referenced by all entries in this 1053 receiver constraint group."; 1054 leaf id { 1055 type uint32; 1056 description 1057 "Identifies the receiver constraint group."; 1058 } 1059 leaf-list entry { 1060 type leafref { 1061 path "../../tet:id"; 1062 } 1063 description 1064 "References a connectivity matrix entry that belongs to 1065 this receiver constraint group.."; 1066 } 1067 uses te-types:te-bandwidth; 1068 } 1069 } 1071 /* 1072 * Data nodes 1073 */ 1074 augment "/nw:networks/nw:network/nw:node/tet:te/" 1075 + "tet:te-node-attributes/tet:connectivity-matrices/" 1076 + "tet:connectivity-matrix" { 1077 description "Augment node configuration and state."; 1078 uses network-slice-connectivity-types; 1079 } 1081 augment "/nw:networks/nw:network/nw:node/tet:te/" 1082 + "tet:information-source-entry/tet:connectivity-matrices/" 1083 + "tet:connectivity-matrix" { 1084 description "Augment node configuration and state."; 1085 uses network-slice-connectivity-types; 1086 } 1087 } 1088 1090 7. IANA Considerations 1092 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 1093 actual RFC number (and remove this note). 1095 This document registers the following namespace URIs in the IETF XML 1096 registry [RFC3688]: 1098 -------------------------------------------------------------------- 1099 URI: urn:ietf:params:xml:ns:yang:ietf-network-slice 1100 Registrant Contact: The IESG. 1101 XML: N/A, the requested URI is an XML namespace. 1102 -------------------------------------------------------------------- 1104 This document registers the following YANG modules in the YANG Module 1105 Names registry [RFC6020]: 1107 -------------------------------------------------------------------- 1108 name: ietf-l3-te-topology 1109 namespace: urn:ietf:params:xml:ns:yang:ietf-network-slice 1110 prefix: ns 1111 reference: RFC XXXX 1112 -------------------------------------------------------------------- 1114 8. Security Considerations 1116 The YANG module specified in this document defines a schema for data 1117 that is designed to be accessed via network management protocols such 1118 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1119 is the secure transport layer, and the mandatory-to-implement secure 1120 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1121 is HTTPS, and the mandatory-to-implement secure transport is TLS 1122 [RFC8446]. 1124 The Network Configuration Access Control Model (NACM) [RFC8341] 1125 provides the means to restrict access for particular NETCONF or 1126 RESTCONF users to a preconfigured subset of all available NETCONF or 1127 RESTCONF protocol operations and content. 1129 There are a number of data nodes defined in this YANG module that are 1130 writable/creatable/deletable (i.e., config true, which is the 1131 default). These data nodes may be considered sensitive or vulnerable 1132 in some network environments. Write operations (e.g., edit-config) 1133 to these data nodes without proper protection can have a negative 1134 effect on network operations. These are the subtrees and data nodes 1135 and their sensitivity/vulnerability: 1137 /nw:networks/nw:network/nw:network-types/ns:network-slice 1138 This subtree specifies the network slice type. Modifying the 1139 configurations can make network slice type invalid and cause 1140 interruption to IETF network slices. 1142 /nw:networks/nw:network/ns:network-slice 1143 This subtree specifies the topology-wide configurations. 1144 Modifying the configurations here can cause traffic 1145 characteristics changed in this IETF network slice and related 1146 networks. 1148 /nw:networks/nw:network/nw:node/ns:network-slice 1149 This subtree specifies the configurations of the nodes in a IETF 1150 network slice. Modifying the configurations in this subtree can 1151 change the traffic characteristics on this node and the related 1152 networks. 1154 /nw:networks/nw:network/nt:link/ns:network-slice 1155 This subtree specifies the configurations of the links in a IETF 1156 network slice. Modifying the configurations in this subtree can 1157 change the traffic characteristics on this link and the related 1158 networks. 1160 Some of the readable data nodes in this YANG module may be considered 1161 sensitive or vulnerable in some network environments. It is thus 1162 important to control read access (e.g., via get, get-config, or 1163 notification) to these data nodes. These are the subtrees and data 1164 nodes and their sensitivity/vulnerability: 1166 /nw:networks/nw:network/nw:network-types/ns:network-slice 1167 Unauthorized access to this subtree can disclose the network slice 1168 type. 1170 /nw:networks/nw:network/ns:network-slice 1171 Unauthorized access to this subtree can disclose the topology-wide 1172 states. 1174 /nw:networks/nw:network/nw:node/ns:network-slice 1175 Unauthorized access to this subtree can disclose the operational 1176 state information of the nodes in a IETF network slice. 1178 /nw:networks/nw:network/nt:link/ns:network-slic 1179 Unauthorized access to this subtree can disclose the operational 1180 state information of the links in a IETF network slice. 1182 9. Acknowledgements 1184 The TEAS Network Slicing Design Team (NSDT) members included Aijun 1185 Wang, Dong Jie, Eric Gray, Jari Arkko, Jeff Tantsura, John E Drake, 1186 Luis M. Contreras, Rakesh Gandhi, Ran Chen, Reza Rokui, Ricard 1187 Vilalta, Ron Bonica, Sergio Belotti, Tomonobu Niwa, Xuesong Geng, and 1188 Xufeng Liu. 1190 10. References 1192 10.1. Normative References 1194 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1195 Requirement Levels", BCP 14, RFC 2119, 1196 DOI 10.17487/RFC2119, March 1997, 1197 . 1199 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1200 DOI 10.17487/RFC3688, January 2004, 1201 . 1203 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1204 the Network Configuration Protocol (NETCONF)", RFC 6020, 1205 DOI 10.17487/RFC6020, October 2010, 1206 . 1208 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1209 and A. Bierman, Ed., "Network Configuration Protocol 1210 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1211 . 1213 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1214 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1215 . 1217 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1218 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1219 . 1221 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1222 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1223 . 1225 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1226 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1227 May 2017, . 1229 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1230 Access Control Model", STD 91, RFC 8341, 1231 DOI 10.17487/RFC8341, March 2018, 1232 . 1234 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1235 and R. Wilton, "Network Management Datastore Architecture 1236 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1237 . 1239 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 1240 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 1241 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 1242 2018, . 1244 [RFC8346] Clemm, A., Medved, J., Varga, R., Liu, X., 1245 Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model 1246 for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346, 1247 March 2018, . 1249 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1250 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1251 . 1253 [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 1254 "Common YANG Data Types for Traffic Engineering", 1255 RFC 8776, DOI 10.17487/RFC8776, June 2020, 1256 . 1258 [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1259 O. Gonzalez de Dios, "YANG Data Model for Traffic 1260 Engineering (TE) Topologies", RFC 8795, 1261 DOI 10.17487/RFC8795, August 2020, 1262 . 1264 [GSMA-NS-Template] 1265 GSM Association, "Generic Network Slice Template, Version 1266 3.0", NG.116, May 2020. 1268 [I-D.ietf-teas-ietf-network-slices] 1269 Farrel, A., Drake, J., Rokui, R., Homma, S., Makhijani, 1270 K., Contreras, L. M., and J. Tantsura, "Framework for IETF 1271 Network Slices", draft-ietf-teas-ietf-network-slices-07 1272 (work in progress), March 2022. 1274 10.2. Informative References 1276 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 1277 RFC 7951, DOI 10.17487/RFC7951, August 2016, 1278 . 1280 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1281 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1282 . 1284 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 1285 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 1286 DOI 10.17487/RFC8453, August 2018, 1287 . 1289 [I-D.ietf-ccamp-otn-topo-yang] 1290 Zheng, H., Busi, I., Liu, X., Belotti, S., and O. G. D. 1291 Dios, "A YANG Data Model for Optical Transport Network 1292 Topology", draft-ietf-ccamp-otn-topo-yang-13 (work in 1293 progress), July 2021. 1295 [I-D.ietf-i2rs-yang-l2-network-topology] 1296 Dong, J., Wei, X., Wu, Q., Boucadair, M., and A. Liu, "A 1297 YANG Data Model for Layer 2 Network Topologies", draft- 1298 ietf-i2rs-yang-l2-network-topology-18 (work in progress), 1299 September 2020. 1301 [I-D.ietf-teas-actn-yang] 1302 Lee, Y., Zheng, H., Ceccarelli, D., Yoon, B. Y., and S. 1303 Belotti, "Applicability of YANG models for Abstraction and 1304 Control of Traffic Engineered Networks", draft-ietf-teas- 1305 actn-yang-08 (work in progress), September 2021. 1307 [I-D.ietf-teas-ietf-network-slice-nbi-yang] 1308 Wu, B., Dhody, D., Rokui, R., Saad, T., and L. Han, "IETF 1309 Network Slice Service YANG Model", draft-ietf-teas-ietf- 1310 network-slice-nbi-yang-01 (work in progress), March 2022. 1312 [I-D.contreras-teas-slice-controller-models] 1313 Contreras, L. M., Rokui, R., Tantsura, J., Wu, B., Liu, 1314 X., Dhody, D., and S. Belloti, "IETF Network Slice 1315 Controller and its associated data models", draft- 1316 contreras-teas-slice-controller-models-02 (work in 1317 progress), March 2022. 1319 Appendix A. Data Tree for the Example in Section 3.1. 1321 A.1. Native Topology 1323 This section contains an example of an instance data tree in the JSON 1324 encoding [RFC7951]. The example instantiates "ietf-network" for the 1325 native topology depicted in Figure 3. 1327 { 1328 "ietf-network:networks": { 1329 "network": [ 1330 { 1331 "network-id":"example-native-topology", 1332 "network-types": { 1333 }, 1334 "node": [ 1335 { 1336 "node-id":"R1", 1337 "ietf-network-topology:termination-point": [ 1338 { 1339 "tp-id":"1-0-1" 1340 }, 1341 { 1342 "tp-id":"1-0-2" 1343 }, 1344 { 1345 "tp-id":"1-2-1" 1346 }, 1347 { 1348 "tp-id":"1-2-2" 1349 } 1350 ] 1351 }, 1352 { 1353 "node-id":"R2", 1354 "ietf-network-topology:termination-point": [ 1355 { 1356 "tp-id":"2-1-1" 1357 }, 1358 { 1359 "tp-id":"2-1-2" 1360 }, 1361 { 1362 "tp-id":"2-3-1" 1363 }, 1364 { 1365 "tp-id":"2-4-1" 1366 } 1368 ] 1369 }, 1370 { 1371 "node-id":"R3", 1372 "ietf-network-topology:termination-point": [ 1373 { 1374 "tp-id":"3-0-1" 1375 }, 1376 { 1377 "tp-id":"3-2-1" 1378 } 1379 ] 1380 }, 1381 { 1382 "node-id":"R4", 1383 "ietf-network-topology:termination-point": [ 1384 { 1385 "tp-id":"4-0-1" 1386 }, 1387 { 1388 "tp-id":"4-2-1" 1389 } 1390 ] 1391 } 1392 ], 1393 "ietf-network-topology:link": [ 1394 { 1395 "link-id":"R1,1-0-1,,", 1396 "source": { 1397 "source-node":"R1", 1398 "source-tp":"1-0-1" 1399 } 1400 }, 1401 { 1402 "link-id":",,R1,1-0-1", 1403 "destination": { 1404 "dest-node":"R1", 1405 "dest-tp":"1-0-1" 1406 } 1407 }, 1408 { 1409 "link-id":"R1,1-0-2,,", 1410 "source": { 1411 "source-node":"R1", 1412 "source-tp":"1-0-2" 1413 } 1414 }, 1415 { 1416 "link-id":",,R1,1-0-2", 1417 "destination": { 1418 "dest-node":"R1", 1419 "dest-tp":"1-0-2" 1420 } 1421 }, 1422 { 1423 "link-id":"R1,1-2-1,R2,2-1-1", 1424 "source": { 1425 "source-node":"R1", 1426 "source-tp":"1-2-1" 1427 }, 1428 "destination": { 1429 "dest-node":"R2", 1430 "dest-tp":"2-1-1" 1431 } 1432 }, 1433 { 1434 "link-id":"R2,2-1-1,R1,1-2-1", 1435 "source": { 1436 "source-node":"R2", 1437 "source-tp":"2-1-1" 1438 }, 1439 "destination": { 1440 "dest-node":"R1", 1441 "dest-tp":"1-2-1" 1442 } 1443 }, 1444 { 1445 "link-id":"R1,1-2-2,R2,2-1-2", 1446 "source": { 1447 "source-node":"R1", 1448 "source-tp":"1-2-2" 1449 }, 1450 "destination": { 1451 "dest-node":"R2", 1452 "dest-tp":"2-1-2" 1453 } 1454 }, 1455 { 1456 "link-id":"R2,2-1-2,R1,1-2-2", 1457 "source": { 1458 "source-node":"R2", 1459 "source-tp":"2-1-2" 1460 }, 1461 "destination": { 1462 "dest-node":"R1", 1463 "dest-tp":"1-2-2" 1465 } 1466 }, 1467 { 1468 "link-id":"R2,2-3-1,R3,3-2-1", 1469 "source": { 1470 "source-node":"R2", 1471 "source-tp":"2-3-1" 1472 }, 1473 "destination": { 1474 "dest-node":"R3", 1475 "dest-tp":"3-2-1" 1476 } 1477 }, 1478 { 1479 "link-id":"R3,3-2-1,R2,2-3-1", 1480 "source": { 1481 "source-node":"R3", 1482 "source-tp":"3-2-1" 1483 }, 1484 "destination": { 1485 "dest-node":"R2", 1486 "dest-tp":"2-3-1" 1487 } 1488 }, 1489 { 1490 "link-id":"R2,2-4-1,R4,4-2-1", 1491 "source": { 1492 "source-node":"R2", 1493 "source-tp":"2-4-1" 1494 }, 1495 "destination": { 1496 "dest-node":"R4", 1497 "dest-tp":"4-2-1" 1498 } 1499 }, 1500 { 1501 "link-id":"R4,4-2-1,R2,2-4-1", 1502 "source": { 1503 "source-node":"R4", 1504 "source-tp":"4-2-1" 1505 }, 1506 "destination": { 1507 "dest-node":"R2", 1508 "dest-tp":"2-4-1" 1509 } 1510 }, 1511 { 1512 "link-id":"R3,3-0-1,,", 1513 "source": { 1514 "source-node":"R3", 1515 "source-tp":"3-0-1" 1516 } 1517 }, 1518 { 1519 "link-id":",,R3,3-0-1", 1520 "destination": { 1521 "dest-node":"R3", 1522 "dest-tp":"3-0-1" 1523 } 1524 }, 1525 { 1526 "link-id":"R4,4-0-1,,", 1527 "source": { 1528 "source-node":"R4", 1529 "source-tp":"4-0-1" 1530 } 1531 }, 1532 { 1533 "link-id":",,R4,4-0-1", 1534 "destination": { 1535 "dest-node":"R4", 1536 "dest-tp":"4-0-1" 1537 } 1538 } 1539 ] 1540 } 1541 ] 1542 } 1543 } 1545 A.2. Network Slice Blue 1547 This section contains an example of an instance data tree in the JSON 1548 encoding [RFC7951]. The example instantiates "ietf-network-slice" 1549 for the topology customized for Network Slice Blue depicted in 1550 Figure 3. 1552 { 1553 "ietf-network:networks": { 1554 "network": [ 1555 { 1556 "network-id":"example-customized-blue-topology", 1557 "network-types": { 1558 "ietf-network-slice:network-slice": { 1559 } 1560 }, 1561 "supporting-network": [ 1562 { 1563 "network-ref":"example-native-topology" 1564 } 1565 ], 1566 "node": [ 1567 { 1568 "node-id":"VR1", 1569 "supporting-node": [ 1570 { 1571 "network-ref":"example-native-topology", 1572 "node-ref":"R1" 1573 } 1574 ], 1575 "ietf-network-slice:network-slice": { 1576 "isolation-level": 1577 "ietf-network-slice:physical-memory-isolation" 1578 }, 1579 "ietf-network-topology:termination-point": [ 1580 { 1581 "tp-id":"1-0-1" 1582 }, 1583 { 1584 "tp-id":"1-3-1" 1585 } 1586 ] 1587 }, 1588 { 1589 "node-id":"VR3", 1590 "supporting-node": [ 1591 { 1592 "network-ref":"example-native-topology", 1593 "node-ref":"R2" 1594 } 1595 ], 1596 "ietf-network-slice:network-slice": { 1597 "isolation-level": 1598 "ietf-network-slice:physical-memory-isolation" 1599 }, 1600 "ietf-network-topology:termination-point": [ 1601 { 1602 "tp-id":"3-1-1" 1603 }, 1604 { 1605 "tp-id":"3-5-1" 1606 } 1608 ] 1609 }, 1610 { 1611 "node-id":"VR5", 1612 "supporting-node": [ 1613 { 1614 "network-ref":"example-native-topology", 1615 "node-ref":"R3" 1616 } 1617 ], 1618 "ietf-network-slice:network-slice": { 1619 "isolation-level": 1620 "ietf-network-slice:physical-memory-isolation" 1621 }, 1622 "ietf-network-topology:termination-point": [ 1623 { 1624 "tp-id":"5-3-1" 1625 }, 1626 { 1627 "tp-id":"5-0-1" 1628 } 1629 ] 1630 } 1631 ], 1632 "ietf-network-topology:link": [ 1633 { 1634 "link-id":"VR1,1-0-1,,", 1635 "source": { 1636 "source-node":"VR1", 1637 "source-tp":"1-0-1" 1638 }, 1639 "supporting-link": [ 1640 { 1641 "network-ref":"example-native-topology", 1642 "link-ref":"R1,1-0-1,," 1643 } 1644 ], 1645 "ietf-network-slice:network-slice": { 1646 "isolation-level": 1647 "ietf-network-slice:physical-network-isolation" 1648 } 1649 }, 1650 { 1651 "link-id":",,VR1,1-0-1", 1652 "destination": { 1653 "dest-node":"VR1", 1654 "dest-tp":"1-0-1" 1655 }, 1656 "supporting-link": [ 1657 { 1658 "network-ref":"example-native-topology", 1659 "link-ref":",,R1,1-0-1" 1660 } 1661 ], 1662 "ietf-network-slice:network-slice": { 1663 "isolation-level": 1664 "ietf-network-slice:physical-network-isolation" 1665 } 1666 }, 1667 { 1668 "link-id":"VR1,1-3-1,VR3,3-1-1", 1669 "source": { 1670 "source-node":"VR1", 1671 "source-tp":"1-3-1" 1672 }, 1673 "destination": { 1674 "dest-node":"VR3", 1675 "dest-tp":"3-1-1" 1676 }, 1677 "supporting-link": [ 1678 { 1679 "network-ref":"example-native-topology", 1680 "link-ref":"R1,1-2-1,R2,2-1-1" 1681 } 1682 ], 1683 "ietf-network-slice:network-slice": { 1684 "isolation-level": 1685 "ietf-network-slice:physical-network-isolation" 1686 } 1687 }, 1688 { 1689 "link-id":"VR3,3-1-1,VR1,1-3-1", 1690 "source": { 1691 "source-node":"VR3", 1692 "source-tp":"3-1-1" 1693 }, 1694 "destination": { 1695 "dest-node":"R1", 1696 "dest-tp":"1-3-1" 1697 }, 1698 "supporting-link": [ 1699 { 1700 "network-ref":"example-native-topology", 1701 "link-ref":"R2,2-1-1,R1,1-2-1" 1702 } 1703 ], 1704 "ietf-network-slice:network-slice": { 1705 "isolation-level": 1706 "ietf-network-slice:physical-network-isolation" 1707 } 1708 }, 1709 { 1710 "link-id":"VR3,3-5-1,VR5,5-3-1", 1711 "source": { 1712 "source-node":"VR3", 1713 "source-tp":"3-5-1" 1714 }, 1715 "destination": { 1716 "dest-node":"VR5", 1717 "dest-tp":"5-3-1" 1718 }, 1719 "supporting-link": [ 1720 { 1721 "network-ref":"example-native-topology", 1722 "link-ref":"R2,2-3-1,R3,3-2-1" 1723 } 1724 ], 1725 "ietf-network-slice:network-slice": { 1726 "isolation-level": 1727 "ietf-network-slice:physical-network-isolation" 1728 } 1729 }, 1730 { 1731 "link-id":"VR5,5-3-1,VR3,3-5-1", 1732 "source": { 1733 "source-node":"VR5", 1734 "source-tp":"5-3-1" 1735 }, 1736 "destination": { 1737 "dest-node":"VR3", 1738 "dest-tp":"3-5-1" 1739 }, 1740 "supporting-link": [ 1741 { 1742 "network-ref":"example-native-topology", 1743 "link-ref":"R3,3-2-1,R2,2-3-1" 1744 } 1745 ], 1746 "ietf-network-slice:network-slice": { 1747 "isolation-level": 1748 "ietf-network-slice:physical-network-isolation" 1749 } 1750 }, 1751 { 1752 "link-id":"VR5,5-0-1,,", 1753 "source": { 1754 "source-node":"VR5", 1755 "source-tp":"5-0-1" 1756 }, 1757 "supporting-link": [ 1758 { 1759 "network-ref":"example-native-topology", 1760 "link-ref":"R3,3-0-1,," 1761 } 1762 ], 1763 "ietf-network-slice:network-slice": { 1764 "isolation-level": 1765 "ietf-network-slice:physical-network-isolation" 1766 } 1767 }, 1768 { 1769 "link-id":",,VR5,5-0-1", 1770 "destination": { 1771 "dest-node":"VR5", 1772 "dest-tp":"5-0-1" 1773 }, 1774 "supporting-link": [ 1775 { 1776 "network-ref":"example-native-topology", 1777 "link-ref":",,R3,3-0-1" 1778 } 1779 ], 1780 "ietf-network-slice:network-slice": { 1781 "isolation-level": 1782 "ietf-network-slice:physical-network-isolation" 1783 } 1784 } 1785 ], 1786 "ietf-network-slice:network-slice": { 1787 "optimization-criterion": 1788 "ietf-te-types:of-minimize-cost-path", 1789 "isolation-level": 1790 "ietf-network-slice:physical-isolation" 1791 } 1792 } 1793 ] 1794 } 1795 } 1797 Authors' Addresses 1799 Xufeng Liu 1800 IBM Corporation 1802 EMail: xufeng.liu.ietf@gmail.com 1804 Jeff Tantsura 1805 Microsoft 1807 EMail: jefftant.ietf@gmail.com 1809 Igor Bryskin 1810 Individual 1812 EMail: i_bryskin@yahoo.com 1814 Luis Miguel Contreras Murillo 1815 Telefonica 1817 EMail: luismiguel.contrerasmurillo@telefonica.com 1819 Qin Wu 1820 Huawei 1822 EMail: bill.wu@huawei.com 1824 Sergio Belotti 1825 Nokia 1827 EMail: sergio.belotti@nokia.com 1829 Reza Rokui 1830 Ciena 1831 Canada 1833 EMail: rrokui@Ciena.com