< draft-wd-teas-ietf-network-slice-nbi-yang-04.txt   draft-wd-teas-ietf-network-slice-nbi-yang-05.txt >
Network Working Group B. Wu Network Working Group B. Wu
Internet-Draft D. Dhody Internet-Draft D. Dhody
Intended status: Standards Track Huawei Technologies Intended status: Standards Track Huawei Technologies
Expires: 26 January 2022 R. Rokui Expires: 30 March 2022 R. Rokui
Nokia Nokia
T. Saad T. Saad
Juniper Networks Juniper Networks
L. Han L. Han
China Mobile China Mobile
25 July 2021 L.M. Contreras
Telefonica
26 September 2021
IETF Network Slice Service YANG Model IETF Network Slice Service YANG Model
draft-wd-teas-ietf-network-slice-nbi-yang-04 draft-wd-teas-ietf-network-slice-nbi-yang-05
Abstract Abstract
This document provides a YANG data model for the IETF Network Slice This document provides a YANG data model for the IETF Network Slice
service model. The model can be used by a IETF Network Slice service. The model can be used by a IETF Network Slice Customer to
customer to manage IETF Network Slice from an IETF Network Slice manage IETF Network Slice from an IETF Network Slice Controller
Controller (NSC). (NSC).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 26 January 2022. This Internet-Draft will expire on 30 March 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 15 skipping to change at page 2, line 20
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3
2.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4
3. IETF Network Slice Service Model Usage . . . . . . . . . . . 4 3. IETF Network Slice Service Model Usage . . . . . . . . . . . 4
4. IETF Network Slice Service Model Overview . . . . . . . . . . 5 4. Background on IETF Network Slice Service Modeling . . . . . . 5
5. IETF Network Slice Templates . . . . . . . . . . . . . . . . 9 4.1. LxSM VPN Service Models . . . . . . . . . . . . . . . . . 5
6. IETF Network Slice Modeling Description . . . . . . . . . . . 9 4.2. ACTN VN Model Augmentation analysis . . . . . . . . . . . 5
6.1. IETF Network Slice Connectivity Type . . . . . . . . . . 10 5. IETF Network Slice Service Model Overview . . . . . . . . . . 8
6.2. IETF Network Slice SLO and SLE Policy . . . . . . . . . . 11 6. IETF Network Slice Templates . . . . . . . . . . . . . . . . 12
6.3. IETF Network Slice Endpoint (NSE) . . . . . . . . . . . . 13 7. IETF Network Slice Modeling Description . . . . . . . . . . . 12
7. IETF Network Slice Monitoring . . . . . . . . . . . . . . . . 16 7.1. IETF Network Slice Connectivity Type . . . . . . . . . . 13
8. IETF Network Slice Service Module . . . . . . . . . . . . . . 17 7.2. IETF Network Slice SLO and SLE Policy . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 37 7.3. IETF Network Slice Endpoint (NSE) . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 8. IETF Network Slice Monitoring . . . . . . . . . . . . . . . . 19
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 9. IETF Network Slice Service Module . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 10. Security Considerations . . . . . . . . . . . . . . . . . . . 40
12.1. Normative References . . . . . . . . . . . . . . . . . . 38 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
12.2. Informative References . . . . . . . . . . . . . . . . . 40 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41
Appendix A. IETF Network Slice NBI Model Usage Example . . . . . 41 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
Appendix B. Comparison with Other Possible Design choices for IETF 13.1. Normative References . . . . . . . . . . . . . . . . . . 41
Network Slice NBI . . . . . . . . . . . . . . . . . . . . 44 13.2. Informative References . . . . . . . . . . . . . . . . . 43
B.1. ACTN VN Model Augmentation . . . . . . . . . . . . . . . 44 Appendix A. IETF Network Slice NBI Model Usage Example . . . . . 44
B.2. RFC8345 Augmentation Model . . . . . . . . . . . . . . . 45 Appendix B. Appendix B IETF Network Slice Match Criteria . . . . 47
Appendix C. Appendix B IETF Network Slice Match Criteria . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction 1. Introduction
This document provides a YANG [RFC7950] data model for the IETF This document provides a YANG [RFC7950] data model for the IETF
Network Slice service model. Network Slice service.
The YANG model discussed in this document is defined based on the The YANG model discussed in this document is defined based on the
description of the IETF Network Slice in description of the IETF Network Slice in
[I-D.ietf-teas-ietf-network-slices], which is used to operate IETF [I-D.ietf-teas-ietf-network-slices], which is used to operate IETF
Network Slices during the IETF Network Slice instantiation. This Network Slices during the IETF Network Slice instantiation. This
YANG model supports various operations on IETF Network Slices such as YANG model supports various operations on IETF Network Slices such as
creation, modification, deletion, and monitoring. creation, modification, deletion, and monitoring.
The IETF Network Slice Controller (NSC) is a logical entity that The IETF Network Slice Controller (NSC) is a logical entity that
allows customers to manage IETF network slices. Customers operate on allows customers to manage IETF network slices. Details related to
abstract IETF network slices. Details related to the production of the realization of IETF network slices that fulfil the request are
slices that fulfil the request are internal to the entity that internal to the entity that operates the network. Such details are
operates the network. Such details are deployment- and deployment- and implementation-specific.
implementation-specific.
The NSC receives request from its customer-facing interface (e.g., The NSC receives request from its customer-facing interface (e.g.,
from a management system). This interface carries data objects the from a management system). This interface carries data objects the
IETF network slice user provides, describing the needed IETF network IETF network slice user provides, describing the needed IETF network
slices in terms of topology, target service level objectives (SLO), slices in terms of topology, target service level objectives (SLO),
and also monitoring and reporting requirements. These requirements and also monitoring and reporting requirements. These requirements
are then translated into technology-specific actions that are are then translated into technology-specific actions that are
implemented in the underlying network using a network-facing implemented in the underlying network using a network-facing
interface. The details of how the IETF network slices are put into interface. The details of IETF network slices realization are out of
effect are out of scope for this document. scope for this document.
The YANG model discussed in this document describes the requirements The YANG model discussed in this document describes the requirements
of an IETF Network Slice from the point of view of the customer. It of an IETF Network Slice from the point of view of the customer. It
is thus classified as customer service model in [RFC8309]. is thus classified as customer service model in [RFC8309].
The IETF Network Slice operational state is included in the same tree The IETF Network Slice operational state is included in the same tree
as the configuration consistent with Network Management Datastore as the configuration consistent with Network Management Datastore
Architecture [RFC8342]. Architecture [RFC8342].
2. Conventions used in this document 2. Conventions used in this document
skipping to change at page 4, line 31 skipping to change at page 4, line 31
According to the [I-D.ietf-teas-ietf-network-slices] description, According to the [I-D.ietf-teas-ietf-network-slices] description,
IETF Network Slices are applicable to use cases such as (but not IETF Network Slices are applicable to use cases such as (but not
limited to) network wholesale services, network infrastructure limited to) network wholesale services, network infrastructure
sharing among operators, NFV connectivity, Data Center Interconnect, sharing among operators, NFV connectivity, Data Center Interconnect,
and 5G E2E network slice. and 5G E2E network slice.
As shown in Figure 1, in all these use-cases, the model is used by As shown in Figure 1, in all these use-cases, the model is used by
the higher management system to communicate with NSC for life cycle the higher management system to communicate with NSC for life cycle
manage of IETF Network Slices including both enablement and manage of IETF Network Slices including both enablement and
monitoring. For example, in 5G E2E network slicing use-case the E2E monitoring. The interface is used to support dynamic IETF Network
network slice orchestrator acts as the higher layer system to request Slice creation and its lifecycle management to facilitate end-to-end
the IETF Network Slices. The interface is used to support dynamic network slice services.
IETF Network Slice creation and its lifecycle management to
facilitate end-to-end network slice services.
+----------------------------------------+ +----------------------------------------+
| IETF Network Slice Customer | | IETF Network Slice Customer |
| | | |
+----------------+-----------------------+ +----------------+-----------------------+
| |
| |
|IETF Network Slice service model YANG |IETF Network Slice service model YANG
| |
+---------------------+--------------------------+ +---------------------+--------------------------+
| IETF Network Slice Controller (NSC) | | IETF Network Slice Controller (NSC) |
+------------------------------------------------+ +------------------------------------------------+
Figure 1: IETF Network Slice Service Reference Architecture Figure 1: IETF Network Slice Service Reference Architecture
4. IETF Network Slice Service Model Overview 4. Background on IETF Network Slice Service Modeling
[I-D.ietf-teas-ietf-network-slices] defines the IETF Network Slice
service model as a technology agnostic interface. That is, customer
expresses requirements for a particular slice by specifying what is
required rather than how that is to be achieved.
This section explains why a new YANG service data model is proposed
for support of IETF network slice services. The following data
models are considered:
* L3SM, L2SM and L1CSM models
* ACTN VN model
4.1. LxSM VPN Service Models
Currently, the three VPN service models defined at IETF are L3SM
[RFC8299], L2SM [RFC8466], L1CSM [I-D.ietf-ccamp-l1csm-yang]. These
models are related to specific VPN technologies. When using these
models as a slicing service interface, customers need to be aware of
the network's VPN technology so that right interfaces can be used.
The IETF network slice service requires a technology agnostic
interface (similar to intent), to avoiding using multiple VPN models
or other technology specific models.
4.2. ACTN VN Model Augmentation analysis
Abstraction and Control of TE Networks (ACTN - [RFC8453]) defines a
virtual network (VN) service [I-D.ietf-teas-actn-vn-yang]. Figure 2
shows that the relationship of IETF network slice and ACTN framework.
ACTN VN is independent of VPN technologies, and relys on traffic
engineering YANG model [RFC8795] to define VN service in terms of a
topology with a single abstract node and its connectivity matrix.
IETF Network Slice | ACTN analogous
Terminology / Concepts Terminology
| and Concepts
+--------------------------------------+
|Consumer higher level operation system| | +-----+
| (e.g E2E network slice orchestrator) | =====> | CNC |
+--------------------------------------+ | +-----+
^ ^
| NSC NBI | | CMI
v v
+-------------------------------------+ | +------+
| IETF Network Slice Controller (NSC) | =====> | MDSC |
+-------------------------------------+ | +------+
^ ^
| NSC SBI | | MPI
v v
+-------------------------------------+ | +-----+
| Network Controller(s) | =====> | PNC |
+-------------------------------------+ | +-----+
Figure 2: ACTN mapping
The ACTN VN model introduced in[I-D.ietf-teas-actn-vn-yang] is an
abstract customer view of the TE network. Its YANG structure
includes four components:
* VN: A Virtual Network (VN) is a network provided by a service
provider to a customer for use and two types of VN has defined.
The Type 1 VN can be seen as a set of edge-to-edge abstract links
between VNAP.
* AP: An AP is a logical identifier used to identify the access link
which is shared between the customer and the IETF scoped Network.
* VN-AP: A VN-AP is a logical binding between an AP and a given VN.
* VN-member: A VN-member is an abstract edge-to-edge link between
any two APs or VN-APs.
Figure 3 illustrates the difference between AP/VNAPs in a VN and NSEs
of IETF network slice. Though AP is a logical identifier, it maps to
a access link between the customer nodes and provider nodes, which is
also TP (Termination Port) of the provider node). When the access
link changes, the VN connection matrix changes accordingly. For
example, when the backup link of AP5/TP5 is added, the corresponding
VN members, AP5-AP3 and AP5-AP4, also need to be added. These
changes are underlying topology details. The slice service focuses
on the connection matrix between C1, C2, and C3.
+----------------------+
| TE topology 1 | +------------+
+---+ | +---+ +---+ | TP1 | | TP3
|C2 +-+----|P1 | |P3 |TP3 | ----| |----
+---+\| TP1+---+\ /+---+\ | \ TP2 | | TP4
\ \/ \ | ---\ ----| AN1 |----
| \TP5 /\ \| / TP3 | |
+---+ | \+---+/ \+---+ \ +---+ ----| |
|C1 +-+----|P2 |----|P4 |-----\+ C3| +------------+
+---+ | TP2+---+ +---+TP4 | +---+ Abstract Node
+----------------------+ TE topology
\|/
+---------------+
AP1 ------| |------ AP3
AP2 ------| |------ AP4 +------------+
AP5 ------| VN 1 | | |
| | | |
+---------------+ NSE1 O |
VN-Member 1 AP1-AP3 | O NSE3
VN-Member 2 AP1-AP4 NSE2 O |
VN-Member 3 AP2-AP3 | |
VN-Member 4 AP2-AP4 +------------+
VN-Member 5 AP5-AP3 Network slice 1
VN-Member 6 AP5-AP4
Legend:
TP:Termination Point
AP:Access Point
Figure 3: Difference between AP and NSE
In summary, the ACTN VN model cannot be used to model the IETF
network slice service model because the VN model is tightly bound to
the IETF TE Topology model and the constraints are buried deep inside
the TE topology connectivity matrix and thus does not provide a clear
mechanism to specify SLO/SLE of IETF network slice. The IETF network
slice endpoint also does not ascribe to the concept of AP/VNAP. The
realization of the IETF Network Slice does not necessarily require
the slice network to support the TE technology. As the IETF network
slice could be realized with non-TE techniques (FlexAlgo, MT).
Reusing or augmenting VN model is problematic.
5. IETF Network Slice Service Model Overview
As defined in [I-D.ietf-teas-ietf-network-slices], an IETF Network As defined in [I-D.ietf-teas-ietf-network-slices], an IETF Network
Slice is a logical network topology connecting a number of endpoints Slice is a logical network topology connecting a number of endpoints
using a set of shared or dedicated network resources that are used to using a set of shared or dedicated network resources that are used to
satisfy specific service requirements. The logical topology types satisfy specific service requirements. The logical topology types
are: point-to-point, point-to-multipoint, multipoint-to-point, or are: point-to-point, point-to-multipoint, multipoint-to-point, or
multipoint-to-multipoint. The endpoints are conceptual points that multipoint-to-multipoint. The endpoints are conceptual points that
could map to a device, application or a network function. And the could map to a device, application or a network function. And the
specific service requirements, typically expressed as bandwidth, specific service requirements, typically expressed as bandwidth,
latency, latency variation, and other desired or required latency, latency variation, and other desired or required
characteristics, such as security, MTU, traffic-type (e.g., IPv4, characteristics, such as security, MTU, traffic-type (e.g., IPv4,
IPv6, Ethernet or unstructured) or a higher-level behavior to process IPv6, Ethernet or unstructured) or a higher-level behavior to process
traffic according to user-application (which may be realized using traffic according to user-application (which may be realized using
network function). An example of an IETF network slice is shown in network function). An example of an IETF network slice is shown in
Figure 2 . Figure 4 .
+----------------------------------------------+ +----------------------------------------------+
| | | |
NSE1 O------------------+ | NSE1 O------------------+ |
. +---------------------------O NSE2 . +---------------------------O NSE2
. | . . | .
. | multipoint-to-multipoint . . | multipoint-to-multipoint .
. | . . | .
. +---------------------------O NSEn . +---------------------------O NSEn
NSEm O------------------+ | NSEm O------------------+ |
skipping to change at page 5, line 42 skipping to change at page 8, line 42
+----------------------------------------------+ +----------------------------------------------+
| | | |
|<-----------An IETF Network Slice ---------->| |<-----------An IETF Network Slice ---------->|
| between endpoints NSE1 to NSEn | | between endpoints NSE1 to NSEn |
Legend: Legend:
NSE: IETF Network Slice Endpoint NSE: IETF Network Slice Endpoint
O: Represents IETF Network Slice Endpoints O: Represents IETF Network Slice Endpoints
Figure 2: An IETF Network Slice Example Figure 4: An IETF Network Slice Example
As shown in the example, an IETF network slice may have multiple As shown in the example, an IETF network slice may have multiple
NSEs. The NSEs are the ingress/egress points where traffic enters/ NSEs. The NSEs are the ingress/egress points where traffic enters/
exits the IETF network slice. As the edge of the IETF network slice, exits the IETF network slice. As the edge of the IETF network slice,
the NSEs also delimit a topological network portion within which the the NSEs also delimit a topological network portion within which the
committed SLOs apply. committed SLOs apply.
When an NSC receives a message via its customer-facing interface for When an NSC receives a message via its customer-facing interface for
creation/modification of an IETF network slice, it uses the provided creation/modification of an IETF network slice, it uses the provided
NSEs to retrieve the corresponding border link or "Provider Node" NSEs to retrieve the corresponding border link or "Provider Node"
(e.g., PE). The NSC further maps them to the appropriate (e.g., PE). The NSC further maps them to the appropriate
service/tunnel/path endpoints in the underlying network. It then service/tunnel/path endpoints in the underlying network. It then
uses services/tunnels/paths to realize the IETF network slice. uses services/tunnels/paths to realize the IETF network slice.
The 'ietf-network-slice' module uses two main data nodes: list 'ietf- The 'ietf-network-slice' module uses two main data nodes: list 'ietf-
network-slice' and container 'ns-templates' (see Figure 3). network-slice' and container 'ns-templates' (see Figure 5).
The 'ietf-network-slice' list includes the set of IETF Network slices The 'ietf-network-slice' list includes the set of IETF Network slices
managed within a provider network. 'ietf-network-slice' is the data managed within a provider network. 'ietf-network-slice' is the data
structure that abstracts an IETF Network Slice. Under the "ietf- structure that abstracts an IETF Network Slice. Under the "ietf-
network-slice", list "ns-endpoint" is used to abstract the NSEs, e.g. network-slice", list "ns-endpoint" is used to abstract the NSEs, e.g.
NSEs in the example above. And list "ns-connection" is used to NSEs in the example above. And list "ns-connection" is used to
abstract connections between NSEs. abstract connections between NSEs.
The 'ns-templates' container is used by the NSC to maintain a set of The 'ns-templates' container is used by the NSC to maintain a set of
common network slice templates that apply to one or several IETF common network slice templates that apply to one or several IETF
skipping to change at page 8, line 44 skipping to change at page 11, line 44
| +--rw mtu uint16 | +--rw mtu uint16
| +--rw steering-constraints | +--rw steering-constraints
| +--rw path-constraints | +--rw path-constraints
| +--rw service-function | +--rw service-function
+--rw monitoring-type? ns-monitoring-type +--rw monitoring-type? ns-monitoring-type
+--ro ns-connection-monitoring +--ro ns-connection-monitoring
+--ro latency? yang:gauge64 +--ro latency? yang:gauge64
+--ro jitter? yang:gauge32 +--ro jitter? yang:gauge32
+--ro loss-ratio? decimal64 +--ro loss-ratio? decimal64
Figure 3 Figure 5
5. IETF Network Slice Templates 6. IETF Network Slice Templates
The 'ns-templates' container (Figure 3) is used by service provider The 'ns-templates' container (Figure 5) is used by service provider
of the NSC to define and maintain a set of common IETF Network Slice of the NSC to define and maintain a set of common IETF Network Slice
templates that apply to one or several IETF Network Slices. The templates that apply to one or several IETF Network Slices. The
exact definition of the templates is deployment specific to each exact definition of the templates is deployment specific to each
network provider. network provider.
The model includes only the identifiers of SLO and SLE templates. The model includes only the identifiers of SLO and SLE templates.
When creation of IETF Network slice, the SLO and SLE policies can be When creation of IETF Network slice, the SLO and SLE policies can be
easily identified. easily identified.
The following shows an example where two network slice templates can The following shows an example where two network slice templates can
skipping to change at page 9, line 41 skipping to change at page 12, line 41
"id":"PLATINUM-template", "id":"PLATINUM-template",
"template-description": "Two-way bandwidth: 1 Gbps, "template-description": "Two-way bandwidth: 1 Gbps,
one-way latency 50ms " one-way latency 50ms "
"sle-isolation":"ns-isolation-dedicated", "sle-isolation":"ns-isolation-dedicated",
}, },
], ],
} }
} }
} }
6. IETF Network Slice Modeling Description 7. IETF Network Slice Modeling Description
The 'ietf-network-slice' is the data structure that abstracts an IETF The 'ietf-network-slice' is the data structure that abstracts an IETF
Network Slice of the IETF network. Each 'ietf-network-slice' is Network Slice of the IETF network. Each 'ietf-network-slice' is
uniquely identified by an identifier: 'ns-id'. uniquely identified by an identifier: 'ns-id'.
An IETF Network Slice has the following main parameters: An IETF Network Slice has the following main parameters:
* "ns-id": Is an identifier that is used to uniquely identify the * "ns-id": Is an identifier that is used to uniquely identify the
IETF Network Slice within NSC. IETF Network Slice within NSC.
skipping to change at page 10, line 23 skipping to change at page 13, line 23
of the IETF Network Slice, and can be used as indicator to detect of the IETF Network Slice, and can be used as indicator to detect
network slice anomalies. network slice anomalies.
* "customer-name": Is used to show the correlation between actual * "customer-name": Is used to show the correlation between actual
slice customers and IETF network slices. It can be used by the slice customers and IETF network slices. It can be used by the
NSC for monitoring and assurance of the IETF network slices where NSC for monitoring and assurance of the IETF network slices where
NSC can notify the higher system by issuing the notifications. NSC can notify the higher system by issuing the notifications.
For example, multiple actual customers use a same network slice. For example, multiple actual customers use a same network slice.
* "ns-slo-sle-policy": Defines SLO and SLE policies for the "ietf- * "ns-slo-sle-policy": Defines SLO and SLE policies for the "ietf-
network-slice". More description are provided in Section 6.2 network-slice". More description are provided in Section 7.2
The "ns-endpoint" is an abstrac entity that represents a set of The "ns-endpoint" is an abstrac entity that represents a set of
matching rules applied to an IETF network edge device or a customer matching rules applied to an IETF network edge device or a customer
network edge device involved in the IETF Network Slice and each 'ns- network edge device involved in the IETF Network Slice and each 'ns-
endpoint' belongs to a single 'ietf-network-slice'. More description endpoint' belongs to a single 'ietf-network-slice'. More description
are provided in Section 6.3 are provided in Section 7.3
6.1. IETF Network Slice Connectivity Type 7.1. IETF Network Slice Connectivity Type
Based on the customer's traffic pattern requirements, an IETF Network Based on the customer's traffic pattern requirements, an IETF Network
Slice connection type could be point-to-point (P2P), point-to- Slice connection type could be point-to-point (P2P), point-to-
multipoint (P2MP), multipoint-to-point (MP2P), or multipoint-to- multipoint (P2MP), multipoint-to-point (MP2P), or multipoint-to-
multipoint (MP2MP). The "ns-connectivity-type" under the node "ietf- multipoint (MP2MP). The "ns-connectivity-type" under the node "ietf-
network-slice" is used for this. network-slice" is used for this.
According to the network services defined in According to the network services defined in
[I-D.ietf-opsawg-vpn-common], some well-known connectivity types are [I-D.ietf-opsawg-vpn-common], some well-known connectivity types are
proposed for IETF network slices. The type could be any-to-any, Hub- proposed for IETF network slices. The type could be any-to-any, Hub-
and-Spoke (where Hubs can exchange traffic), and the custom. By and-Spoke (where Hubs can exchange traffic), and the custom. By
default, the any-to-any is used. New connectivity type could be default, the any-to-any is used. New connectivity type could be
added via augmentation or by list of 'ns-connection' specified. added via augmentation or by list of 'ns-connection' specified.
In addition, "ep-role" under the node "ns-endpoint" also needs to be In addition, "ep-role" under the node "ns-endpoint" also needs to be
defined, which specifies the role of the NSE in a particular Network defined, which specifies the role of the NSE in a particular Network
Slice connectivity type. In the any-to-any, all NSEs MUST have the Slice connectivity type. In the any-to-any, all NSEs MUST have the
same role, which will be "any-to-any-role". In the Hub-and-Spoke, same role, which will be "any-to-any-role". In the Hub-and-Spoke,
NSEs MUST have a Hub role or a Spoke role. NSEs MUST have a Hub role or a Spoke role.
6.2. IETF Network Slice SLO and SLE Policy 7.2. IETF Network Slice SLO and SLE Policy
As defined in [I-D.ietf-teas-ietf-network-slices], the SLO and SLE As defined in [I-D.ietf-teas-ietf-network-slices], the SLO and SLE
policy of an IETF Network Slice defines the minimum IETF Network policy of an IETF Network Slice defines the minimum IETF Network
Slice SLO attributes, and additional attributes can be added as Slice SLO attributes, and additional attributes can be added as
needed. needed.
"ns-slo-sle-policy" is used to represent specific SLO and SLE "ns-slo-sle-policy" is used to represent specific SLO and SLE
policies. During the creation of an IETF Network Slice, the policy policies. During the creation of an IETF Network Slice, the policy
can be specified either by a standard SLO and SLO template or a can be specified either by a standard SLO and SLO template or a
customized SLO and SLE policy. customized SLO and SLE policy.
skipping to change at page 13, line 28 skipping to change at page 16, line 28
"metric-type": "ns-slo-availability", "metric-type": "ns-slo-availability",
"bound": "99.9%" "bound": "99.9%"
}, },
], ],
} }
} }
} }
} }
} }
6.3. IETF Network Slice Endpoint (NSE) 7.3. IETF Network Slice Endpoint (NSE)
An IETF Network Slice Endpoint has several characteristics: An IETF Network Slice Endpoint has several characteristics:
* "ep-id": Uniquely identifies the NSE within Network Slice * "ep-id": Uniquely identifies the NSE within Network Slice
Controller (NSC). The identifier is a string that allows any Controller (NSC). The identifier is a string that allows any
encoding for the local administration of the IETF Network Slice. encoding for the local administration of the IETF Network Slice.
* "location": Indicates NSE location information that facilities NSC * "location": Indicates NSE location information that facilities NSC
easy identification of a NSE. easy identification of a NSE.
* "ep-role": Represents a connectivity type role of a NSE belonging * "ep-role": Represents a connectivity type role of a NSE belonging
to an IETF network slice, as described in Section 6.1. The "ep- to an IETF network slice, as described in Section 7.1. The "ep-
role" leaf defines the role of the endpoint in a particular NS role" leaf defines the role of the endpoint in a particular NS
connectivity type. In the any-to-any, all NSEs MUST have the same connectivity type. In the any-to-any, all NSEs MUST have the same
role, which will be "any-to-any-role". role, which will be "any-to-any-role".
* "node-id": The NSE node information facilities NSC with easy * "node-id": The NSE node information facilities NSC with easy
identification of a NSE. identification of a NSE.
* "ep-ip": The NSE IP information facilities NSC with easy * "ep-ip": The NSE IP information facilities NSC with easy
identification of a NSE. identification of a NSE.
skipping to change at page 15, line 5 skipping to change at page 18, line 5
* Logical interface: For example, a given VLAN ID is used to * Logical interface: For example, a given VLAN ID is used to
identify an IETF Network Slice. identify an IETF Network Slice.
* Encapsulation in the traffic header: For example, a source IP * Encapsulation in the traffic header: For example, a source IP
address is used to identify an IETF Network Slice. address is used to identify an IETF Network Slice.
To illustrate the use of NSE parameters, the below are two examples. To illustrate the use of NSE parameters, the below are two examples.
How the NSC realize the mapping is out of scope for this document. How the NSC realize the mapping is out of scope for this document.
* NSE with PE parameters example: As shown in Figure 4 , customer of * NSE with PE parameters example: As shown in Figure 6 , customer of
the IETF network slice would like to connect two NSEs to satisfy the IETF network slice would like to connect two NSEs to satisfy
specific service, e.g., Network wholesale services. In this case, specific service, e.g., Network wholesale services. In this case,
the IETF network slice endpoints are mapped to physical interfaces the IETF network slice endpoints are mapped to physical interfaces
of PE nodes. The IETF network slice controller (NSC) uses 'node- of PE nodes. The IETF network slice controller (NSC) uses 'node-
id' (PE device ID), 'ep-network-access-points' (Two PE interfaces id' (PE device ID), 'ep-network-access-points' (Two PE interfaces
) to map the interfaces and corresponding services/tunnels/paths. ) to map the interfaces and corresponding services/tunnels/paths.
NSE1 NSE2 NSE1 NSE2
(With PE1 parameters) (with PE2 parameters) (With PE1 parameters) (with PE2 parameters)
o<--------- IETF Network Slice 1 ------->o o<--------- IETF Network Slice 1 ------->o
skipping to change at page 15, line 38 skipping to change at page 18, line 38
Customer Provider Provider Customer Customer Provider Provider Customer
Edge 1 Edge 1 Edge 2 Edge 2 Edge 1 Edge 1 Edge 2 Edge 2
Legend: Legend:
O: Representation of the IETF network slice endpoints (NSE) O: Representation of the IETF network slice endpoints (NSE)
+: Mapping of NES to PE or CE nodes on IETF network +: Mapping of NES to PE or CE nodes on IETF network
X: Physical interfaces used for realization of IETF network slice X: Physical interfaces used for realization of IETF network slice
S1: L0/L1/L2/L3 services used for realization of IETF network slice S1: L0/L1/L2/L3 services used for realization of IETF network slice
T1: Tunnels used for realization of IETF network slice T1: Tunnels used for realization of IETF network slice
Figure 4 Figure 6
* NSE with CE parameters example: As shown in Figure 5 , customer of * NSE with CE parameters example: As shown in Figure 7 , customer of
the IETF network slice would like to connect two NSEs to provide the IETF network slice would like to connect two NSEs to provide
connectivity between transport portion of 5G RAN to 5G Core connectivity between transport portion of 5G RAN to 5G Core
network functions. In this scenario, the IETF network slice network functions. In this scenario, the IETF network slice
controller (NSC) uses 'node-id' (CE device ID) , 'ep-ip' (CE controller (NSC) uses 'node-id' (CE device ID) , 'ep-ip' (CE
tunnel endpoint IP), 'network-slice-match-criteria' (VLAN tunnel endpoint IP), 'network-slice-match-criteria' (VLAN
interface), 'ep-network-access-points' (Two nexthop interfaces ) interface), 'ep-network-access-points' (Two nexthop interfaces )
to retrieve the corresponding border link or PE, and further map to retrieve the corresponding border link or PE, and further map
to services/tunnels/paths. to services/tunnels/paths.
NSE3 NSE4 NSE3 NSE4
skipping to change at page 16, line 30 skipping to change at page 19, line 30
Customer Provider Provider Customer Customer Provider Provider Customer
Edge 1 Edge 1 Edge 2 Edge 2 Edge 1 Edge 1 Edge 2 Edge 2
Legend: Legend:
O: Representation of the IETF network slice endpoints (NSE) O: Representation of the IETF network slice endpoints (NSE)
+: Mapping of NSE to PE or CE-PE interfaces on IETF network +: Mapping of NSE to PE or CE-PE interfaces on IETF network
X: Physical interfaces used for realization of IETF network slice X: Physical interfaces used for realization of IETF network slice
S2: L0/L1/L2/L3 services used for realization of IETF network slice S2: L0/L1/L2/L3 services used for realization of IETF network slice
T2: Tunnels used for realization of IETF network slice T2: Tunnels used for realization of IETF network slice
Figure 5 Figure 7
Note: The model needs to be optimized for better extension of other Note: The model needs to be optimized for better extension of other
protocols or AC technologies. protocols or AC technologies.
7. IETF Network Slice Monitoring 8. IETF Network Slice Monitoring
An IETF Network Slice is a connectivity with specific SLO An IETF Network Slice is a connectivity with specific SLO
characteristics, including bandwidth, latency, etc. The connectivity characteristics, including bandwidth, latency, etc. The connectivity
is a combination of logical unidirectional connections, represented is a combination of logical unidirectional connections, represented
by 'ns-connection'. by 'ns-connection'.
This model also describes performance status of an IETF Network This model also describes performance status of an IETF Network
Slice. The statistics are described in the following granularity: Slice. The statistics are described in the following granularity:
* Per NS connection: specified in 'ns-connection-monitoring' under * Per NS connection: specified in 'ns-connection-monitoring' under
skipping to change at page 17, line 18 skipping to change at page 20, line 18
By specifying subtree filters or xpath filters to 'ns-connection' or By specifying subtree filters or xpath filters to 'ns-connection' or
'ns-endpoint' ,so that only interested contents will be sent. These 'ns-endpoint' ,so that only interested contents will be sent. These
mechanisms can be used for monitoring the IETF Network Slice mechanisms can be used for monitoring the IETF Network Slice
performance status so that the customer management system could performance status so that the customer management system could
initiate modification based on the IETF Network Slice running status. initiate modification based on the IETF Network Slice running status.
Note: More critical events affecting service delivery need to be Note: More critical events affecting service delivery need to be
added. added.
8. IETF Network Slice Service Module 9. IETF Network Slice Service Module
The "ietf-network-slice" module uses types defined in [RFC6991], The "ietf-network-slice" module uses types defined in [RFC6991],
[RFC8776]. [RFC8776].
<CODE BEGINS> file "ietf-network-slice@2021-07-20.yang" <CODE BEGINS> file "ietf-network-slice@2021-07-20.yang"
module ietf-network-slice { module ietf-network-slice {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-network-slice"; namespace "urn:ietf:params:xml:ns:yang:ietf-network-slice";
prefix ietf-ns; prefix ins;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
reference reference
"RFC 6991: Common YANG Types."; "RFC 6991: Common YANG Types.";
} }
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
reference reference
"RFC 6991: Common YANG Types."; "RFC 6991: Common YANG Types.";
skipping to change at page 37, line 28 skipping to change at page 40, line 28
"List of Network Slice connections."; "List of Network Slice connections.";
uses ns-connection; uses ns-connection;
} }
} }
} }
//ietf-network-slice list //ietf-network-slice list
} }
} }
<CODE ENDS> <CODE ENDS>
9. Security Considerations 10. Security Considerations
The YANG module defined in this document is designed to be accessed The YANG module defined in this document is designed to be accessed
via network management protocols such as NETCONF [RFC6241] or via network management protocols such as NETCONF [RFC6241] or
RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport
layer, and the mandatory-to-implement secure transport is Secure layer, and the mandatory-to-implement secure transport is Secure
Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the
mandatory-to-implement secure transport is TLS [RFC8446]. mandatory-to-implement secure transport is TLS [RFC8446].
The NETCONF access control model [RFC8341] provides the means to The NETCONF access control model [RFC8341] provides the means to
restrict access for particular NETCONF or RESTCONF users to a restrict access for particular NETCONF or RESTCONF users to a
skipping to change at page 38, line 10 skipping to change at page 41, line 10
to these data nodes without proper protection can have a negative to these data nodes without proper protection can have a negative
effect on network operations. effect on network operations.
o /ietf-network-slice/network-slices/network-slice o /ietf-network-slice/network-slices/network-slice
The entries in the list above include the whole network The entries in the list above include the whole network
configurations corresponding with the slice which the higher configurations corresponding with the slice which the higher
management system requests, and indirectly create or modify the PE or management system requests, and indirectly create or modify the PE or
P device configurations. Unexpected changes to these entries could P device configurations. Unexpected changes to these entries could
lead to service disruption and/or network misbehavior. lead to service disruption and/or network misbehavior.
10. IANA Considerations 11. IANA Considerations
This document registers a URI in the IETF XML registry [RFC3688]. This document registers a URI in the IETF XML registry [RFC3688].
Following the format in [RFC3688], the following registration is Following the format in [RFC3688], the following registration is
requested to be made: requested to be made:
URI: urn:ietf:params:xml:ns:yang:ietf-network-slice URI: urn:ietf:params:xml:ns:yang:ietf-network-slice
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
This document requests to register a YANG module in the YANG Module This document requests to register a YANG module in the YANG Module
Names registry [RFC7950]. Names registry [RFC7950].
Name: ietf-network-slice Name: ietf-network-slice
Namespace: urn:ietf:params:xml:ns:yang:ietf-network-slice Namespace: urn:ietf:params:xml:ns:yang:ietf-network-slice
Prefix: ietf-ns Prefix: ins
Reference: RFC XXXX Reference: RFC XXXX
11. Acknowledgments 12. Acknowledgments
The authors wish to thank Mohamed Boucadair, Kenichi Ogaki, Sergio The authors wish to thank Mohamed Boucadair, Kenichi Ogaki, Sergio
Belotti, Qin Wu, Susan Hares, Eric Grey, and many others for their Belotti, Qin Wu, Susan Hares, Eric Grey, and many others for their
helpful comments and suggestions. helpful comments and suggestions.
12. References 13. References
12.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
skipping to change at page 40, line 10 skipping to change at page 43, line 10
[RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications
for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,
September 2019, <https://www.rfc-editor.org/info/rfc8641>. September 2019, <https://www.rfc-editor.org/info/rfc8641>.
[RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
"Common YANG Data Types for Traffic Engineering", "Common YANG Data Types for Traffic Engineering",
RFC 8776, DOI 10.17487/RFC8776, June 2020, RFC 8776, DOI 10.17487/RFC8776, June 2020,
<https://www.rfc-editor.org/info/rfc8776>. <https://www.rfc-editor.org/info/rfc8776>.
12.2. Informative References 13.2. Informative References
[I-D.geng-teas-network-slice-mapping] [I-D.geng-teas-network-slice-mapping]
Geng, X., Dong, J., Pang, R., Han, L., Niwa, T., Jin, J., Geng, X., Dong, J., Pang, R., Han, L., Niwa, T., Jin, J.,
Liu, C., and N. Nageshar, "5G End-to-end Network Slice Liu, C., and N. Nageshar, "5G End-to-end Network Slice
Mapping from the view of Transport Network", Work in Mapping from the view of Transport Network", Work in
Progress, Internet-Draft, draft-geng-teas-network-slice- Progress, Internet-Draft, draft-geng-teas-network-slice-
mapping-03, 22 February 2021, mapping-03, 22 February 2021,
<https://www.ietf.org/archive/id/draft-geng-teas-network- <https://www.ietf.org/archive/id/draft-geng-teas-network-
slice-mapping-03.txt>. slice-mapping-03.txt>.
[I-D.ietf-opsawg-vpn-common] [I-D.ietf-opsawg-vpn-common]
Barguil, S., Dios, O. G. D., Boucadair, M., and Q. Wu, "A Barguil, S., Dios, O. G. D., Boucadair, M., and Q. Wu, "A
Layer 2/3 VPN Common YANG Model", Work in Progress, Layer 2/3 VPN Common YANG Model", Work in Progress,
Internet-Draft, draft-ietf-opsawg-vpn-common-09, 15 July Internet-Draft, draft-ietf-opsawg-vpn-common-11, 23
2021, <https://www.ietf.org/archive/id/draft-ietf-opsawg- September 2021, <https://www.ietf.org/archive/id/draft-
vpn-common-09.txt>. ietf-opsawg-vpn-common-11.txt>.
[I-D.ietf-teas-actn-vn-yang] [I-D.ietf-teas-actn-vn-yang]
Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. Y. Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. Y.
Yoon, "A YANG Data Model for VN Operation", Work in Yoon, "A YANG Data Model for VN Operation", Work in
Progress, Internet-Draft, draft-ietf-teas-actn-vn-yang-11, Progress, Internet-Draft, draft-ietf-teas-actn-vn-yang-12,
19 February 2021, <https://www.ietf.org/archive/id/draft- 25 August 2021, <https://www.ietf.org/archive/id/draft-
ietf-teas-actn-vn-yang-11.txt>. ietf-teas-actn-vn-yang-12.txt>.
[I-D.ietf-teas-ietf-network-slices] [I-D.ietf-teas-ietf-network-slices]
Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S., Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S.,
Makhijani, K., Contreras, L. M., and J. Tantsura, Makhijani, K., Contreras, L. M., and J. Tantsura,
"Framework for IETF Network Slices", Work in Progress, "Framework for IETF Network Slices", Work in Progress,
Internet-Draft, draft-ietf-teas-ietf-network-slices-03, 23 Internet-Draft, draft-ietf-teas-ietf-network-slices-04, 23
May 2021, <https://www.ietf.org/archive/id/draft-ietf- August 2021, <https://www.ietf.org/archive/id/draft-ietf-
teas-ietf-network-slices-03.txt>. teas-ietf-network-slices-04.txt>.
[I-D.liu-teas-transport-network-slice-yang]
Liu, X., Tantsura, J., Bryskin, I., Contreras, L. M., Wu,
Q., Belotti, S., and R. Rokui, "IETF Network Slice YANG
Data Model", Work in Progress, Internet-Draft, draft-liu-
teas-transport-network-slice-yang-04, 9 July 2021,
<https://www.ietf.org/archive/id/draft-liu-teas-transport-
network-slice-yang-04.txt>.
[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models
Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
<https://www.rfc-editor.org/info/rfc8309>. <https://www.rfc-editor.org/info/rfc8309>.
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
Abstraction and Control of TE Networks (ACTN)", RFC 8453,
DOI 10.17487/RFC8453, August 2018,
<https://www.rfc-editor.org/info/rfc8453>.
[RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
O. Gonzalez de Dios, "YANG Data Model for Traffic
Engineering (TE) Topologies", RFC 8795,
DOI 10.17487/RFC8795, August 2020,
<https://www.rfc-editor.org/info/rfc8795>.
Appendix A. IETF Network Slice NBI Model Usage Example Appendix A. IETF Network Slice NBI Model Usage Example
The following example describes a simplified service configuration of The following example describes a simplified service configuration of
two IETF Network slice instances: two IETF Network slice instances:
* IETF Network Slice 1 on Device1, Device3, and Device4, with any- * IETF Network Slice 1 on Device1, Device3, and Device4, with any-
to-any connectivity type to-any connectivity type
* IETF Network Slice 2 on Device2, Device3, with any-to-any * IETF Network Slice 2 on Device2, Device3, with any-to-any
connectivity type connectivity type
skipping to change at page 43, line 51 skipping to change at page 47, line 4
} }
] ]
} }
] ]
} }
] ]
} }
} }
] ]
} }
}
Appendix B. Comparison with Other Possible Design choices for IETF
Network Slice NBI
According to the 5.3.2 Northbound Inteface (NBI)
[I-D.ietf-teas-ietf-network-slices], the IETF Network Slice NBI is a
technology-agnostic interface, which is used for a customer to
express requirements for a particular IETF Network Slice. Customers
operate on abstract IETF Network Slices, with details related to
their realization hidden. As classified by [RFC8309], the IETF
Network Slice NBI is classified as Customer Service Model.
This draft analyzes the following existing IETF models to identify
the gap between the IETF Network Slice NBI requirements.
B.1. ACTN VN Model Augmentation
The difference between the ACTN VN model and the IETF Network Slice
NBI requirements is that the IETF Network Slice NBI is a technology-
agnostic interface, whereas the VN model is bound to the IETF TE
Topologies. The realization of the IETF Network Slice does not
necessarily require the slice network to support the TE technology.
The ACTN VN (Virtual Network) model introduced
in[I-D.ietf-teas-actn-vn-yang] is the abstract customer view of the
TE network. Its YANG structure includes four components:
* VN: A Virtual Network (VN) is a network provided by a service
provider to a customer for use and two types of VN has defined.
The Type 1 VN can be seen as a set of edge-to-edge abstract links.
Each link is an abstraction of the underlying network which can
encompass edge points of the customer's network, access links,
intra-domain paths, and inter-domain links.
* AP: An AP is a logical identifier used to identify the access link
which is shared between the customer and the IETF scoped Network.
* VN-AP: A VN-AP is a logical binding between an AP and a given VN.
* VN-member: A VN-member is an abstract edge-to-edge link between
any two APs or VN-APs. Each link is formed as an E2E tunnel
across the underlying networks.
The Type 1 VN can be used to describe IETF Network Slice connection
requirements. However, the Network Slice SLO and Network Slice
Endpoint are not clearly defined and there's no direct equivalent.
For example, the SLO requirement of the VN is defined through the
IETF TE Topologies YANG model, but the TE Topologies model is related
to a specific implementation technology. Also, VN-AP does not define
"network-slice-match-criteria" to specify a specific NSE belonging to
an IETF Network Slice.
B.2. RFC8345 Augmentation Model
The difference between the IETF Network Slice NBI requirements and
the IETF basic network model is that the IETF Network Slice NBI
requests abstract customer IETF Network Slices, with details related
to the slice Network hidden. But the IETF network model is used to
describe the interconnection details of a Network. The customer
service model does not need to provide details on the Network.
For example, IETF Network Topologies YANG data model extension
introduced in Transport Network Slice YANG Data Model
[I-D.liu-teas-transport-network-slice-yang] includes three major
parts:
* Network: a transport network list and an list of nodes contained
in the network
* Link: "links" list and "termination points" list describe how }
nodes in a network are connected to each other
* Support network: vertical layering relationships between IETF
Network Slice networks and underlay networks
Based on this structure, the IETF Network Slice-specific SLO
attributes nodes are augmented on the Network Topologies model,, e.g.
isolation etc. However, this modeling design requires the slice
network to expose a lot of details of the network, such as the actual
topology including nodes interconnection and different network layers
interconnection.
Appendix C. Appendix B IETF Network Slice Match Criteria Appendix B. Appendix B IETF Network Slice Match Criteria
5G is a use case of the IETF Network Slice and 5G End-to-end Network 5G is a use case of the IETF Network Slice and 5G End-to-end Network
Slice Mapping from the view of IETF Slice Mapping from the view of IETF
Network[I-D.geng-teas-network-slice-mapping] Network[I-D.geng-teas-network-slice-mapping]
defines two types of Network Slice interconnection and defines two types of Network Slice interconnection and
differentiation methods: by physical interface or by TNSII (Transport differentiation methods: by physical interface or by TNSII (Transport
Network Slice Interworking Identifier). TNSII is a field in the Network Slice Interworking Identifier). TNSII is a field in the
packet header when different 5G wireless network slices are packet header when different 5G wireless network slices are
transported through a single physical interfaces of the IETF scoped transported through a single physical interfaces of the IETF scoped
skipping to change at page 47, line 34 skipping to change at page 49, line 4
Reza Rokui Reza Rokui
Nokia Nokia
Email: reza.rokui@nokia.com Email: reza.rokui@nokia.com
Tarek Saad Tarek Saad
Juniper Networks Juniper Networks
Email: tsaad@juniper.net Email: tsaad@juniper.net
Liuyan Han Liuyan Han
China Mobile China Mobile
Email: hanliuyan@chinamobile.com Email: hanliuyan@chinamobile.com
Luis Miguel Contreras
Telefonica
Distrito T
28050 Madrid
Spain
Email: luismiguel.contrerasmurillo@telefonica.com
 End of changes. 47 change blocks. 
169 lines changed or deleted 216 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/