idnits 2.17.1 draft-wd-teas-ietf-network-slice-nbi-yang-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 289 has weird spacing: '...ic-type ide...' == Line 293 has weird spacing: '...mber-id lea...' == Line 313 has weird spacing: '...ch-type ide...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (November 15, 2020) is 1257 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC6991' is defined on line 1383, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-nsdt-teas-ietf-network-slice-definition-01 ** Downref: Normative reference to an Informational draft: draft-nsdt-teas-ietf-network-slice-definition (ref. 'I-D.nsdt-teas-ietf-network-slice-definition') == Outdated reference: A later version (-05) exists of draft-nsdt-teas-ns-framework-04 ** Downref: Normative reference to an Informational draft: draft-nsdt-teas-ns-framework (ref. 'I-D.nsdt-teas-ns-framework') == Outdated reference: A later version (-05) exists of draft-geng-teas-network-slice-mapping-02 == Outdated reference: A later version (-24) exists of draft-ietf-teas-actn-vn-yang-10 == Outdated reference: A later version (-09) exists of draft-liu-teas-transport-network-slice-yang-02 Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Wu 3 Internet-Draft D. Dhody 4 Intended status: Standards Track Huawei Technologies 5 Expires: May 19, 2021 L. Han 6 China Mobile 7 R. Rokui 8 Nokia Canada 9 November 15, 2020 11 A Yang Data Model for IETF Network Slice NBI 12 draft-wd-teas-ietf-network-slice-nbi-yang-01 14 Abstract 16 This document provides a YANG data model for the IETF Network Slice 17 NBI (Northbound Interface). The model can be used by a higher level 18 system which is the IETF Network Slice consumer of an IETF Network 19 Slice Controller (NSC) to request, configure, and manage the 20 components of an IETF Network Slice. 22 The YANG modules in this document conforms to the Network Management 23 Datastore Architecture (NMDA) defined in RFC 8342. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 19, 2021. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions used in this document . . . . . . . . . . . . . . 3 61 2.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 62 3. IETF Network Slice NBI Model Usage . . . . . . . . . . . . . 4 63 4. IETF Network Slice NBI Model Overview . . . . . . . . . . . . 5 64 5. IETF Network Slice NBI Model Description . . . . . . . . . . 8 65 5.1. IETF Network Slice Connection Types . . . . . . . . . . . 8 66 5.2. IETF Network Slice Endpoint (NSE) . . . . . . . . . . . . 9 67 5.3. IETF Network Slice SLO . . . . . . . . . . . . . . . . . 9 68 6. IETF Network Slice Monitoring . . . . . . . . . . . . . . . . 11 69 7. IETF Network Slice NBI Module . . . . . . . . . . . . . . . . 11 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 72 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 74 11.1. Normative References . . . . . . . . . . . . . . . . . . 29 75 11.2. Informative References . . . . . . . . . . . . . . . . . 30 76 Appendix A. IETF Network Slice NBI Model Usage Example . . . . . 31 77 Appendix B. Comparison with Other Possible Design choices for 78 IETF Network Slice NBI . . . . . . . . . . . . . . . 33 79 B.1. ACTN VN Model Augmentation . . . . . . . . . . . . . . . 34 80 B.2. RFC8345 Augmentation Model . . . . . . . . . . . . . . . 34 81 Appendix C. Appendix B IETF Network Slice Match Criteria . . . . 35 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 84 1. Introduction 86 This document provides a YANG [RFC7950] data model for the IETF 87 Network Slice NBI. 89 The YANG model discussed in this document is defined based on the 90 description of the IETF Network Slice in 91 [I-D.nsdt-teas-ietf-network-slice-definition] and 92 [I-D.nsdt-teas-ns-framework], which is used to operate IETF Network 93 Slice during the IETF Network Slice instantiation, and the operations 94 includes modification, deletion, and monitoring. 96 The YANG model discussed in this document describes the requirements 97 of an IETF Network Slice that interconnects a set of IETF Network 98 Slice Endpoints from the point of view of the consumer, which is 99 classified as Customer Service Model in [RFC8309]. 101 It will be up to the management system or NSC (IETF Network Slice 102 controller) to take this model as an input and use other management 103 system or specific configuration models to configure the different 104 network elements to deliver an IETF Network Slice. The YANG models 105 can be used with network management protocols such as NETCONF 106 [RFC6241] or RESTCONF [RFC8040]. How the configuration of network 107 elements is done is out of scope for this document. 109 The IETF Network Slice operational state is included in the same tree 110 as the configuration consistent with Network Management Datastore 111 Architecture [RFC8342]. 113 2. Conventions used in this document 115 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described in 118 BCP14, [RFC2119], [RFC8174] when, and only when, they appear in all 119 capitals, as shown here. 121 The following terms are defined in [RFC6241] and are used in this 122 specification: 124 o client 126 o configuration data 128 o state data 130 This document also makes use of the following terminology introduced 131 in the YANG 1.1 Data Modeling Language [RFC7950]: 133 o augment 135 o data model 137 o data node 139 This document also makes use of the following terminology introduced 140 in the IETF Network Slice definition draft 141 [I-D.nsdt-teas-ietf-network-slice-definition]: 143 o IETF Network Slice (NS): An IETF Network Slice is a logical 144 network topology connecting a number of endpoints and a set of 145 shared or dedicated network resources, which are used to satisfy 146 specific Service Level Objectives (SLO). The definition is from 147 Section 3 of [I-D.nsdt-teas-ietf-network-slice-definition]. 149 o IETF Network Slice Endpoint (NSE): An IETF Network Slice Endpoint 150 is a logical identifier at DAN (Device,Application,Network 151 Function) of the customer network to identify the logical access 152 to which, a particular subset of traffic traversing the external 153 interface, is mapped to a specific IETF Network Slice and it 154 follows the definition of NSE (IETF Network Slice Endpoint) in 155 Section 4.2 of [I-D.nsdt-teas-ietf-network-slice-definition]. 157 o SLO: An SLO is a service level objective 159 o DAN: Device,Application,Network Function 161 o NSC: IETF Network Slice Controller 163 o NBI: Northbound Interface 165 In addition, this document defines the following terminology: 167 o IETF Network Slice Member (Network-Slice-Member): A IETF Network- 168 Slice-Member is an abstract entity which represents the network 169 resources mapped to a particular connection between a pair of NSEs 170 belonging to an IETF Network Slice. Note that different SLO 171 requirement per Network-Slice-Member could be applied. 173 o Network Slice Connection Group: Represents a set of Network Slice 174 Members with same SLO attributes in one IETF Network Slice. 176 2.1. Tree Diagrams 178 Tree diagrams used in this document follow the notation defined in 179 [RFC8340]. 181 3. IETF Network Slice NBI Model Usage 183 The intention of the IETF Network Slice NBI model is to allow the 184 consumer, e.g. A higher level management system, to request and 185 monitor IETF Network Slices. In particular, the model allows 186 consumers to operate in an abstract, technology-agnostic manner, with 187 implementation details hidden. 189 In the use case of 5G transport application, the E2E network slice 190 orchestrator acts as the higher layer system to request the IETF 191 Network Slices. The interface is used to support dynamic IETF 192 Network Slice creation and its lifecycle management to facilitate 193 end-to-end network slice services. 195 +----------------------------------------+ 196 | IETF Network Slice Consumer | 197 |(e.g 5G E2E network slice orchestrator) | 198 +----------------+-----------------------+ 199 | 200 | 201 |IETF Network Slice NBI YANG 202 | 203 +---------------------+--------------------------+ 204 | IETF Network Slice Controller (NSC) | 205 +------------------------------------------------+ 207 Figure 1 IETF Network Slice NBI Model Context 209 4. IETF Network Slice NBI Model Overview 211 From a consumer perspective, an example of an IETF Network Slice is 212 shown in figure 2. 214 IETF scoped Network 215 DAN1 +---------------------------------+ DAN3 216 +--------+ +------+ | +--------+ 217 | o +---o| A | +------+ | | 218 | NSE1 | +------+ | C |o---+ | 219 +--------+ | +------+ | | 220 | | | o | 221 +--------+ | +------+ | NSE3 | 222 | | +------+ | D |o---+ | 223 | o +---o| B | +------+ | | 224 | NSE2 | +------+ | | | 225 +--------+ | | +--------+ 226 DAN2 +---------------------------------+ 227 | | 228 | | 229 |<----------------IETF Network Slice 1----------------->| 231 Legend:DAN (Device,Application,Network Function) 233 Network-Slice-Connection-Group Red Network-Slice-Connection-Group Blue 234 Network-Slice-Member 1 NSE1-NSE3 Network-Slice-Member 3 NSE1-NSE2 235 Network-Slice-Member 2 NSE2-NSE3 237 Figure 2: An example of an IETF Network Slice 238 As shown in figure 2, an IETF Network Slice (NS) links together NSEs 239 at the DANs, which are customer endpoints that request an IETF 240 Network Slice. At each customer DAN, one or multiple NSEs could be 241 connected to the IETF Network Slice. 243 An IETF Network Slice is a connectivity with specific SLO 244 characteristics, including bandwidth, QoS metric, etc. The 245 connectivity is a combination of logical connections, represented by 246 Network-Slice-Members. When some parts of a network slice have 247 different SLO requirements, a set of Network-Slice-Members with the 248 same SLO is described by Network Slice Connection Group. 250 Based on this design, the IETF Network Slice YANG module consists of 251 the main containers: "network-slice", "network-slice-endpoint", 252 "network-slice-member",and "network-slice-connection-group". 254 The figure below describes the overall structure of the YANG module: 256 module: ietf-network-slice 257 +--rw ietf-network-slices 258 +--rw slice-templates 259 | +--rw slo-template* [id] 260 | +--rw id string 261 | +--rw template-description? string 262 +--rw ietf-network-slice* [network-slice-id] 263 +--rw network-slice-id uint32 264 +--rw network-slice-name? string 265 +--rw network-slice-tag* string 266 +--rw network-slice-topology* identityref 267 +--rw network-slice-connection-group* [connection-group-name] 268 | +--rw connection-group-name string 269 | +--rw default-connection-group? boolean 270 | +--rw (slo-template)? 271 | | +--:(standard) 272 | | | +--rw template? leafref 273 | | +--:(custom) 274 | | +--rw network-slice-slo-policy 275 | | +--rw latency 276 | | | +--rw one-way-latency? uint32 277 | | | +--rw two-way-latency? uint32 278 | | +--rw jitter 279 | | | +--rw one-way-jitter? uint32 280 | | | +--rw two-way-jitter? uint32 281 | | +--rw loss 282 | | | +--rw one-way-loss? decimal64 283 | | | +--rw two-way-loss? decimal64 284 | | +--rw availability-type? identityref 285 | | +--rw isolation-type? identityref 286 | | +--rw network-slice-metric-bounds 287 | | +--rw network-slice-metric-bound* 288 | | [metric-type] 289 | | +--rw metric-type identityref 290 | | +--rw upper-bound? uint64 291 | +--rw network-slice-member-group* 292 | | [network-slice-member-id] 293 | | +--rw network-slice-member-id leafref 294 | +--ro connection-group-monitoring 295 | +--ro latency? uint32 296 | +--ro jitter? uint32 297 | +--ro loss? decimal64 298 +--rw status 299 | +--rw admin-enabled? boolean 300 | +--ro oper-status? operational-type 301 +--rw network-slice-endpoint* [endpoint-id] 302 | +--rw endpoint-id uint32 303 | +--rw endpoint-name? string 304 | +--rw endpoint-role* identityref 305 | +--rw geolocation 306 | | +--rw altitude? int64 307 | | +--rw latitude? decimal64 308 | | +--rw longitude? decimal64 309 | +--rw node-id? string 310 | +--rw port-id? string 311 | +--rw network-slice-match-criteria 312 | | +--rw network-slice-match-criteria* [match-type] 313 | | +--rw match-type identityref 314 | | +--rw value? string 315 | +--rw endpoint-ip? inet:host 316 | +--rw bandwidth 317 | | +--rw incoming-bandwidth 318 | | | +--rw guaranteed-bandwidth? te-types:te-bandwidth 319 | | +--rw outgoing-bandwidth 320 | | +--rw guaranteed-bandwidth? te-types:te-bandwidth 321 | +--rw mtu uint16 322 | +--rw routing 323 | | +--rw bgp 324 | | | +--rw bgp-peer-ipv4* inet:ipv4-prefix 325 | | | +--rw bgp-peer-ipv6* inet:ipv6-prefix 326 | | +--rw static 327 | | +--rw static-route-ipv4* inet:ipv4-prefix 328 | | +--rw static-route-ipv6* inet:ipv6-prefix 329 | +--rw status 330 | | +--rw admin-enabled? boolean 331 | | +--ro oper-status? operational-type 332 | +--ro endpoint-monitoring 333 | +--ro incoming-utilized-bandwidth? 334 | | te-types:te-bandwidth 335 | +--ro incoming-bw-utilization decimal64 336 | +--ro outgoing-utilized-bandwidth? 337 | | te-types:te-bandwidth 338 | +--ro outgoing-bw-utilization decimal64 339 +--rw network-slice-member* [network-slice-member-id] 340 +--rw network-slice-member-id uint32 341 +--rw src 342 | +--rw src-network-slice-endpoint-id? leafref 343 +--rw dest 344 | +--rw dest-network-slice-endpoint-id? leafref 345 +--rw monitoring-type? 346 | network-slice-monitoring-type 347 +--ro network-slice-member-monitoring 348 +--ro latency? uint32 349 +--ro jitter? uint32 350 +--ro loss? decimal64 352 5. IETF Network Slice NBI Model Description 354 An IETF Network Slice consists of a group of interconnected NSEs, and 355 the connections between NSEs may have different SLO requirements, 356 including symmetrical or asymmetrical traffic throughput, different 357 traffic delay, etc. 359 5.1. IETF Network Slice Connection Types 361 An IETF Network Slice can be point-to-point (P2P), point-to- 362 multipoint (P2MP), multipoint-to-point (MP2P), or multipoint-to- 363 multipoint (MP2MP) based on the consumer's traffic pattern 364 requirements. 366 Therefore, the "network-slice-topology" under the node "network- 367 slice" is required for configuration. The model supports any-to-any, 368 Hub and Spoke (where Hubs can exchange traffic), and the different 369 combinations. New topologies could be added via augmentation. By 370 default, the any-to-any topology is used. 372 In addition, "endpoint-role" under the node "network-slice-endpoint" 373 also needs to be defined, which specifies the role of the NSE in a 374 particular Network Slice topology. In the any-to-any topology, all 375 NSEs MUST have the same role, which will be "any-to-any-role". In 376 the Hub-and-Spoke topology, NSEs MUST have a Hub role or a Spoke 377 role. 379 5.2. IETF Network Slice Endpoint (NSE) 381 An NSE belong to a single IETF Network Slice. An IETF Network Slice 382 involves two or more NSEs. 384 A NSE is used to define the limit on the user traffic that can be 385 injected to a network slice. For example, in some scenarios, the 386 access traffic of a DAN is allowed only when it matches the logical 387 Layer 2 connection identifier. In some scenarios, the access traffic 388 of a DAN is allowed only when the traffic matches a source IP 389 address. Sometimes, the traffic from a distinct physical connection 390 of a DAN is allowed. 392 Therefore, to ensure that the NSE is uniquely identified, the model 393 use the following parameters including "node-id", "port-id" and 394 "network-slice-match-criteria". The "node-id" identifies a DAN node, 395 the "port-id" identifies a port, and the "network-slice-match- 396 criteria" identifies a possible logical L2 ID or IP address or other 397 possible traffic identifier in the user traffic. 399 Additionally, a number of slice interconnection parameters need to be 400 agreed with a customer DAN and the IETF network, such as IP address 401 (v4 or v6) etc. 403 5.3. IETF Network Slice SLO 405 As defined in [I-D.nsdt-teas-ietf-network-slice-definition], this 406 model defines the minimum IETF Network Slice SLO attributes, and 407 other SLO nodes can be augmented as needed. NS SLO assurance is 408 implemented through the following mechanisms: 410 o Network Slice SLO list: Which defines the performance objectives 411 of the NS. Performance objectives can be specified for various 412 performance metrics,and different objectives are as follows: 414 Latency: Indicates the maximum latency between two NSE. The 415 unit is micro seconds. The latency could be round trip times 416 or one-way metrics. 418 Jitter: Indicates the jitter constraint of the slice maximum 419 permissible delay variation, and is measured by the difference 420 in the one- way delay between sequential packets in a flow. 422 Loss: Indicates maximum permissible packet loss rate, which is 423 defined by the ratio of packets dropped to packets transmitted 424 between two endpoints. 426 Availability: Is defined as the ratio of up-time to 427 total_time(up-time+down-time), where up-time is the time the 428 IETF Network Slice is available in accordance with the SLOs 429 associated with it. 431 Isolation: Whether the isolation needs to be explicitly 432 requested is still in discussion. 434 o Bandwidth: Indicates the guaranteed minimum bandwidth between any 435 two NSE. The unit is data rate per second. And the bandwidth is 436 unidirectional. The bandwidth is specified at each NSE and can be 437 applied to incoming NS traffic or outgoing NS traffic. When 438 applied in the incoming direction, the Bandwidth is applicable to 439 the traffic from the NSE to the IETF scope Network that passes 440 through the external interface. When Bandwidth is applied to the 441 outgoing direction, it is applied to the traffic from the IETF 442 Network to the NSE of that particular NS. 444 Note: About the definition of SLO parameters, the author is 445 discussing to reuse the TE-Types grouping definition as much as 446 possible, to avoid duplication of definitions. 448 Consumers' Network Slices can be very different, e.g. some slices has 449 the same SLO requirements of connections, some slices has the 450 different SLO requirements for different parts of the slice. In some 451 slices, the bandwidth of one endpoint is different from that of other 452 endpoints, for example, one is central endpoint, the other endpoints 453 are access endpoints. 455 The list "network-slice-connection-group" defines a set of "network- 456 slice-membe" with a particular SLO attributes, which are used to 457 describe that different parts of a network slice have different SLOs. 458 The specific SLOs of the slice connection group may use a standard 459 SLO template, or may use different customized parameters. A group of 460 "network-slice-member" is used to describe which connections of the 461 slice use the SLOs. 463 For some simplest IETF Network Slices, only one category SLO of 464 "network-slice-connection-group" needs to be defined. For some 465 complicated network slices, in addition to the configurations above, 466 multiple "network-slice-connection-group" needs to be defined, and 467 "network-slice-member-group" describes details of the per-connection 468 SLO. 470 In addition to SLO performance objectives, there are also some other 471 Network Slice objectives, such as MTU and security which can be 472 augmented when needed. MTU specifies the maximum packet length that 473 the network slice guarantee to be able to carry across. 475 Note: In some use cases, the number of connections represented by 476 "network-slice-member-group" may be huge, which may lead to 477 configuration issues, for example, the scalability or error-prone. 479 6. IETF Network Slice Monitoring 481 This model also describes performance status of an IETF Network 482 Slice. The statistics are described in the following granularity: 484 o Per NS Connection group: specified in 'connection-group- 485 monitoring' under the "network-slice-connection-group" 487 o Per NS connection: specified in 'network-slice-member-monitoring' 488 under the "network-slice-member" 490 o Per NS Endpoint: specified in 'endpoint-monitoring' under the 491 "network-slice-endpoint" 493 This model does not define monitoring enabling methods. The 494 mechanism defined in [RFC8640] and [RFC8641] can be used for either 495 periodic or on-demand subscription. 497 By specifying subtree filters or xpath filters to 'network-slice- 498 member' or 'network-slice-endpoint' ,so that only interested contents 499 will be sent. These mechanisms can be used for monitoring the IETF 500 Network Slice performance status so that the client management system 501 could initiate modification based on the IETF Network Slice running 502 status. 504 7. IETF Network Slice NBI Module 506 file "ietf-network-slice@2020-11-13.yang" 508 module ietf-network-slice { 509 yang-version 1.1; 510 namespace "urn:ietf:params:xml:ns:yang:ietf-network-slice"; 511 prefix ietf-ns; 513 import ietf-inet-types { 514 prefix inet; 515 } 516 import ietf-te-types { 517 prefix te-types; 518 } 520 organization 521 "IETF Traffic Engineering Architecture and Signaling (TEAS) 522 Working Group"; 524 contact 525 "WG Web: 526 WG List: 527 Editor: Bo Wu 528 : Dhruv Dhody "; 529 description 530 "This module contains a YANG module for the IETF Network Slice. 532 Copyright (c) 2020 IETF Trust and the persons identified as 533 authors of the code. All rights reserved. 535 Redistribution and use in source and binary forms, with or 536 without modification, is permitted pursuant to, and subject to 537 the license terms contained in, the Simplified BSD License set 538 forth in Section 4.c of the IETF Trust's Legal Provisions 539 Relating to IETF Documents 540 (http://trustee.ietf.org/license-info). 542 This version of this YANG module is part of RFC XXXX; see the 543 RFC itself for full legal notices."; 545 revision 2020-11-13 { 546 description 547 "initial version."; 548 reference 549 "RFC XXXX: A Yang Data Model for IETF Network Slice Operation"; 550 } 552 /* Features */ 553 /* Identities */ 555 identity network-slice-topology { 556 description 557 "Base identity for IETF Network Slice topology."; 558 } 560 identity any-to-any { 561 base network-slice-topology; 562 description 563 "Identity for any-to-any IETF Network Slice topology."; 564 } 566 identity hub-spoke { 567 base network-slice-topology; 568 description 569 "Identity for Hub-and-Spoke IETF Network Slice topology."; 570 } 571 identity endpoint-role { 572 description 573 "Network Slice Endpoint Role in an IETF Network Slice topology "; 574 } 576 identity any-to-any-role { 577 base endpoint-role; 578 description 579 "Network Slice Endpoint as the any-to-any role in an any-to-any 580 IETF Network Slice."; 581 } 583 identity hub { 584 base endpoint-role; 585 description 586 "Network Slice Endpoint as the hub role in a Hub-and-Spoke 587 IETF Network Slice."; 588 } 590 identity spoke { 591 base endpoint-role; 592 description 593 "Network Slice Endpoint as the spoke role in a Hub-and-Spoke 594 IETF Network Slice."; 595 } 597 identity isolation-type { 598 description 599 "Base identity from which specific isolation types are derived."; 600 } 602 identity physical-isolation { 603 base isolation-type; 604 description 605 "physical isolation."; 606 } 608 identity logical-isolation { 609 base isolation-type; 610 description 611 "logical-isolation."; 612 } 614 identity network-slice-slo-metric-type { 615 description 616 "Base identity for Network Slice SLO metric type"; 617 } 618 identity network-slice-match-type { 619 description 620 "Base identity for Network Slice traffic match type"; 621 } 623 identity network-slice-vlan-match { 624 base network-slice-match-type; 625 description 626 "VLAN as Network Slice traffic match criteria."; 627 } 629 /* 630 * Identity for availability-type 631 */ 633 identity availability-type { 634 description 635 "Base identity from which specific availability 636 types are derived."; 637 } 639 identity level-1 { 640 base availability-type; 641 description 642 "level 1: 99.9999%"; 643 } 645 identity level-2 { 646 base availability-type; 647 description 648 "level 2: 99.999%"; 649 } 651 identity level-3 { 652 base availability-type; 653 description 654 "level 3: 99.99%"; 655 } 657 identity level-4 { 658 base availability-type; 659 description 660 "level 4: 99.9%"; 661 } 663 identity level-5 { 664 base availability-type; 665 description 666 "level 5: 99%"; 667 } 669 /* typedef */ 671 typedef operational-type { 672 type enumeration { 673 enum up { 674 value 0; 675 description 676 "Operational status UP."; 677 } 678 enum down { 679 value 1; 680 description 681 "Operational status DOWN"; 682 } 683 enum unknown { 684 value 2; 685 description 686 "Operational status UNKNOWN"; 687 } 688 } 689 description 690 "This is a read-only attribute used to determine the 691 status of a particular element"; 692 } 694 typedef network-slice-monitoring-type { 695 type enumeration { 696 enum one-way { 697 description 698 "represents one-way monitoring type"; 699 } 700 enum two-way { 701 description 702 "represents two-way monitoring type"; 703 } 704 } 705 description 706 "enumerated type of monitoring on a network-slice-member "; 707 } 709 /* Groupings */ 711 grouping status-params { 712 description 713 "Grouping used to join operational and administrative status"; 715 container status { 716 description 717 "Container for status of administration and operational"; 718 leaf admin-enabled { 719 type boolean; 720 description 721 "Administrative Status UP/DOWN"; 722 } 723 leaf oper-status { 724 type operational-type; 725 config false; 726 description 727 "Operations status"; 728 } 729 } 730 } 732 grouping network-slice-match-criteria { 733 description 734 "Grouping for Network Slice match definition."; 735 container network-slice-match-criteria { 736 description 737 "Describes Network Slice match criteria."; 738 list network-slice-match-criteria { 739 key "match-type"; 740 description 741 "List of Network Slice traffic criteria"; 742 leaf match-type { 743 type identityref { 744 base network-slice-match-type; 745 } 746 description 747 "Identifies an entry in the list of match-type for 748 the Network Slice."; 749 } 750 leaf value { 751 type string; 752 description 753 "Describes Network Slice match criteria,e.g. IP address, 754 VLAN, etc."; 755 } 756 } 757 } 758 } 760 grouping network-slice-metric-bounds { 761 description 762 "Network Slice metric bounds grouping"; 764 container network-slice-metric-bounds { 765 description 766 "Network Slice metric bounds container"; 767 list network-slice-metric-bound { 768 key "metric-type"; 769 description 770 "List of Network Slice metric bounds"; 771 leaf metric-type { 772 type identityref { 773 base network-slice-slo-metric-type; 774 } 775 description 776 "Identifies an entry in the list of metric-types 777 bound for the Network Slice."; 778 } 779 leaf upper-bound { 780 type uint64; 781 default "0"; 782 description 783 "Upper bound on network-slice-member metric. A zero indicate 784 an unbounded upper limit for the specific metric-type"; 785 } 786 } 787 } 788 } 790 grouping routing-protocols { 791 description 792 "Grouping for endpoint protocols definition."; 793 container routing { 794 description 795 "Describes protocol between Network Slice Endpoint and IETF 796 scoped network edge device."; 797 container bgp { 798 description 799 "BGP-specific configuration."; 800 leaf-list bgp-peer-ipv4 { 801 type inet:ipv4-prefix; 802 description 803 "BGP peer ipv4 address."; 804 } 805 leaf-list bgp-peer-ipv6 { 806 type inet:ipv6-prefix; 807 description 808 "BGP peer ipv6 address."; 809 } 810 } 811 container static { 812 description 813 "Only applies when protocol is static."; 814 leaf-list static-route-ipv4 { 815 type inet:ipv4-prefix; 816 description 817 "ipv4 static route"; 818 } 819 leaf-list static-route-ipv6 { 820 type inet:ipv6-prefix; 821 description 822 "ipv6 static route"; 823 } 824 } 825 } 826 } 828 grouping endpoint-monitoring-parameters { 829 description 830 "Grouping for endpoint-monitoring-parameters."; 831 container endpoint-monitoring { 832 config false; 833 description 834 "Container for endpoint-monitoring-parameters."; 835 leaf incoming-utilized-bandwidth { 836 type te-types:te-bandwidth; 837 description 838 "Bandwidth utilization that represents the actual 839 utilization of the incoming endpoint."; 840 } 841 leaf incoming-bw-utilization { 842 type decimal64 { 843 fraction-digits 5; 844 range "0..100"; 845 } 846 units "percent"; 847 mandatory true; 848 description 849 "To be used to define the bandwidth utilization 850 as a percentage of the available bandwidth."; 851 } 852 leaf outgoing-utilized-bandwidth { 853 type te-types:te-bandwidth; 854 description 855 "Bandwidth utilization that represents the actual 856 utilization of the incoming endpoint."; 857 } 858 leaf outgoing-bw-utilization { 859 type decimal64 { 860 fraction-digits 5; 861 range "0..100"; 862 } 863 units "percent"; 864 mandatory true; 865 description 866 "To be used to define the bandwidth utilization 867 as a percentage of the available bandwidth."; 868 } 869 } 870 } 872 grouping common-monitoring-parameters { 873 description 874 "Grouping for link-monitoring-parameters."; 875 leaf latency { 876 type uint32; 877 units "usec"; 878 description 879 "The latency statistics per Network Slice member."; 880 } 881 leaf jitter { 882 type uint32 { 883 range "0..16777215"; 884 } 885 description 886 "The jitter statistics per Network Slice member."; 887 } 888 leaf loss { 889 type decimal64 { 890 fraction-digits 6; 891 range "0 .. 50.331642"; 892 } 893 description 894 "Packet loss as a percentage of the total traffic 895 sent over a configurable interval. The finest precision is 896 0.000003%. where the maximum 50.331642%."; 897 reference 898 "RFC 7810, section-4.4"; 899 } 900 } 902 grouping geolocation-container { 903 description 904 "A grouping containing a GPS location."; 905 container geolocation { 906 description 907 "A container containing a GPS location."; 909 leaf altitude { 910 type int64; 911 units "millimeter"; 912 description 913 "Distance above the sea level."; 914 } 915 leaf latitude { 916 type decimal64 { 917 fraction-digits 8; 918 range "-90..90"; 919 } 920 description 921 "Relative position north or south on the Earth's surface."; 922 } 923 leaf longitude { 924 type decimal64 { 925 fraction-digits 8; 926 range "-180..180"; 927 } 928 description 929 "Angular distance east or west on the Earth's surface."; 930 } 931 } 932 // gps-location 933 } 935 // geolocation-container 937 grouping endpoint { 938 description 939 "IETF Network Slice endpoint related information"; 940 leaf endpoint-id { 941 type uint32; 942 description 943 "unique identifier for the referred IETF Network 944 Slice endpoint"; 945 } 946 leaf endpoint-name { 947 type string; 948 description 949 "endpoint name"; 950 } 951 leaf-list endpoint-role { 952 type identityref { 953 base endpoint-role; 954 } 955 default "any-to-any-role"; 956 description 957 "Role of the endpoint in the IETF Network Slice."; 958 } 959 uses geolocation-container; 960 leaf node-id { 961 type string; 962 description 963 "Uniquely identifies an edge node within the IETF slice 964 network."; 965 } 966 leaf port-id { 967 type string; 968 description 969 "Reference to the Port-id of the customer node."; 970 } 971 uses network-slice-match-criteria; 972 leaf endpoint-ip { 973 type inet:host; 974 description 975 "The address of the TACACS+ server."; 976 } 977 container bandwidth { 978 container incoming-bandwidth { 979 leaf guaranteed-bandwidth { 980 type te-types:te-bandwidth; 981 description 982 "If guaranteed-bandwidth is 0, it means best effort, no 983 minimum throughput is guaranteed."; 984 } 985 description 986 "Container for the incoming bandwidth policy"; 987 } 988 container outgoing-bandwidth { 989 leaf guaranteed-bandwidth { 990 type te-types:te-bandwidth; 991 description 992 "If guaranteed-bandwidth is 0, it means best effort, no 993 minimum throughput is guaranteed."; 994 } 995 description 996 "Container for the bandwidth policy"; 997 } 998 description 999 "Container for the bandwidth policy"; 1000 } 1001 leaf mtu { 1002 type uint16; 1003 units "bytes"; 1004 mandatory true; 1005 description 1006 "MTU of Network Slice traffic. If the traffic type is IP, 1007 it refers to the IP MTU. If the traffic type is Ethertype, 1008 will refer to the Ethernet MTU. "; 1009 } 1010 uses routing-protocols; 1011 uses status-params; 1012 uses endpoint-monitoring-parameters; 1013 } 1015 //network-slice-endpoint 1017 grouping network-slice-member { 1018 description 1019 "network-slice-member is described by this container"; 1020 leaf network-slice-member-id { 1021 type uint32; 1022 description 1023 "network-slice-member identifier"; 1024 } 1025 container src { 1026 description 1027 "the source of Network Slice link"; 1028 leaf src-network-slice-endpoint-id { 1029 type leafref { 1030 path "/ietf-network-slices/ietf-network-slice/" 1031 + "network-slice-endpoint/endpoint-id"; 1032 } 1033 description 1034 "reference to source Network Slice endpoint"; 1035 } 1036 } 1037 container dest { 1038 description 1039 "the destination of Network Slice link "; 1040 leaf dest-network-slice-endpoint-id { 1041 type leafref { 1042 path "/ietf-network-slices/ietf-network-slice" 1043 + "/network-slice-endpoint/endpoint-id"; 1044 } 1045 description 1046 "reference to dest Network Slice endpoint"; 1047 } 1048 } 1049 leaf monitoring-type { 1050 type network-slice-monitoring-type; 1051 description 1052 "One way or two way monitoring type."; 1054 } 1055 container network-slice-member-monitoring { 1056 config false; 1057 description 1058 "SLO status Per network-slice endpoint to endpoint "; 1059 uses common-monitoring-parameters; 1060 } 1061 } 1063 //network-slice-member 1065 grouping network-slice-connection-group { 1066 description 1067 "Grouping for SLO definition of Network Slice"; 1068 list network-slice-connection-group { 1069 key "connection-group-name"; 1070 description 1071 "List of Network Slice connection groups, the connection group 1072 is used to support different SLO objectives between different 1073 network-slice-members in a same IETF Network slice."; 1074 leaf connection-group-name { 1075 type string; 1076 description 1077 "Identifies an entry in the list of connection group for the 1078 Network Slice."; 1079 } 1080 leaf default-connection-group { 1081 type boolean; 1082 default "false"; 1083 description 1084 "Is the connection group is selected as the default connection 1085 group of a particular SLO"; 1086 } 1087 choice slo-template { 1088 description 1089 "Choice for SLO template. 1090 Can be standard template or customized template."; 1091 case standard { 1092 description 1093 "Standard SLO template."; 1094 leaf template { 1095 type leafref { 1096 path "/ietf-network-slices" 1097 + "/slice-templates/slo-template/id"; 1098 } 1099 description 1100 "QoS template to be used."; 1101 } 1103 } 1104 case custom { 1105 description 1106 "Customized SLO template."; 1107 container network-slice-slo-policy { 1108 container latency { 1109 leaf one-way-latency { 1110 type uint32 { 1111 range "0..16777215"; 1112 } 1113 units "usec"; 1114 description 1115 "Lowest latency in micro seconds."; 1116 } 1117 leaf two-way-latency { 1118 type uint32 { 1119 range "0..16777215"; 1120 } 1121 description 1122 "Lowest-way delay or latency in micro seconds."; 1123 } 1124 description 1125 "Latency constraint on the traffic class."; 1126 } 1127 container jitter { 1128 leaf one-way-jitter { 1129 type uint32 { 1130 range "0..16777215"; 1131 } 1132 description 1133 "lowest latency in micro seconds."; 1134 } 1135 leaf two-way-jitter { 1136 type uint32 { 1137 range "0..16777215"; 1138 } 1139 description 1140 "lowest-way delay or latency in micro seconds."; 1141 } 1142 description 1143 "Jitter constraint on the traffic class."; 1144 } 1145 container loss { 1146 leaf one-way-loss { 1147 type decimal64 { 1148 fraction-digits 6; 1149 range "0 .. 50.331642"; 1150 } 1151 description 1152 "Packet loss as a percentage of the total traffic sent 1153 over a configurable interval. The finest precision is 1154 0.000003%. where the maximum 50.331642%."; 1155 reference 1156 "RFC 7810, section-4.4"; 1157 } 1158 leaf two-way-loss { 1159 type decimal64 { 1160 fraction-digits 6; 1161 range "0 .. 50.331642"; 1162 } 1163 description 1164 "Packet loss as a percentage of the total traffic sent 1165 over a configurable interval. The finest precision is 1166 0.000003%. where the maximum 50.331642%."; 1167 reference 1168 "RFC 7810, section-4.4"; 1169 } 1170 description 1171 "Loss constraint on the traffic class."; 1172 } 1173 leaf availability-type { 1174 type identityref { 1175 base availability-type; 1176 } 1177 description 1178 "Availability Requirement for the Network Slice"; 1179 } 1180 leaf isolation-type { 1181 type identityref { 1182 base isolation-type; 1183 } 1184 default "logical-isolation"; 1185 description 1186 "Network Slice isolation-level."; 1187 } 1188 uses network-slice-metric-bounds; 1189 description 1190 "container for customized policy constraint on the slice 1191 traffic."; 1192 } 1193 } 1194 } 1195 list network-slice-member-group { 1196 key "network-slice-member-id"; 1197 description 1198 "List of included Network Slice Member groups for the SLO."; 1200 leaf network-slice-member-id { 1201 type leafref { 1202 path "/ietf-network-slices/ietf-network-slice/" 1203 + "network-slice-member/network-slice-member-id"; 1204 } 1205 description 1206 "Identifies the included list of Network Slice member."; 1207 } 1208 } 1209 container connection-group-monitoring { 1210 config false; 1211 description 1212 "SLO status per connection group "; 1213 uses common-monitoring-parameters; 1214 } 1215 } 1216 } 1218 grouping slice-template { 1219 description 1220 "Grouping for slice-templates."; 1221 container slice-templates { 1222 description 1223 "Container for slice-templates."; 1224 list slo-template { 1225 key "id"; 1226 leaf id { 1227 type string; 1228 description 1229 "Identification of the SLO Template to be used. 1230 Local administration meaning."; 1231 } 1232 leaf template-description { 1233 type string; 1234 description 1235 "Description of the SLO template."; 1236 } 1237 description 1238 "List for SLO template identifiers."; 1239 } 1240 } 1241 } 1243 /* Configuration data nodes */ 1245 container ietf-network-slices { 1246 description 1247 "IETF network-slice configurations"; 1249 uses slice-template; 1250 list ietf-network-slice { 1251 key "network-slice-id"; 1252 description 1253 "a network-slice is identified by a network-slice-id"; 1254 leaf network-slice-id { 1255 type uint32; 1256 description 1257 "a unique network-slice identifier"; 1258 } 1259 leaf network-slice-name { 1260 type string; 1261 description 1262 "network-slice name"; 1263 } 1264 leaf-list network-slice-tag { 1265 type string; 1266 description 1267 "Network Slice tag for operational management"; 1268 } 1269 leaf-list network-slice-topology { 1270 type identityref { 1271 base network-slice-topology; 1272 } 1273 default "any-to-any"; 1274 description 1275 "Network Slice topology."; 1276 } 1277 uses network-slice-connection-group; 1278 uses status-params; 1279 list network-slice-endpoint { 1280 key "endpoint-id"; 1281 uses endpoint; 1282 description 1283 "list of endpoints in this slice"; 1284 } 1285 list network-slice-member { 1286 key "network-slice-member-id"; 1287 description 1288 "List of network-slice-member in a slice"; 1289 uses network-slice-member; 1290 } 1291 } 1292 //ietf-network-slice list 1293 } 1294 } 1295 1297 8. Security Considerations 1299 The YANG module defined in this document is designed to be accessed 1300 via network management protocols such as NETCONF [RFC6241] or 1301 RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport 1302 layer, and the mandatory-to-implement secure transport is Secure 1303 Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the 1304 mandatory-to-implement secure transport is TLS [RFC8446]. 1306 The NETCONF access control model [RFC8341] provides the means to 1307 restrict access for particular NETCONF or RESTCONF users to a 1308 preconfigured subset of all available NETCONF or RESTCONF protocol 1309 operations and content. 1311 There are a number of data nodes defined in this YANG module that are 1312 writable/creatable/deletable (i.e., config true, which is the 1313 default). These data nodes may be considered sensitive or vulnerable 1314 in some network environments. Write operations (e.g., edit-config) 1315 to these data nodes without proper protection can have a negative 1316 effect on network operations. 1318 o /ietf-network-slice/ietf-network-slices/ietf-network-slice 1320 The entries in the list above include the whole network 1321 configurations corresponding with the slice which the higher 1322 management system requests, and indirectly create or modify the PE or 1323 P device configurations. Unexpected changes to these entries could 1324 lead to service disruption and/or network misbehavior. 1326 9. IANA Considerations 1328 This document registers a URI in the IETF XML registry [RFC3688]. 1329 Following the format in [RFC3688], the following registration is 1330 requested to be made: 1332 URI: urn:ietf:params:xml:ns:yang:ietf-network-slice 1333 Registrant Contact: The IESG. 1334 XML: N/A, the requested URI is an XML namespace. 1336 This document requests to register a YANG module in the YANG Module 1337 Names registry [RFC7950]. 1339 Name: ietf-network-slice 1340 Namespace: urn:ietf:params:xml:ns:yang:ietf-network-slice 1341 Prefix: ietf-ns 1342 Reference: RFC XXXX 1344 10. Acknowledgments 1346 The authors wish to thank Sergio Belotti, Qin Wu, Susan Hares, Eric 1347 Grey, and many other NS DT members for their helpful comments and 1348 suggestions. 1350 11. References 1352 11.1. Normative References 1354 [I-D.nsdt-teas-ietf-network-slice-definition] 1355 Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. 1356 Tantsura, "Definition of IETF Network Slices", draft-nsdt- 1357 teas-ietf-network-slice-definition-01 (work in progress), 1358 November 2020. 1360 [I-D.nsdt-teas-ns-framework] 1361 Gray, E. and J. Drake, "Framework for Transport Network 1362 Slices", draft-nsdt-teas-ns-framework-04 (work in 1363 progress), July 2020. 1365 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1366 Requirement Levels", BCP 14, RFC 2119, 1367 DOI 10.17487/RFC2119, March 1997, 1368 . 1370 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1371 DOI 10.17487/RFC3688, January 2004, 1372 . 1374 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1375 and A. Bierman, Ed., "Network Configuration Protocol 1376 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1377 . 1379 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1380 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1381 . 1383 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1384 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1385 . 1387 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1388 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1389 . 1391 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1392 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1393 . 1395 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1396 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1397 May 2017, . 1399 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1400 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1401 . 1403 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1404 Access Control Model", STD 91, RFC 8341, 1405 DOI 10.17487/RFC8341, March 2018, 1406 . 1408 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1409 and R. Wilton, "Network Management Datastore Architecture 1410 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1411 . 1413 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1414 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1415 . 1417 [RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 1418 E., and A. Tripathy, "Dynamic Subscription to YANG Events 1419 and Datastores over NETCONF", RFC 8640, 1420 DOI 10.17487/RFC8640, September 2019, 1421 . 1423 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 1424 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 1425 September 2019, . 1427 11.2. Informative References 1429 [I-D.geng-teas-network-slice-mapping] 1430 Geng, X., Dong, J., Pang, R., Han, L., Niwa, T., Jin, J., 1431 Liu, C., and N. Nageshar, "5G End-to-end Network Slice 1432 Mapping from the view of Transport Network", draft-geng- 1433 teas-network-slice-mapping-02 (work in progress), July 1434 2020. 1436 [I-D.ietf-teas-actn-vn-yang] 1437 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. 1438 Yoon, "A YANG Data Model for VN Operation", draft-ietf- 1439 teas-actn-vn-yang-10 (work in progress), November 2020. 1441 [I-D.liu-teas-transport-network-slice-yang] 1442 Liu, X., Tantsura, J., Bryskin, I., Contreras, L., WU, Q., 1443 Belotti, S., and R. Rokui, "IETF Network Slice YANG Data 1444 Model", draft-liu-teas-transport-network-slice-yang-02 1445 (work in progress), November 2020. 1447 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 1448 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 1449 . 1451 Appendix A. IETF Network Slice NBI Model Usage Example 1453 The following example describes a simplified service configuration of 1454 two IETF Network slice instances: 1456 o IETF Network Slice 1 on Device1, Device3, and Device4, with any- 1457 to-any connection type 1459 o IETF Network Slice 2 on Device2, Device3, with any-to-any 1460 connection type 1462 192.0.2.2 VLAN1 1463 +--------+ 1464 |Device1 o------/ 1465 +--------+ | +------+ 1466 +--------+ +------o| A +---------------+ 1467 |Device2 o-------/-----o| | | 1468 +--------+ +---+--+ | 1469 198.51.100.2 | | 1470 VLAN2 | +---+--+ 192.0.2.4 VLAN1 1471 | | | +--------+ 1472 192.0.2.3 VLAN1 | | C o-----/-----oDevice4 | 1473 +--------+ | +---+--+ +--------+ 1474 | o------/ | | 1475 | | | +---+--+ | 1476 | Device3| +------o| B +---------------+ 1477 | o-------/-----o| | 1478 +--------+ +------+ 1479 198.51.100.3 1480 VLAN2 1482 POST: /restconf/data/ietf-network-slice:ietf-network-slices 1483 Host: example.com 1484 Content-Type: application/yang-data+json 1486 { 1487 "ietf-network-slices": { 1488 "ietf-network-slice": [ 1489 { 1490 "network-slice-id": 1, 1491 "network-slice-name": "slice1", 1492 "network-slice-topology": "any-to-any", 1493 "network-slice-endpoint": [ 1494 { 1495 "endpoint-id": 11, 1496 "endpoint-name": "device1-ep1", 1497 "endpoint-role": "any-to-any-role", 1498 "network-slice-match-criteria": [ 1499 { 1500 "match-type": "network-slice-vlan-match", 1501 "value": "1" 1502 } 1503 ] 1504 }, 1505 { 1506 "endpoint-id": 12, 1507 "endpoint-name": "device3-ep1", 1508 "endpoint-role": "any-to-any-role", 1509 "network-slice-match-criteria": [ 1510 { 1511 "match-type": "network-slice-vlan-match", 1512 "value": "1" 1513 } 1514 ] 1515 }, 1516 { 1517 "endpoint-id": 13, 1518 "endpoint-name": "device4-ep1", 1519 "endpoint-role": "any-to-any-role", 1520 "network-slice-match-criteria": [ 1521 { 1522 "match-type": "network-slice-vlan-match", 1523 "value": "1" 1524 } 1525 ] 1526 } 1527 ] 1528 }, 1529 { 1530 "network-slice-id": 2, 1531 "network-slice-name": "slice2", 1532 "network-slice-topology": "any-to-any", 1533 "network-slice-endpoint": [ 1534 { 1535 "endpoint-id": 21, 1536 "endpoint-name": "device2-ep1", 1537 "endpoint-role": "any-to-any-role", 1538 "network-slice-match-criteria": [ 1539 { 1540 "match-type": "network-slice-vlan-match", 1541 "value": "2" 1542 } 1543 ] 1544 }, 1545 { 1546 "endpoint-id": 22, 1547 "endpoint-name": "device3-ep2", 1548 "endpoint-role": "any-to-any-role", 1549 "network-slice-match-criteria": [ 1550 { 1551 "match-type": "network-slice-vlan-match", 1552 "value": "2" 1553 } 1554 ] 1555 } 1556 ] 1557 } 1558 ] 1559 } 1560 } 1562 Appendix B. Comparison with Other Possible Design choices for IETF 1563 Network Slice NBI 1565 According to the 3.3.1. Northbound Inteface (NBI) 1566 [I-D.nsdt-teas-ns-framework], the IETF Network Slice NBI is a 1567 technology-agnostic interface, which is used for a consumer to 1568 express requirements for a particular IETF Network Slice. Consumers 1569 operate on abstract IETF Network Slices, with details related to 1570 their realization hidden. As classified by [RFC8309], the IETF 1571 Network Slice NBI is classified as Customer Service Model. 1573 This draft analyzes the following existing IETF models to identify 1574 the gap between the IETF Network Slice NBI requirements. 1576 B.1. ACTN VN Model Augmentation 1578 The difference between the ACTN VN model and the IETF Network Slice 1579 NBI requirements is that the IETF Network Slice NBI is a technology- 1580 agnostic interface, whereas the VN model is bound to the IETF TE 1581 Topologies. The realization of the IETF Network Slice does not 1582 necessarily require the slice network to support the TE technology. 1584 The ACTN VN (Virtual Network) model introduced in 1585 [I-D.ietf-teas-actn-vn-yang] is the abstract consumer view of the TE 1586 network. Its YANG structure includes four components: 1588 o VN: A Virtual Network (VN) is a network provided by a service 1589 provider to a customer for use and two types of VN has defined. 1590 The Type 1 VN can be seen as a set of edge-to-edge abstract links. 1591 Each link is an abstraction of the underlying network which can 1592 encompass edge points of the customer's network, access links, 1593 intra-domain paths, and inter-domain links. 1595 o AP: An AP is a logical identifier used to identify the access link 1596 which is shared between the customer and the IETF scoped Network. 1598 o VN-AP: A VN-AP is a logical binding between an AP and a given VN. 1600 o VN-member: A VN-member is an abstract edge-to-edge link between 1601 any two APs or VN-APs. Each link is formed as an E2E tunnel 1602 across the underlying networks. 1604 The Type 1 VN can be used to describe IETF Network Slice connection 1605 requirements. However, the Network Slice SLO and Network Slice 1606 Endpoint are not clearly defined and there's no direct equivalent. 1607 For example, the SLO requirement of the VN is defined through the 1608 IETF TE Topologies YANG model, but the TE Topologies model is related 1609 to a specific implementation technology. Also, VN-AP does not define 1610 "network-slice-match-criteria" to specify a specific NSE belonging to 1611 an IETF Network Slice. 1613 B.2. RFC8345 Augmentation Model 1615 The difference between the IETF Network Slice NBI requirements and 1616 the IETF basic network model is that the IETF Network Slice NBI 1617 requests abstract consumer IETF Network Slices, with details related 1618 to the slice Network hidden. But the IETF network model is used to 1619 describe the interconnection details of a Network. The customer 1620 service model does not need to provide details on the Network. 1622 For example, IETF Network Topologies YANG data model extension 1623 introduced in Transport Network Slice YANG Data Model 1625 [I-D.liu-teas-transport-network-slice-yang] includes three major 1626 parts: 1628 o Network: a transport network list and an list of nodes contained 1629 in the network 1631 o Link: "links" list and "termination points" list describe how 1632 nodes in a network are connected to each other 1634 o Support network: vertical layering relationships between IETF 1635 Network Slice networks and underlay networks 1637 Based on this structure, the IETF Network Slice-specific SLO 1638 attributes nodes are augmented on the Network Topologies model,, e.g. 1639 isolation etc. However, this modeling design requires the slice 1640 network to expose a lot of details of the network, such as the actual 1641 topology including nodes interconnection and different network layers 1642 interconnection. 1644 Appendix C. Appendix B IETF Network Slice Match Criteria 1646 5G is a use case of the IETF Network Slice and 5G End-to-end Network 1647 Slice Mapping from the view of IETF Network 1648 [I-D.geng-teas-network-slice-mapping] 1650 defines two types of Network Slice interconnection and 1651 differentiation methods: by physical interface or by TNSII (Transport 1652 Network Slice Interworking Identifier). TNSII is a field in the 1653 packet header when different 5G wireless network slices are 1654 transported through a single physical interfaces of the IETF scoped 1655 Network. In the 5G scenario, "network-slice-match-criteria" refers 1656 to TNSII. 1658 +------------------------------------------------------------+ 1659 | 5G E2E network slice orchestrator | 1660 ++-----------------------------------------------------+-----+ 1661 | | | 1662 | IETF Network Slice NBI | 1663 +---+-------+ | +-----+-----+ 1664 | | +------------------+ | | 1665 |RAN Slice | |IETF Network Slice| |Core Slice | 1666 |controller | | controller | | controller| 1667 +----+------+ +-------+----------+ +-----+-----+ 1668 | | | 1669 | | | 1670 +---+--+ +------------+----------------+ ++-----+ 1671 | | | | | | 1672 | | | | | | 1673 |+----+| | | | | 1674 || ||NS1-NSE1 | Network Slice 1 | |+----+| 1675 ||gNB1|+---------+-----+-----------------------+--------+|UPF1|| 1676 || |+************ / |NS1-NSE3|+----+| 1677 |+----+|NS2-NSE1 | */ | | | 1678 | | /* | | | 1679 |+----+|NS1-NSE2 | / * | | | 1680 || |+---------- * Network Slice 2 |NS2-NSE3|+----+| 1681 ||gNB2|+************************************************+|UPF2|| 1682 || ||NS2-NSE2 | | |+----+| 1683 |+----+| | | | 1684 | | | | | | 1685 | | | | | | 1686 +------+ +----------- -----------------+ +------+ 1688 As shown in the figure, gNodeB 1 and gNodeB 2 use IP gNB1 and IP gNB2 1689 to communicate with the IETF network, respectively. In addition, the 1690 traffic of NS1 and NS2 on gNodeB 1 and gNodeB 2 is transmitted 1691 through the same access links to the IETF slice network. The IETF 1692 slice network need to to distinguish different IETF Network Slice 1693 traffic of same gNB. Therefore, in addition to using "node-id" and 1694 "port-id" to identify a Network Slice Endpont, other information is 1695 needed along with these parameters to uniquely distinguish a NSE. 1696 For example, VLAN IDs in the user traffic can be used to distinguish 1697 the NSEs of gNBs and UPFs. 1699 Authors' Addresses 1700 Bo Wu 1701 Huawei Technologies 1702 101 Software Avenue, Yuhua District 1703 Nanjing, Jiangsu 210012 1704 China 1706 Email: lana.wubo@huawei.com 1708 Dhruv Dhody 1709 Huawei Technologies 1710 Divyashree Techno Park 1711 Bangalore, Karnataka 560066 1712 India 1714 Email: dhruv.ietf@gmail.com 1716 Liuyan Han 1717 China Mobile 1719 Email: hanliuyan@chinamobile.com 1721 Reza Rokui 1722 Nokia Canada 1724 Email: reza.rokui@nokia.com