Re: [Teas] Decision point on scope of draft-ietf-teas-ietf-network-slices

[Gyan Mishra <[e-mail]>]

Hi Igor

I understand your point and some of us here were as well were on the OTN
slice discussion including both of us and Adrian.

https://datatracker.ietf.org/doc/html/draft-zheng-ccamp-yang-otn-slicing-03

I understand the issue with OTN slicing and maybe we can address that with
the OTN authors regarding top down versus bottom up approach- understood
and agreed as I recall that mentioned in the thread.

So OTN is one concern which I can understand the reasoning.

What is the issue with IP VPN taking being in scope for Enhanced VPN?

Hypothetically if we made an explicit permit making all IP VPN use cases in
scope followed by an explicit deny of any other use cases would that
satisfy your concerns?

Another way to word it would be  Non IP networks are forbidden.

Kind Regards

Gyan
On Mon, Mar 7, 2022 at 10:43 AM Igor Bryskin <i_bryskin=
[e-mail]> wrote:

> Hi Gyan,
>
> IMHO network slicing is inherently top-down emerging process aiming at
> realization of various connectivity constructs of different types and
> complexity levels that guarantee agreed upon SLOs through the lifetime of a
> network slice.  OTN, being a transport layer, can only offer bottom-up
> network building capabilities via realization of p2p data links for higher
> layer clients. This is the only thing a transport layer has been doing and
> is expected to be doing in the NS framework.
>
> Consider, for example, an application requiring a p2mp distribution and
> asking for a network slice. While implementing required slice, network's IP
> layer may request help from the underlying OTN, but this help should not be
> understood IMHO as OTN slicing (which would be the case, for example, if IP
> layer was attempting to map the required p2mp tree onto a p2mp connection
> established in OTN). Rather, IP, when seeing that it does not have enough
> resources in IP layer to satisfy the request, may ask from the OTN (and not
> just one OTN, because IP may span multiple independent OTN networks and not
> just OTNs, but transport networks of different types, including not
> involving OTN layer at all, but other transports such as FlexE, microwave,
> etc.) to enrich the IP topology with additional IP links supported by the
> underlying transport layer tunnels. Such additions are not OTN (or other
> transport) slices, rather, they are additional NRPs (Network Resource
> Partitions) as Pavan's, Tarek's and Co. ns-packet-slicing draft correctly
> defines.
>
> So, yes, I do not like the idea of OTN slicing, which, incidentally has
> nothing to do with 5G.
>
> Cheers,
> Igor
>
> 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 Mon, Mar 7, 2022 at 10:24 AM, Igor Bryskin
> <i_bryskin=[e-mail]> wrote:
>
> Pavan,
>
> What makes you think that what we have been discussing so far goes beyond
> 5G needs? Specifically,  which exactly connectivity types, SLOs, SLEs, etc.
> discussed so far will not be required by 5G?
>
> Lack of focus on 5G, on the other hand, creates confusion. Tell me:
> what does it mean to guarantee SLO or SLE? 5G has a very clear definition
> of that.
>
>  Is a bunch of OTN tunnels is a netwrk slice, NRP, bottom up network
> building option, all of the above, none of the above? Which connectivity
> service is definitely not a slice?
>
> Igor
>
> 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 Mon, Mar 7, 2022 at 9:56 AM, Igor Bryskin
> <i_bryskin=[e-mail]> wrote:
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*