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

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

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