Draft: draft-ietf-ccamp-yang-otn-slicing

Commentary: Add NRP description and figure 
 For connectivity - based OTN slices , NRP is optional - a connection within an OTN slice can be realized by an OTN tunnel in the underlay topology For resource - based OTN slices , NRP is typically required due to the need for reserving resources - one OTN slice topology is typically realized by one dedicated NRP topology . Need to add the above description in the document .
OTN slices may be pre-configured by the management plane and
presented to the customer via the northbound interface (NBI), or be
dynamically provisioned by a higher layer slice controller, e.g. an
IETF network slice controller (IETF NSC) through the NBI.  The OTN
slice is provided by a service provider to a customer to be used as
though it was part of the customer's own networks.
OTN slices may be pre-configured by the management plane and
presented to the customer via the northbound interface (NBI), or be
dynamically provisioned by a higher layer slice controller, e.g., an
IETF network slice controller (IETF NSC) through the NBI.  The OTN
slice is provided by a service provider to a customer to be used as
though it was part of the customer's own networks.
In an end-to-end network slicing scenario such as 5G network slicing
TS.28.530-3GPP, an IETF network slice I-D.ietf-teas-ietf-network-
slices provides the required connectivity between other different
segments of an end-to-end network slice, such as the Radio Access
Network (RAN) and the Core Network (CN) segments, with a specific
performance commitment.  An IETF network slice could be composed of
network slices from multiple technological and administrative
domains.  An IETF network slice can be realized by using or combining
multiple underlying OTN slices with OTN resources, e.g.  ODU time
slots or ODU containers, to achieve end-to-end slicing across the
transport domain.
In an end-to-end network slicing scenario such as 5G network slicing
TS.28.530-3GPP, an IETF network slice I-D.ietf-teas-ietf-network-
slices provides the required connectivity between other different
segments of an end-to-end network slice, such as the Radio Access
Network (RAN) and the Core Network (CN) segments, with a specific
performance commitment.  An IETF network slice could be composed of
network slices from multiple technological and administrative
domains.  An IETF network slice can be realized by using or combining
multiple underlying OTN slices with OTN resources, e.g., ODU time
slots or ODU containers, to achieve end-to-end slicing across the
transport domain.
OTN slices may be abstracted differently depending on the requirement
contained in the configuration provided by the slice customer.
Whereas the customer requests an OTN slice to provide connectivities
between specified endpoints, an OTN slice can be abstracted as a set
of endpoint-to-endpoint links, with each link formed by an end-to-end
tunnel across the underlying OTN networks.  The resources associated
with each link of the slice is reserved and commissioned in the
underlying physical network upon the completion of configuring the
OTN slice and all the links are active.
OTN slices may be abstracted differently depending on the requirement
contained in the configuration provided by the slice customer.
Whereas the customer requests an OTN slice to provide connectivity
between specified endpoints, an OTN slice can be abstracted as a set
of endpoint-to-endpoint links, with each link formed by an end-to-end
tunnel across the underlying OTN networks.  The resources associated
with each link of the slice is reserved and commissioned in the
underlying physical network upon the completion of configuring the
OTN slice and all the links are active.
An OTN slice can also be abstracted as an abstract topology when the
customer requests the slice to share resources between multiple
endpoints and to use the resources on demand.  The abstract topology
may consist of virtual nodes and virtual links, whose associated
resources are reserved but not commissioned across the underlying OTN
networks.  The customer can later commission resources within the
slice dynamically using the NBI provided by the service provider.  An
OTN slice could use abstract topology to connect endpoints with
shared resources to optimize the resource utilization, and
connections can be activated within the slice as needed.
An OTN slice can also be abstracted as an abstract topology when the
customer requests the slice to share resources between multiple
endpoints and to use the resources on demand.  The abstract topology
may consist of virtual nodes and virtual links, and their associated
resources are reserved but not commissioned across the underlying OTN
networks.  The customer can later commission resources within the
slice dynamically using the NBI provided by the service provider.  An
OTN slice could use abstract topology to connect endpoints with
shared resources to optimize the resource utilization, and
connections can be activated within the slice as needed.
for network maintenance considerations.  Therefore an OTN slice
controller shall support configuring an OTN slice with both options.
for network maintenance considerations.  Therefore, an OTN slice
controller shall support configuring an OTN slice with both options.
I-D.ietf-teas-ietf-network-slices introduces a mechanism for an IETF
network slice controller to realize network slices by constructing
Network Resource Partitions (NRP).  A NRP is a collection of
resources identified in the underlay network to facilitate the
mapping of network slices onto available network resources.  An NRP
is a scope view of a topology and may be considered as a topology in
its own right.  Thus, in traffic-engineered (TE) networks including
OTN, an NRP may be simply represented as an abstract TE topology
defined by RFC8795.  For OTN networks, An NRP may be represented as
an abstract OTN topology defined by I-D.ietf-ccamp-otn-topo-yang.
The NRP may be used to address the scalability issues where there may
be considerable numbers of control and data plane states required to
be stored and programmed if network slices are mapped directly to the
underlay topology.  NRP is internal to a network slice controller,
and use of NRPs is optional yet could benefit a network slice
realization in large-scale networks, including OTN networks.
For connectivity-based OTN slices, a connection within an OTN slice
can be realized by an OTN tunnel in the underlay topology and
resources are reserved by the tunnel, thus use of NRP is optional in
this case.
For resource-based OTN slices, the OTN-SC may map an OTN slice
directly onto the underlay TE topology presented by the subtended
network controller (MDSC or PNC) without creating NRP topologies.
Due to the need for reserving resources, the OTN-SC needs to color
corresponding link resources of the underlay topology with a slice
identifier and maintain the coloring to keep track of the mapping of
OTN slices.  The OTN-SC may push the colored topology to the
subtended MDSC or PNC using the MPI model defined in this draft.
Alternatively, an OTN slice may be mapped to a NRP as an overlay
abstract OTN TE topology on top of the underlay topology.  The
corresponding link resources allocated to the slice is encapsulated
in and tracked by the abstract topology, and a given link or port in
the NRP topology represents resources that are reserved in the
underlay topology.  One OTN slice is typically realized by one
dedicated NRP topology and all the resources within that NRP topology
are reserved for the OTN slice.  In this case, the use of NRP
eliminates the need for coloring links in the underlay topology, and
the NRP topology may be pushed directly to the subtended MDSC or PNC
by the OTN-SC.
Multiple OTN slices may be mapped to the same NRP, and a single
connectivity construct of the slice may be mapped to only one NRP, as
per I-D.ietf-teas-ietf-network-slices.
fig-otn-sc-nrp illustrates the relationship between OTN slices and
NRP.
Common attributes, which include a set of common attributes like
slice identifier, name, description and names of customers who use
the slice.
Common attributes, which include a set of common attributes like
slice identifier, name, description, and names of customers who
use the slice.
Network topology, which represent set of shared, reserved
resources organized as a virtual topology between all of the
endpoints.  A customer could use such network topology to define
detailed connecvitiy path traversing the topology, and allow
sharing of resources between its multiple endpoint pairs.
Connectivity matrix, which represent the intended virtual
connections between the endpoints within a TNS.  A connctivity
matrix entry could be associated with an explicit path over the
above network topology.
Network topology, which represent set of shared, reserved
resources organized as a virtual topology between all of the
endpoints.  A customer could use such network topology to define
detailed connectivity path traversing the topology, and allow
sharing of resources between its multiple endpoint pairs.
Connectivity matrix, which represent the intended virtual
connections between the endpoints within a TNS.  A connectivity
matrix entry could be associated with an explicit path over the
above network topology.