Subject: [CCAMP] POLL CLOSED - WG adoption poll on draft-zheng-ccamp-yang-otn-slicing-03

From: Fatai Zhang <[email-masked]>
Date: Wed, 26 Jan 2022 14:45:03 +0000

Hi all,

The WG poll is closed with the result of the draft being adopted based on the WG consensus.

We as the chairs made the decision to adopt the draft because there is lots of interest in this topic and the open comments have been clarified to some extent, and we’re arranging an interim just on this draft and the WG will decide if and how to update the draft according to mailing list discussion and interim discussions.

Authors, please republish draft-zheng-ccamp-yang-otn-slicing-03  as draft-ietf-ccamp-yang-otn-slicing-00 with only the date and file name changed..

Thanks,

Fatai & Daniele

发件人: CCAMP [mailto:[email-masked]] 代表 Fatai Zhang
发送时间: 2022年1月12日 10:24
收件人: CCAMP <[email-masked]>
主题: [CCAMP] WG adoption poll on draft-zheng-ccamp-yang-otn-slicing-03

Hi all,

All the IPR declarations regarding draft-zheng-ccamp-yang-otn-slicing-03 have been collected, this starts the polling for WG adoption.

The poll will last 2 weeks and will end on Wednesday January 26th.

Please send email to the list indicating "yes/support" or "no/do not support" and a motivation for your reply, mandatory for the "not support" and nice to have for the "support".

Thanks,

Fatai & Daniele

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 26 Jan 2022 16:03:41 +0000 (UTC)

Hi Fatai,I have to say, I like your style very much too;)
As you personally encouraged me, I have asked a few questions during the poll, sometimes repeating them several times in a very clear and direct way.
So far, all but one of them were completely ignored, just crickets.The one question that was answered, was done so in a very perfunctory and totally illogical way: We couldnt/shouldn't stop slicing at IP layer, because NS framework doesn't limit slicing to IP. True, but neither it demands slicing in lower layers, just envisions that certain resource partitioning will be required to support higher layer slicing.--》For example, my nearest beach rules do not  limit using the beach to summer months, yet I do not jump into icy water in January.
Not to say that NS framework itself is still a work very much in progress.
The most obvious question is why the authors are clinging so desperately to the term "OTN slice"? After all it is just a term ( albeit very shiny these days). Why wouldn't  they just say: OK, you guys, find it a bit confusing. Let's come up with something  else. How about "OTN resource partition" or "OTN virtual network", as, I was told, SG12 folks did some 6 years ago when they themselves killed the term "OTN slice" ( which was being used since 2010) precisely because of the unfortunate connotation of something OTN partitioning service offered to OTN clients was not.
In short, I still like the Daniele's proposal of interim meeting.
Cheers,Igor

Sent from Yahoo Mail on Android 
 
  On Wed, Jan 26, 2022 at 9:45 AM, Fatai Zhang<zhangfatai=[email-masked]> wrote:    <!--#yiv0828751243 filtered {}#yiv0828751243 filtered {}#yiv0828751243 filtered {}#yiv0828751243 filtered {}#yiv0828751243 filtered {}#yiv0828751243 filtered {}#yiv0828751243 p.yiv0828751243MsoNormal, #yiv0828751243 li.yiv0828751243MsoNormal, #yiv0828751243 div.yiv0828751243MsoNormal {margin:0cm;margin-bottom:.0001pt;text-align:justify;text-justify:inter-ideograph;font-size:10.5pt;font-family:"Calibri", sans-serif;}#yiv0828751243 a:link, #yiv0828751243 span.yiv0828751243MsoHyperlink {color:#0563C1;text-decoration:underline;}#yiv0828751243 a:visited, #yiv0828751243 span.yiv0828751243MsoHyperlinkFollowed {color:#954F72;text-decoration:underline;}#yiv0828751243 p.yiv0828751243MsoPlainText, #yiv0828751243 li.yiv0828751243MsoPlainText, #yiv0828751243 div.yiv0828751243MsoPlainText {margin:0cm;margin-bottom:.0001pt;font-size:11.0pt;font-family:"Calibri", sans-serif;}#yiv0828751243 span.yiv0828751243EmailStyle17 {font-family:sans-serif;color:#1F497D;}#yiv0828751243 span.yiv0828751243EmailStyle18 {font-family:sans-serif;color:#1F497D;}#yiv0828751243 span.yiv0828751243Char {font-family:"Calibri", sans-serif;}#yiv0828751243 .yiv0828751243MsoChpDefault {font-size:10.0pt;}#yiv0828751243 filtered {}#yiv0828751243 div.yiv0828751243WordSection1 {}-->
