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

[Aihua Guo <[e-mail]>]

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]> 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
>