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

[Gyan Mishra <[e-mail]>]

Hi Aihua

Very welcome.

Comments in-line

On Mon, Jan 24, 2022 at 12:03 PM Aihua Guo <[e-mail]> wrote:

> Hi Gyan,
>
> Thanks for your comments.
>

   Gyan> Ack

>
I agree with your observation that OTN-SC is "taking the higher layer IETF
> network slice provisioning modeland trying to augment and realize the
> overall solution realizing the underlay OTN slice leveraging the existing
> ACTN framework".
>

    Gyan> Ack

>
> The use of OTN-SC is also in line with the IETF network slice framework
> defined in draft-ietf-teas-ietf-network-slices-05, which states that, "an
> IETF NS may be combined hierarchically, 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".  I did not see it mentioned but maybe
> add reference to the verbiage above in the draft and help provide reasoning
> for using the word “slice”.
>

    Gyan> Understood

In this case, OTN-SC serves as a sub-slice controller to the IETF NSC for
> provisioning OTN slices in underlying OTN domains to support end-to-end
> network slicing. Section 2.5 of draft-zheng-ccamp-yang-otn-slicing
> describes this scenario, which can be made clearer based on your
> suggestions.
>

    Gyan> Thank you

>
> I also agree that it would be beneficial for this draft to clearly mark
> the different options provided by the OTN-SC in both the descriptions and
> the picture, as you suggested below. Will incorporate those improvements in
> the next draft revision.
>

    Gyan> That would be very helpful for the reader as well as clearly
defining the OTN slice specification.

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


