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

[Igor Bryskin <[e-mail]>]

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

Sent from Yahoo Mail on Android 
 
  On Wed, Jan 26, 2022 at 2:16 PM, Aihua Guo<[e-mail]> wrote:   Hi Igor,
Please see my comments below.
Thanks,Aihua
On Wed, Jan 26, 2022 at 11:03 AM Igor Bryskin <i_bryskin=[e-mail]> 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.


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.

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


In short, I still like the Daniele's proposal of interim meeting.

[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


Sent from Yahoo Mail on Android 
 
  On Wed, Jan 26, 2022 at 9:45 AM, Fatai Zhang<zhangfatai=[e-mail]> wrote:    
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:[e-mail]]代表 Fatai Zhang
发送时间: 2022年1月12日 10:24
收件人: CCAMP <[e-mail]>
主题: [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
 
  
 
  
 
  
 _______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp
  
  
_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp