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

["Joel M. Halpern" <[e-mail]>]

Igor, you know better.  If youa re asking for a service to deliver IP or 
Ethernet packets, what would you do with a walnut?

Yours,
Joel

On 1/21/2022 4:49 PM, Igor Bryskin wrote:
> Question: if I am to ask for a slice of a 3 layer cake with raspberries 
> at the top, walnuts in the middle and pineapple at the bottom ( for 
> SLOs) do I send the request to one or three separate places? If the 
> latter, how do I know where from and from how many places the kitchen 
> gets its walnuts?
> 
> 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 Fri, Jan 21, 2022 at 3:00 PM, Joel M. Halpern
>     <[e-mail]> wrote:
>     Under what circumstance, even if the customer knows (out of band) that
>     the operator has OTN capability) would the customer somehow specify OTN
>     specifics as part of requesting an end-to-end network slice (which
>     inherently has to traverse more than the OTN?)
> 
>     Yours,
>     Joel
> 
>     On 1/21/2022 2:07 PM, Aihua Guo 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:
>      >
>      >                           +--------------------+____
>      >
>      >                           | 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.__
>      >
>      > __ __
>      >
>      > */_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.
>      >
>      > __
>      >
>      > __ __
>      >
>      > 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.
>      >
>      >
>      > 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.
>      >
>      > __ __
>      >
>      > 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.__
>      >
>      > __ __
>      >
>      > Thanks,____
>      >
>      > Aihua
>      >
>      >
>      > On Fri, Jan 21, 2022 at 3:26 AM Gyan Mishra
>     <[e-mail] <mailto:[e-mail]>
>      > <mailto:[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]>
>      >    <mailto:[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/
>     <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/
>     <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/
>     <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]>
>      >        <mailto:[e-mail]
>     <mailto:[e-mail]>>> *On Behalf Of *Fatai Zhang
>      >
>      >
>      >        *Sent:* 12 January 2022 02:24
>      >        *To:* CCAMP <[e-mail] <mailto:[e-mail]>
>     <mailto:[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]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      > https://www.ietf.org/mailman/listinfo/ccamp
>     <https://www.ietf.org/mailman/listinfo/ccamp>
>      >        <https://www.ietf.org/mailman/listinfo/ccamp
>     <https://www.ietf.org/mailman/listinfo/ccamp>>
>      >
>      >    --
>      >
>      >    <http://www.verizon.com/ <http://www.verizon.com/>>
>      >
>      >    *Gyan Mishra*
>      >
>      >    /Network Solutions A//rchitect /
>      >
>      >    /Email [e-mail]
>     <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>//
>      >    /
>      >
>      >    /M 301 502-1347
>      >
>      >    /
>      >
>      >
>      >    _______________________________________________
>      >    CCAMP mailing list
>      > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
> 
>      > https://www.ietf.org/mailman/listinfo/ccamp
>     <https://www.ietf.org/mailman/listinfo/ccamp>
>      >    <https://www.ietf.org/mailman/listinfo/ccamp
>     <https://www.ietf.org/mailman/listinfo/ccamp>>
>      >
>      >
>      > _______________________________________________
>      > CCAMP mailing list
>      > [e-mail] <mailto:[e-mail]>
>      > https://www.ietf.org/mailman/listinfo/ccamp
>     <https://www.ietf.org/mailman/listinfo/ccamp>
> 
>     _______________________________________________
>     CCAMP mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/ccamp
>     <https://www.ietf.org/mailman/listinfo/ccamp>
>