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

[Aihua Guo <[e-mail]>]

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