Re: [CCAMP] Question on draft-zheng-ccamp-yang-otn-slicing-03

[Aihua Guo <[e-mail]>]

Hi Daniele, Fatai, Reza, et.al,

Thank you all for the comments. We have received support for WG adoption as
well as concerns/questions regarding the scope and terminologies,
particularly the term "OTN slicing" used with this draft. These comments
are always very helpful, and we would like to summarize the comments and
share some collective responses below.

The main open points of these comments include:
*Q: The use cases described in the draft are useful. However, the term
"slice" is conflated. Why not change the term "OTN slicing" to "OTN
service"? (Joel & Daniele)*
A: According to the descriptions in the IETF NS framework document:
-         Network slice service (what the user asks for and operates with,
as described in section 3.2)
-         Network slice (how the network resources are managed by the
network, as described in section 3.1)
Accordingly, in the context of OTN there are scenarios where OTN
technology-specific services require OTN network slices. Below are a few of
the examples:
Section 2 of the draft describes OTN services that benefit from OTN network
slices and we notice that the OTN wholesale (section 2.3) and co-sharing of
OTN infrastructure (section 2.2) are also mentioned in the Framework for
IETF network slices. Since these services are OTN technology specific, they
require an OTN technology-specific slice and cannot rely on the
technology-agnostic IETF network slices, otherwise the OTN
technology-specific parameters requested by the user will be lost in the
workflow.
Another example is a 4K HD service using baseband video/fiber channel
directly over OTN ((non-IP). In this case the orchestrator can request an
OTN technology-specific slice from an OTN-SC with L1-specific SLOs/SLEs.

*Q: Network slicing should stop at the IP layer (Igor)*
A: First, there is no such restriction described in the TEAS NS
framework draft.
Second, as discussed above, in many use cases the customer may be OTN-aware
and request OTN technology-specific SLOs/SLEs.

*Q: Should the OTN slicing model just augment the
ietf-network-slice-nbi-yang?*
A: The model captured in section 4.2 of this draft targets a generic module
for OTN/WDM/MW in the CCAMP WG. After the initial analysis, the authors are
positive to support the augmentation approach which is already aligned with
the previous comments from the mailing list.

*Q:Need a document in CCAMP to explain how OTN is used to support network
slicing, a kind of applicability document (Dianele, Igor)*
A: How OTN is used to support network slicing is already described in
section 3 of this document. In addition, this draft describes how other OTN
services are to be supported by OTN slicing, and YANG models addressing the
identified gaps are also provided.

Thanks,
Sergio, Italo, Haomian, and Aihua

On Tue, Jan 25, 2022 at 9:12 AM Daniele Ceccarelli <
[e-mail]> wrote:

> Hi,
>
>
>
> Speaking as an individual I tend to agree with Igor on the fact that we
> need a document in CCAMP to explain how OTN is used to support network
> slicing, a kind of applicability document.
>
> The role of the OTN-SC as NS realizer would perfectly fit into it.
>
> Speaking about OTN slicing seems to be a bit  “excessive”. For sure all
> the use cases in the draft make a lot of sense, like the wholesale one, but
> I would see as a request for an OTN service, not as an OTN slice.
>
>
>
> Again, this is just my personal opinion.
> Tomorrow when the poll will be closed Fatai and I will try to understand
> where the consensus is.
>
>
>
> Probably it could be a good idea to put the call for consensus on hold and
> have an interim meeting dedicated just to this topic.
>
>
>
> BR
> Daniele
>
>
>
>
>
> *From:* CCAMP <[e-mail]> *On Behalf Of *Aihua Guo
> *Sent:* den 24 januari 2022 18:02
> *To:* Rokui, Reza <[e-mail]>
> *Cc:* CCAMP <[e-mail]>rg>; Fatai Zhang <zhangfatai=
> [e-mail]>
> *Subject:* Re: [CCAMP] Question on draft-zheng-ccamp-yang-otn-slicing-03
>
>
>
> Hi Reza,
>
>
>
> Thank you for the comments. I agree with you that from the IETF NSC
> perspective, OTN-SC can be seen as just an NS realizer for underlying OTN
> technology. Additionally, OTN-SC could use the same interface to support
> technology-specific slicing for OTN-aware customers. These points can be
> captured in the next revision of the draft.
>
>
>
> Thanks,
>
> Aihua
>
>
>
> On Mon, Jan 24, 2022 at 9:00 AM Rokui, Reza <[e-mail]> wrote:
>
> Hi AIhua,
>
>
>
> I would like to bring another item for discussion which is relationship
> between OTN-SC and following draft:
>
>    - draft-contreras-teas-slice-controller-models-01
>
>
>
> In this draft, the internal logic of an IETF Network Slice Controller has
> been discussed which shown in picture on left. There is one
> technology-specific functional block called “NS Realizer”.
>
> If you compare this with picture on right, it seems reasonable to assume
> OTN-SC is simply the NS Realizer for OTN technology.
>
>
>
> IMO, it would be helpful if this concept is captured in your draft to
> reflect this fact that OTN-SC is just a “NS Realizer” for OTN network.
>
>
>
> Cheers,
>
> Reza
>
>
>
>
>
> [image: Diagram Description automatically generated]
>
>