Hi all,

 

 

 
Thanks,

Fatai & Daniele

发件人: CCAMP [mailto:[email-masked]]代表 Fatai Zhang
发送时间: 2022年1月12日 10:24
收件人: CCAMP <[email-masked]>
主题: [CCAMP] WG adoption poll on draft-zheng-ccamp-yang-otn-slicing-03

Hi all,

 

 

Thanks,

Fatai & Daniele

  
 _______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Aihua Guo <[email-masked]>
Date: Wed, 26 Jan 2022 14:15:18 -0500

Hi Igor,

Please see my comments below.

Thanks,
Aihua

On Wed, Jan 26, 2022 at 11:03 AM Igor Bryskin <i_bryskin=
[email-masked]> wrote:

>
>
> Hi Fatai,
> I have to say, I like your style very much too;)
>
> As you personally encouraged me, I have asked a few questions during the
> poll, sometimes repeating them several times in a very clear and direct way.
>
> So far, all but one of them were completely ignored, just crickets.
> The one question that was answered, was done so in a very perfunctory and
> totally illogical way:
>  We couldnt/shouldn't stop slicing at IP layer, because NS framework
> doesn't limit slicing to IP.
> True, but neither it demands slicing in lower layers, just envisions that
> certain resource partitioning will be required to support higher layer
> slicing.
> --》For example, my nearest beach rules do not  limit using the beach to
> summer months, yet I do not jump into icy water in January.
>
> *[AG] The comments above only quoted the first point in our reply, which
states the fact that technology-specific slicing is in the scope of the
framework for IETF network slicing and provides a base upon which OTN
slicing can build (and augment). More importantly, as we presented in the
last reply, there are use cases which require OTN technology-specific
slices from an OTN-aware customer. The general use cases for these specific
examples were already described in this draft. *
*In addition, the NS framework indicates that an IETF NS may be combined
hierarchically or sequentially, "so that a network slice may itself be
sliced. They may also be combined sequentially so that various different
networks can each be sliced and the network slices placed into a sequence
to provide an end-to-end service". For OTN networks one such sub-slice may
as well be an augmented version of network slice - an OTN slice, with
OTN-specific SLOs/SLEs, and is provided by an OTN slice controller. Section
2.5 of draft-zheng-ccamp-yang-otn-slicing describes how this scenario is to
be supported with different options, which, as agreed in the previous
comments, can be made clearer by both the descriptions and the figure.*

> The most obvious question is why the authors are clinging so desperately
> to the term "OTN slice"? After all it is just a term ( albeit very shiny
> these days). Why wouldn't  they just say: OK, you guys, find it a bit
> confusing. Let's come up with something  else. How about "OTN resource
> partition" or "OTN virtual network", as, I was told, SG12 folks did some 6
> years ago when they themselves killed the term "OTN slice" ( which was
> being used since 2010) precisely because of the unfortunate connotation of
> something OTN partitioning service offered to OTN clients was not.
>
> *[AG]  My understanding is the NS framework is targeted to solidify the
term slice in the scope of TEAS without further ambiguity. Any work built
on it inherits this nature of unambiguity. Frankly I do not see the
confusion for using the term slicing as long as it is in the scope of the
framework.*
*Personally I was not involved in the discussion in ITU-T SG12 (perhaps you
mean SG15) so I wouldn't be able to comment on your quote about that
decision. Will do some further investigation on that.*

