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

[Igor Bryskin <[e-mail]>]

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 
 
  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]>> 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>
> 
> 
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp

_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp