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

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

It strikes me that we are abusing the term network slice rather badly 
across all of our use cases.

What you describe is an OTN service.  I has little or nothing to do with 
end-to-end network slicing.  (It can, of course, be used to fulfill 
portions of an end-to-end network slice, but so can lots of things.)

What you describe sound useful.  Wouldn't we be better of if we 
described it as what it is, rather than conflating it with IETF network 
slice (technology agnostic) or worse end-to-end network slices?

Yours,
Joel

On 1/21/2022 9:24 PM, Aihua Guo wrote:
> Hi Joel,
> 
> Thanks for your comments.
> 
> Section 2 of draft-zheng-ccamp-yang-otn-slicing describes several use 
> cases where a customer would potentially request an OTN slice with 
> OTN-specific SLOs. For example, in the use case for wholesale of optical 
> resources, a local OTN operator (as a customer) may rent from a large 
> global operator an OTN slice to serve its own traffic needs. The 
> connectivity between the two operators are OTN CE-PE and the OTN slice 
> is expected to meet specific OTN SLO requirements, such as bandwidth in 
> terms of # and types of ODU containers, and service performance in terms 
> of bit error rates.
> 
> Thanks,
> Aihua
> 
> On Fri, Jan 21, 2022 at 2:59 PM Joel M. Halpern <[e-mail] 
> <mailto:[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>
>