> *[AG] Yes I think an interim meeting would be helpful. In addition, we
would welcome anyone interested in this work to join the weekly call on
each Thursday 10am-11am EST to discuss the comments.*

> Cheers,
> Igor
> <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature>
>
> On Wed, Jan 26, 2022 at 9:45 AM, Fatai Zhang
> <zhangfatai=[email-masked]> wrote:
>
> Hi all,
>
>
>
> We as the chairs made the decision to adopt the draft because there is
> lots of interest in this topic and the open comments have been clarified to
> some extent, and we’re arranging an interim just on this draft and the WG
> will decide if and how to update the draft according to mailing list
> discussion and interim discussions.
>
>
>
> Authors, please republish draft-zheng-ccamp-yang-otn-slicing-03  as
> draft-ietf-ccamp-yang-otn-slicing-00 with only the date and file name
> changed..
>
>
>
>
>
>
>
> Thanks,
>
>
>
> Fatai & Daniele
>
>
>
>
>
> *发件人:* CCAMP [mailto:[email-masked]] *代表 *Fatai Zhang
> *发送时间:* 2022年1月12日 10:24
> *收件人:* CCAMP <[email-masked]>
> *主题:* [CCAMP] WG adoption poll on draft-zheng-ccamp-yang-otn-slicing-03
>
>
>
> Hi all,
>
>
>
> All the IPR declarations regarding draft-zheng-ccamp-yang-otn-slicing-03
> have been collected, this starts the polling for WG adoption.
>
>
>
> Please send email to the list indicating "yes/support" or "no/do not
> support" and a motivation for your reply, mandatory for the "not support"
> and nice to have for the "support".
>
>
>
>
>
> Thanks,
>
>
>
> Fatai & Daniele
>
>
>
>
>
>

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 26 Jan 2022 22:06:44 +0000 (UTC)

Hi Aihua,
Apologies, it was Q12 (not SG12) that deprecated the term "OTN slice" 6 years ago.
Secondly, the problem with the term is because it is confusing,  and it is confusing because even within the same NS framework IP slice and OTN slice mean different things, both conceptually and functionality.

Here is an analogy. I am huge fan of European football.  Suppose I am an employer and whant to reward my employees with season seats in, say, the Ajax arena. I could do it in two ways:1) allocate several VIP boxes;2) buy N season tickets on common stands;
The former is OTN kind of slicing - VIP boxes make up a virtual stadium. You have keys to the boxes. You can seat anyone you want in the boxes.You can come on 75 min and still  will be guaranteed to have seats waiting for you.The latter is IP kind of slicing - the kind 5G folks are talking about. If you come on 75min. of a Champions League game, it is almost guaranteed that someone will be seating on your seat, unless a serious effort is put in place (invoking stadium personal) to resolve such conflicts in real time throughout the entire game. Do you agree with this analogy? Do you agree that VIP box allication and season ticket pirchase should not be called by the same name? You need resource allocation and presentation (topologies, virtual networks)  but not slicing in the layer where congestion and othe client's misbehavior is impossible. 
Cheers,Igor

  On Wed, Jan 26, 2022 at 2:16 PM, Aihua Guo<[email-masked]> wrote:   Hi Igor,
Please see my comments below.
Thanks,Aihua
On Wed, Jan 26, 2022 at 11:03 AM Igor Bryskin <i_bryskin=[email-masked]> wrote:

[AG] The comments above only quoted the first point in our reply, which states the fact that technology-specific slicing is in the scope of the framework for IETF network slicing and provides a base upon which OTN slicing can build (and augment). More importantly, as we presented in the last reply, there are use cases which require OTN technology-specific slices from an OTN-aware customer. The general use cases for these specific examples were already described in this draft. In addition, the NS framework indicates that an IETF NS may be combined hierarchically or sequentially, "so that a network slice may itself be sliced. They may also be combined sequentially so that various different networks can each be sliced and the network slices placed into a sequence to provide an end-to-end service". For OTN networks one such sub-slice may as well be an augmented version of network slice - an OTN slice, with OTN-specific SLOs/SLEs, and is provided by an OTN slice controller. Section 2.5 of draft-zheng-ccamp-yang-otn-slicing describes how this scenario is to be supported with different options, which, as agreed in the previous comments, can be made clearer by both the descriptions and the figure.