> Thanks,
> Aihua
>
> On Sat, Jan 22, 2022 at 3:00 PM Gyan Mishra <[e-mail]> wrote:
>
>> Hi Aihua
>>
>> From a layering perspective and integration into TEAS IETF NS,  the
>> technology agnostic IETF NSC provisions the Network slice and interfaces
>> with RFC 8453 ACTN for provisioning of the abstraction of control functions
>> of underlay GMPLS In MPLS-TP transport domains VN Type 1 or Type 2 resource
>> based slice using MDSC and PSC controllers.  So with this draft we are
>> creating another layer -technology specific OTN-SC which  sits at the
>> southbound of the ACTN controller. Correct?
>>
>> The OTN-SC interfaces at the southbound using the MDSC-to-PNC interface
>> (MPI) with a Physical Network Controller (PNC)
>>
>> or Multi-Domain Service Orchestrator (MDSC), as defined in the ACTN control framework [RFC8453 <https://datatracker.ietf.org/doc/html/rfc8453>].  The logical function within the OTN-SC is responsible for translating the OTN slice requests intoconcrete slice realization which can beunderstood and provisioned at the
>> southbound by the PNC or MDSC.
>>
>>
>> So this is another provisioning layer being added that directly interfaces between ACTN PNC / MSDC and the physical OTN underlay optical layer DWDM equipment.
>>
>>
>> I do think the term “slice” being used is very confusing but I see now that it’s taking the higher layer IETF network slice provisioning model
>>
>> and trying to augment and realize the overall solution realizing the underlay OTN slice leveraging the existing ACTN framework.
>>
>>
>> So the question in my mind is if the additional OTN-SC layer is necessary or not?
>>
>>
>> Responses In-line
>>
>>
>> Kind Regards
>>
>>
>> Gyan
>>
>>
>> On Fri, Jan 21, 2022 at 2:07 PM Aihua Guo <[e-mail]>
>> wrote:
>>
>>> Hi Gyan,
>>>
>>> I'd agree with you and Adrian that a technology-agnostic network
>>> slicing, i.e. IETF NS can be used to specify slice requests regardless of
>>> underlay network technologies - whether it being IP or OTN. Actually, in
>>> draft-zheng-ccamp-yang-otn-slicing, Figure 2 describes the support for this
>>> scenario with multiple options, as shown below:
>>>
>>
>>    Gyan>  Section 3 describes the framework of network slicing but I
>> don’t see the three options as you have listed below.  Or is this embedded
>> in the Yang models.  Explicit verbiage showing the options would be good
>> for the reader.
>>
>>>
>>>                          +--------------------+
>>>
>>>                          | Provider's User    |
>>>
>>>                          +--------|-----------+
>>>
>>>                                   | CMI
>>>
>>>           +-----------------------+----------------------------+
>>>
>>>           |          Orchestrator / E2E Slice Controller       |
>>>
>>>           +------------+-----------------------------+---------+
>>>
>>>                        |                             | NSC-NBI
>>>
>>>                        |       +---------------------+---------+
>>>
>>>                        |       | IETF Network Slice Controller |
>>>
>>>                        |       +-----+---------------+---------+
>>>
>>>                        |*option3*      |*option 2*       |
>>>
>>>                        | OTN-SC NBI  |OTN-SC NBI     |
>>>
>>>           +------------+-------------+--------+      | *option 1*
>>>
>>>           |               OTN-SC              |      |
>>>
>>>           +--------------------------+--------+      |
>>>
>>>                                      | MPI           | MPI
>>>
>>>           +--------------------------+---------------+---------+
>>>
>>>           |                         PNC                        |
>>>
>>>           +--------------------------+-------------------------+
>>>
>>>                                      | SBI
>>>
>>>                          +-----------+----------+
>>>
>>>                          |OTN Physical Network  |
>>>
>>>                          +----------------------+
>>>
>>>
>>>
>>> *Option 1:* the IETF NSC receives a technology-agnostic slice request,
>>> it uses MPI to realize the slice on PNC using available mechanisms, such as
>>> L1VPN, abstract TE topologies, TE tunnels, or any proprietary technologies
>>> the controller chooses to use. In this case, the OTN-SC NBI is not used.
>>>
>>>  Gyan> Understood.  Where is this option defined what section.
>>>
>>> *Option 2:* the IETF NSC receives a technology-agnostic slice request
>>> and delegates the request to the OTN-SC by using the OTN slicing interface
>>> at the OTN-SC NBI. The OTN-SC NBI is technology specific and augments the
>>> IETF NSC NBI. Therefore, the IETF NSC request to OTN-SC can be either
>>> technology agnostic or OTN specific depending on the realization of IETF
>>> NSC. The OTN-SC will in turn work with the PNC and realize the slice. In
>>> this option, OTN-SC is essentially a subordinate slice controller of the
>>> IETF NSC which also meets the hierarchical nature of slice control as
>>> described in the network slice framework document.
>>>
>>> Gyan> Understood.  I see that in section 3.  I think the confusion is
>>> that IETF network slice is technology agnostic and the OTN-SC is OTN
>>> technology specific.  Also question as to whether this additional layer
>>> interfacing with OTN to realize the IETF network slice is necessary or is
>>> it adding unnecessary complexity in provisioning the IETF network slice.
>>>
>>> Both Option 1 and Option 2 are in line with the view that a customer can
>>> request a technology-agnostic NS and the IETF-NSC can realize the slice in
>>> its underlay networks whether it being OTN or packet.
>>>
>>>
>>> Additionally, *Option 3: * a customer who is OTN-aware may use the
>>> augmented OTN-SC NBI to request an OTN slice with OTN-specific SLOs (e.g.
>>> BER, bandwidth in terms of the # of time slots), and the OTN SC realizes
>>> the slice by working with the underlying PNC(s) in single- or multi-domain
>>> network scenarios. Several use cases for option 3 are also described in the
>>> draft.
>>>
>>> Gyan> Where is Option 3 verbiage in the draft.  I don’t see it in
>>> section 3.  I think labeling the options would be helpful and maybe with a
>>> diagram.
>>>
>>> To summarize, the OTN slicing model provides a service-intent interface
>>> that supports the configuration of OTN slices, which can be realized by the
>>> OTN-SC controller in various ways. The OTN SC also allows an OTN-aware
>>> customer to create OTN slices with OTN-specific SLOs.
>>>
>>> Gyan> I think what 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.
>>>
>>> I hope the above clarification could be helpful. Authors are open to
>>> make further clarifications in the document to align with the framework of
>>> IETF network slicing.
>>>
>>>  Gyan> Many Thanks for the clarifications.  Thank you for reviewing my
>>> comments.
>>>
>>> Thanks,
>>>
>>> Aihua
>>>
>>> On Fri, Jan 21, 2022 at 3:26 AM Gyan Mishra <[e-mail]>
>>> wrote:
>>>
>>>>
>>>> Hi Adrian
>>>>
>>>> I agree with all your comments related to this draft especially the
>>>> complexity with this approach as compared to ACTN architecture.  One
>>>> critical  point you make is that the slice service should be independent of
>>>> underlay technology.  As OTN is a component of the underlay it goes against
>>>> the agnostic slice approach taken with IETF Network Slice.
>>>>
>>>> Others have mentioned the same related to underlay technology slice
>>>> added complexity and does that mean a different  slice Yang model for each
>>>> L1 Technology “Bottoms Up” approach. 😁
>>>>
>>>> Comments in-line
>>>>
>>>> Kind Regards
>>>>
>>>> Gyan
>>>>
>>>> On Thu, Jan 13, 2022 at 12:20 PM Adrian Farrel <[e-mail]>
>>>> wrote:
>>>>
>>>>> Hi Fatai, Daniele,
>>>>>
>>>>>
>>>>>
>>>>> I think that CCAMP should work on YANG models for slicing OTN
>>>>> networks. I think that this draft forms a starting point and should be
>>>>> adopted, but like Igor, “I have questions”.
>>>>>
>>>>>  Gyan>  I support WG adoption and I think all the comments mentioned
>>>>> can be addressed.
>>>>>
>>>>> So, my support for adoption is heavily conditional on the authors not
>>>>> believing that the approach used in the draft is fixed. (This is normal,
>>>>> but it is worth highlighting in view of my thoughts, below).
>>>>>
>>>>>
>>>>>
>>>>> I am particularly interested to look at harmonising this work with
>>>>> draft-ietf-teas-applicability-actn-slicing and
>>>>> draft-ietf-teas-ietf-network-slice-nbi-yang
>>>>> <https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slice-nbi-yang/>
>>>>> (I appreciate the work the authors have done to synchronise with
>>>>> draft-ietf-teas-ietf-network-slices).
>>>>>
>>>>      Gyan> Agreed
>>>>
>>>> I think one question here is whether the “slice request” interface
>>>>> shouldn’t actually be built on
>>>>> draft-ietf-teas-ietf-network-slice-nbi-yang
>>>>> <https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slice-nbi-yang/>
>>>>> (i.e. top down, not bottom up as currently).
>>>>>
>>>>     Gyan> Agreed.
>>>>
>>>> The point being that “The definition of an IETF Network Slice Service
>>>>> is independent of the connectivity and technologies used in the underlay
>>>>> network” [draft-ietf-teas-ietf-network-slices] meaning that the NBI in this
>>>>> model could be a technology-specific augmentation of
>>>>> draft-ietf-teas-ietf-network-slice-nbi-yang
>>>>> <https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slice-nbi-yang/>
>>>>> .
>>>>>
>>>>>     Gyan> Agreed
>>>>
>>>>> Another question is why there is the need to introduce the complexity
>>>>> of interfaces and controllers shown in Figure 2, when Figure 1 of draft-ietf-teas-applicability-actn-slicing
>>>>> considers a more simple mapping between the slicing and ACTN architectures.
>>>>> That is, why does the CMI appear as different from the OTN-SC NBI and the
>>>>> NSC NBI?
>>>>>
>>>>    Gyan> Completely Agree.  ACTN mapping is a much simpler mapping.
>>>>
>>>>> We might also debate the meaning of “E2E Slice Controller” since this
>>>>> term is not mentioned anywhere except in Figure 2 and only appears once in draft-ietf-teas-ietf-network-slices
>>>>> (in Figure 2) that appears to have escaped being cleaned up.
>>>>>
>>>>>
>>>>>
>>>>> But, I think these are questions that can be easily resolved in
>>>>> discussions within the WG, so adoption should be safe.
>>>>>
>>>>>  Gyan> Agreed
>>>>>
>>>>> Best,
>>>>>
>>>>> Adrian
>>>>>
>>>>>
>>>>>
>>>>> PS. At some stage the AD is going to ask, “Please find a way to reduce
>>>>> the front page authors to 5 or fewer.” Experience suggests that it is
>>>>> easier to do this sooner rather than later, and it is better if the authors
>>>>> resolve that rather than requiring the chairs to force the point.
>>>>>
>>>>>
>>>>>
>>>>> *From:* CCAMP <[e-mail]> *On Behalf Of *Fatai Zhang
>>>>>
>>>>>
>>>>> *Sent:* 12 January 2022 02:24
>>>>> *To:* CCAMP <[e-mail]>
>>>>> *Subject:* [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
>>>>>
>>>> --
>>>>
>>>> <http://www.verizon.com/>
>>>>
>>>> *Gyan Mishra*
>>>>
>>>> *Network Solutions A**rchitect *
>>>>
>>>> *Email [e-mail] <[e-mail]>*
>>>>
>>>>
>>>>
>>>> *M 301 502-1347*
>>>>
>>>> _______________________________________________
>>>> CCAMP mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>
>>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions A**rchitect *
>>
>> *Email [e-mail] <[e-mail]>*
>>
>>
>>
>> *M 301 502-1347*
>>
>> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*