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

[Loa Andersson <[e-mail]>]

Gyan, Aihuu, et.al.,



On 23/01/2022 03:59, Gyan Mishra 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. 

Why is that MPLS/TP specific, woulodn't it wprk exactly the same if you 
wanted to establish VN Type 1 or Type 2 if the network on top of the 
GMPLS were MPLS?

/Loa

  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] 
> <mailto:[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]
>     <mailto:[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] <mailto:[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]
>             <mailto:[e-mail]>> *On Behalf Of *Fatai Zhang
> 
> 
>             *Sent:* 12 January 2022 02:24
>             *To:* CCAMP <[e-mail] <mailto:[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] <mailto:[e-mail]>
>             https://www.ietf.org/mailman/listinfo/ccamp
>             <https://www.ietf.org/mailman/listinfo/ccamp>
> 
>         -- 
> 
>         <http://www.verizon.com/>
> 
>         *Gyan Mishra*
> 
>         /Network Solutions A//rchitect /
> 
>         /Email [e-mail]
>         <mailto:[e-mail]>//
>         /
> 
>         /M 301 502-1347
> 
>         /
> 
> 
>         _______________________________________________
>         CCAMP mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/ccamp
>         <https://www.ietf.org/mailman/listinfo/ccamp>
> 
> -- 
> 
> <http://www.verizon.com/>
> 
> *Gyan Mishra*
> 
> /Network Solutions A//rchitect /
> 
> /Email [e-mail] <mailto:[e-mail]>//
> /
> 
> /M 301 502-1347
> 
> /
> 
> 
> 
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp

-- 
Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Bronze Dragon Consulting             phone: [phone]