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

[Vishnu Pavan Beeram <[e-mail]>]

Adrian,

I think the scope of the document as is stated in the current version of
the document is apt. I don't see the need to change it.
Please see inline for more..

Regards,
-Pavan

On Mon, Mar 7, 2022 at 5:50 AM Adrian Farrel <[e-mail]> wrote:

> Hi,
>
>
>
> I’m changing the subject line to extract a question from Igor’s email.
>
>
>
> With respect to whether “IETF Network Slices” are limited to use for 5G
> services, Igor asks, “it would be helpful if the framework identified
> clearer/narrower its focus.”
>
>
>
> What do other people think? Should the document state that slicing of IETF
> technology networks is intended only to support 5G network slicing as a
> “transport network slice”?
>

[VPB] No.

>
>
> My personal view is that Igor makes a very good point that “VPNs with
> SLOs” have been available as a matter of contractual negotiation between
> customers and service providers, but there has been no standard way of
> asking for this.
>

[VPB] I think there is no dispute that the notion of "VPNs with SLOs" has
been available for a while. And depending on the SLOs, one might even argue
that there are already standard ways for asking for this. If there is
anything that I have discerned from the discussion on this topic in the WG
in the past few years, it is that there has been a shift in the semantics
of SLOs/SLEs (more and more applications require stricter service
guarantees -- and this is not limited to 5G) and that there are gaps (in
the existing toolkit) in terms of how these newer and more complex services
are requested and catered to.


> Both enhanced VPN and network slicing make moves towards formalising this
> service.
>
>
>
> In fact, my interest in network slicing goes beyond 5G to consider all
> manner of service users that want complex connectivity services with
> service guarantees. I feel that enterprises, especially those supporting
> applications that need low latency (such as collaborative gaming or VR),
> will become consumers of network slice services.
>

>
Cheers,
>
> Adrian
>
>
>
> *From:* Igor Bryskin <[e-mail]>
> *Sent:* 07 March 2022 01:22
> *To:* [e-mail]; Gyan Mishra <[e-mail]>
> *Cc:* Adrian Farrel <[e-mail]>; Ogaki, Kenichi <
> [e-mail]>; [e-mail]; TEAS WG <[e-mail]>
> *Subject:* Re: [Teas] Upcoming changes to
> draft-ietf-teas-ietf-network-slices
>
>
>
> Hi Gyan,
>
>
>
> Thanks for the thoughtful and detailed response. Indeed, this is an
> important discussion.
>
>
>
> 1. IMHO IETF network slicing does not mean something wider than 5G network
> slicing. On the contrary, I'd argue it is narrower than 5G network slicing.
> It is  just a way to say that IETF cannot take care of 5G slicing end to
> end, rather, it can only focus on certain segments of 5G service (e.g. core
> network, back hawl, etc.), but not all (e.g. RAN).
>
>
>
> 2. The fact that things like VPN with SLOs existed as an idea for 20
> years, but is taken  on realization  only now, after 5G came along
> (requiring the same SLOs) does not mean that we are defining something that
> is not limited to 5G - nothing prevents any client to take advantage of
> some/all  functions of 5G network slicing. This is just a lucky  byproduct.
>
>
>
> 3. The outcome of this discussion may have consequences that are not
> entirely harmless. For e ample, as we see in CCAMP,  because the framework
> stipulates  IETF network slicing to be not only about 5G, folks are already
> working on things like OTN slicing, and soon will be working on microwave
> and all other transport layer slicing. Do we really want to go there?
>
>
>
> The bottom line: it would be helpful if the framework  indentified
> clearer/narrower its  focus.
>
>
>
> 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 Sun, Mar 6, 2022 at 7:07 PM, Gyan Mishra
>
> <[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
>