Closed aguoietf closed 2 years ago
aguoietf
commented
2 years ago In the context of draft-contreras-teas-slice-controller-models. NS mapper is to map a technology-agnostic request to a technology-specific request. Therefore, an OTN-SC can be viewed as a NS realizer.
aguoietf
commented
2 years ago text proposal:
The presence of OTN-SC provides multiple options for a high-level slice controller
or an orchestrator to configure and realize slicing in OTN networks, depending on
whether a customer's slice request is technology agnostic or technology specific:
Option 1[opt.1]: An IETF NSC receives a technology-agnostic slice request from the IETF NSC NBI and
realizes full or part of the slice in OTN networks directly through MPI provided by
the PNC or MDSC. The IETF NSC is responsible for mapping a technology-agnostic slicing request
into an OTN technology-specific realization. In this option, the OTN-SC is not used.
Option 2[opt.2]: An IETF NSC receives a technology-agnostic slice request from the IETF NSC NBI and delegates the
request to the OTN-SC through the OTN-SC NBI, which is OTN technology specific. The OTN-SC in turn realizes the
slice in single or multi domain OTN networks by working with the underlying PNC or MDSC. In this option, the OTN-SC is
considered as a realization of IETF NSC, i.e., an NS realizer as per
{{!I-D.draft-contreras-teas-slice-controller-models}},
when the underlying network is OTN. The OTN-SC is also a subordinate slice controller of the IETF NSC, which
is consistent with the hierarchical control of slices defined by the IETF network slice framework.
Option 3[opt.3]: An OTN-aware orchestrator may request an OTN technology-specific slice with OTN-specific SLOs
through the OTN-SC NBI to the OTN-SC. The OTN-SC in turn realizes the slice in single or multi domain OTN
networks by working with the underlying PNC or MDSC
An OTN slice may be realized by using standard MPI interfaces, control plane,
network management system (NMS) or any other proprietary interfaces as needed. Examples of such
interfaces include the abstract TE topology {{!RFC8795}}, TE tunnel {{!I-D.ietf-teas-yang-te}},
L1VPN{{!RFC4847}}, or Netconf/YANG based interfaces such as OpenConfig. Some of these interfaces,
such as the TE tunnel model, are suitable for creating connectivity-based OTN slices which represent a
slice as a set of TE tunnels, while other interfaces such as the TE topology model are more suitable for
creating resource-based OTN slices which represent a slice as a topology.
The OTN-SC NBI is a technology-specific interface that augments the IETF NSC NBI, which is technology-
agnostic.
{{fig-slice-interfaces}} illustrates the OTN slicing control hierarchy
, the positioning of the OTN slicing interfaces as well as the options for OTN slice configuration.
+--------------------+
| Provider's User |
+--------|-----------+
| CMI
+-----------------------+----------------------------+
| Orchestrator / E2E Slice Controller |
+------------+-----------------------------+---------+
| | NSC-NBI
| +---------------------+---------+
| | IETF Network Slice Controller |
| +-----+---------------+---------+
| opt.3 | opt.2 | opt.1
| OTN-SC NBI |OTN-SC NBI |
+------------+-------------+--------+ |
| OTN-SC | |
+--------------------------+--------+ |
| MPI | MPI
+--------------------------+---------------+---------+
| PNC |
+--------------------------+-------------------------+
| SBI
+-----------+----------+
|OTN Physical Network |
+----------------------+Updates included in draft-ietf-ccamp-yang-otn-slicing-01
draft-contreras-teas-slice-controller-models defines the structure of an IETF NSC as:
OTN-SC Diagram:
It would be helpful for the draft to reflect the fact that OTN-SC is just a “NS Realizer” for OTN network. A possible update is:
mail thread