[AG]  My understanding is the NS framework is targeted to solidify the term slice in the scope of TEAS without further ambiguity. Any work built on it inherits this nature of unambiguity. Frankly I do not see the confusion for using the term slicing as long as it is in the scope of the framework.Personally I was not involved in the discussion in ITU-T SG12 (perhaps you mean SG15) so I wouldn't be able to comment on your quote about that decision. Will do some further investigation on that.

[AG] Yes I think an interim meeting would be helpful. In addition, we would welcome anyone interested in this work to join the weekly call on each Thursday 10am-11am EST to discuss the comments.

Cheers,Igor

  On Wed, Jan 26, 2022 at 9:45 AM, Fatai Zhang<zhangfatai=[email-masked]> wrote:    
Hi all,

 

 

 
Thanks,

Fatai & Daniele

 
Hi all,

 

 

Thanks,

Fatai & Daniele

---

From: Aihua Guo <[email-masked]>
Date: Thu, 27 Jan 2022 13:14:03 -0500

Hi Fatai, Daniele, WG,

Thank you for concluding the adoption call.
draft-ietf-ccamp-yang-otn-slicing-00 has been published to the WG.

In today's meeting, we have created a collection of comments received from
the mailing list, and plan to provide further responses for the interim
based on the replies already made on the mailing list. The list is tracked
as issue #25
<https://github.com/aguoietf/ietf-ccamp-yang-otn-slicing/issues/25> on
GitHub and also copied below for your reference:

   1.

   Harmonizing with [draft-ietf-teas-ietf-network-slice-nbi-yang]
   2.

   It would be helpful for the draft to reflect the fact that OTN-SC is
   just a “NS Realizer” for OTN networks.
   3.

   Harmonizing with [draft-ietf-teas-applicability-actn-slicing]
   4.

   Reduced frontpage author (#23
   <https://github.com/aguoietf/ietf-ccamp-yang-otn-slicing/issues/23>)
   5.

   Clarify relationship between an OTN slice and L1VPN
   6.

   Clarify relationship between an OTN slice and Abstract (TE) Topology
   7.

   Is there a need for OTN slicing? Some thought that slicing should stop
   at IP layer
   8.

   Is "OTN slicing" a conflated term, and should we call it "OTN resource
   partitioning" or "OTN virtual network"?
   9.

   Update the description and Fig. 2 for the 3 identified options. Explicit
   verbiage showing the options would be good for the reader.
   10.

   It would be helpful to show maybe in a section that how this additional
   OTN-SC the value and gains it provides that is not already provided by ACTN
   framework RFC 8453.
   11.

   It may be a good idea to add verbiage in the draft as to the OTN slice
   provisioning gap that exists for network slicing compared to ACTN
   provisioning of underlay VN Type 1 and Type 2 OTN resources.
   12.

   Minor changes to the text following section 1.3.2 of RFC 5921 (MPLS -->
   MPLS(-TP))

Thanks,
Aihua

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 27 Jan 2022 20:36:02 +0000 (UTC)

Hi Aihua,
Thanks for the summary of comments. One my question is still missing:
- in case of OTN slicing where the connectivity constructs defined by the NS framework,  such as P2MP, MP2MP will come from?
Cheers,Igor

  On Thu, Jan 27, 2022 at 1:14 PM, Aihua Guo<[email-masked]> wrote:   _______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Aihua Guo <[email-masked]>
Date: Thu, 27 Jan 2022 15:50:26 -0500

Hi Igor,

Thanks for catching it - added the question to the list now (#25
<https://github.com/aguoietf/ietf-ccamp-yang-otn-slicing/issues/25>)

Aihua

On Thu, Jan 27, 2022 at 3:36 PM Igor Bryskin <[email-masked]> wrote:

> - in case of OTN slicing where the connectivity constructs defined by the
> NS framework,  such as P2MP, MP2MP will come from?
>
> Cheers,
> Igor
>
> On Thu, Jan 27, 2022 at 1:14 PM, Aihua Guo
> <[email-masked]> wrote:

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 28 Jan 2022 13:50:49 +0000

Hi Aihua,

That’s an excellent work, it will make the interim much more profitable.
Thanks a lot.
It would be great to have a similar list/presentation from the part of the WG that believes that we should speak about OTN slicing but only applicability of OTN to network slicing.

Thanks,
Daniele

From: CCAMP <[email-masked]> On Behalf Of Aihua Guo
Sent: den 27 januari 2022 19:14
To: Fatai Zhang <zhangfatai=[email-masked]>
Cc: CCAMP <[email-masked]>
Subject: Re: [CCAMP] POLL CLOSED - WG adoption poll on draft-zheng-ccamp-yang-otn-slicing-03

Hi Fatai, Daniele, WG,

Thank you for concluding the adoption call. draft-ietf-ccamp-yang-otn-slicing-00 has been published to the WG.

In today's meeting, we have created a collection of comments received from the mailing list, and plan to provide further responses for the interim based on the replies already made on the mailing list. The list is tracked as issue #25<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-487ca34dd2925741&q=1&e=558326bf-5aa5-4c1a-bc50-0e4d1cac4cb3&u=https%3A%2F%2Fgithub.com%2Faguoietf%2Fietf-ccamp-yang-otn-slicing%2Fissues%2F25> on GitHub and also copied below for your reference:

  1.  Harmonizing with [draft-ietf-teas-ietf-network-slice-nbi-yang]
  2.  It would be helpful for the draft to reflect the fact that OTN-SC is just a “NS Realizer” for OTN networks.
  3.  Harmonizing with [draft-ietf-teas-applicability-actn-slicing]
  4.  Reduced frontpage author (#23<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-4792b329c1f7937d&q=1&e=558326bf-5aa5-4c1a-bc50-0e4d1cac4cb3&u=https%3A%2F%2Fgithub.com%2Faguoietf%2Fietf-ccamp-yang-otn-slicing%2Fissues%2F23>)
  5.  Clarify relationship between an OTN slice and L1VPN
  6.  Clarify relationship between an OTN slice and Abstract (TE) Topology
  7.  Is there a need for OTN slicing? Some thought that slicing should stop at IP layer
  8.  Is "OTN slicing" a conflated term, and should we call it "OTN resource partitioning" or "OTN virtual network"?
  9.  Update the description and Fig. 2 for the 3 identified options. Explicit verbiage showing the options would be good for the reader.
  10. It would be helpful to show maybe in a section that how this additional OTN-SC the value and gains it provides that is not already provided by ACTN framework RFC 8453.
  11. It may be a good idea to add verbiage in the draft as to the OTN slice provisioning gap that exists for network slicing compared to ACTN provisioning of underlay VN Type 1 and Type 2 OTN resources.
  12. Minor changes to the text following section 1.3.2 of RFC 5921 (MPLS --> MPLS(-TP))
Thanks,
Aihua

On Wed, Jan 26, 2022 at 9:45 AM Fatai Zhang <zhangfatai=[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Thanks,

Fatai & Daniele

发件人: CCAMP [mailto:[email-masked]<mailto:[email-masked]>] 代表 Fatai Zhang
发送时间: 2022年1月12日 10:24
收件人: CCAMP <[email-masked]<mailto:[email-masked]>>
主题: [CCAMP] WG adoption poll on draft-zheng-ccamp-yang-otn-slicing-03

Hi all,

Thanks,

Fatai & Daniele

_______________________________________________
CCAMP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ccamp