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

From: "Rokui, Reza" <[email-masked]>
Date: Mon, 24 Jan 2022 13:59:55 +0000

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

[Diagram  Description automatically generated]

---

From: Aihua Guo <[email-masked]>
Date: Mon, 24 Jan 2022 12:01:36 -0500

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 <[email-masked]> wrote:

>    - 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
>
>
>
>
>
>

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 25 Jan 2022 14:12:25 +0000

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 <[email-masked]> On Behalf Of Aihua Guo
Sent: den 24 januari 2022 18:02
To: Rokui, Reza <[email-masked]>
Cc: CCAMP <[email-masked]>; Fatai Zhang <zhangfatai=[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi AIhua,

Cheers,
Reza

---

From: Aihua Guo <[email-masked]>
Date: Tue, 25 Jan 2022 13:45:39 -0500

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 <
[email-masked]> 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.
>
> 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.
>
>
>
> 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 <[email-masked]> *On Behalf Of *Aihua Guo
> *Sent:* den 24 januari 2022 18:02
> *To:* Rokui, Reza <[email-masked]>
> *Cc:* CCAMP <[email-masked]>; Fatai Zhang <zhangfatai=
> [email-masked]>
> *Subject:* Re: [CCAMP] Question on draft-zheng-ccamp-yang-otn-slicing-03
>
>
>
> Hi Reza,
>
>
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 25 Jan 2022 19:51:39 -0000

Hello all,

Thanks to the authors for trying to pull together the different points that have been raised. That’s a useful way to understand where we are. Hopefully it will help the chairs work out what to do next.

Additional thoughts in line…

Adrian

From: CCAMP <[email-masked]> On Behalf Of Aihua Guo
Sent: 25 January 2022 18:46
To: Daniele Ceccarelli <[email-masked]>
Cc: CCAMP <[email-masked]>; Fatai Zhang <zhangfatai=[email-masked]>
Subject: Re: [CCAMP] Question on draft-zheng-ccamp-yang-otn-slicing-03

Hi Daniele, Fatai, Reza, et.al <http://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.

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)

-         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.

I think that part of the problem in this discussion is that the term slice has been interpreted by some people (possibly in the marketing departments) as implying some kind of magic and sophisticated wizardry. But I don’t think it is!

Although I am still not happy with the text in draft-ietf-teas-ietf-network-slices, that document gives us a good scoping definition of the network slice and network slice service where the former is the arrangement of network resources in order to deliver the latter. So all this document is saying is that there are use cases where it is useful to partition the optical resources in the network to provide a set of connections that guarantee SLOs and SLEs as requested by the customer. 

It may be that some of us like to discuss that partitioning as an L1VPN or a virtual network or a set of L1 connections. That’s OK. But in the “modern jargon ” what is going on is a request for a network slice service and an arrangement of network resources to provide a network slice.

I can’t get hung up on the terminology.

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.

draft-ietf-teas-ietf-network-slices says

   IETF Network Slices are created and managed within the scope of one

   or more network technologies (e.g., IP, MPLS, optical).

So what CCAMP is seeking to do is clearly in scope of the concept of an IETF network slice. Any further discussion of this point would be needed in TEAS.

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.

That’s good to hear. I think, with that statement of intent, I’d be OK for the draft to continue with adoption and for this issue to be resolved in a later revision.

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. 

Yes. I think there are three different things going on.

The first is the YANG model for augmenting the network slice service request to be specific to OTN.

The second is a YANG model for mapping the OTN slice request onto the OTN control. (A bit like the LxNM models, but also considering the existing TEAS topology models etc.)

The third is more of an applicability statement describing how an OTN is sliced and what is necessary to support a network slice.

I don’t much care whether these are all in the same document. They could be since there is probably not a lot of work in total, and RFCs cost money.

I would ask the authors to be pretty careful about the description of ACTN and to make sure they are well aligned with (including not repeating material from) draft-ietf-teas-applicability-actn-slicing.

Best,

Adrian