Re: [Teas] Upcoming changes to draft-ietf-teas-ietf-network-slices

[Gyan Mishra <[e-mail]>]

Hi Adrian

As this is an interesting topic here are some thoughts for the framework
draft, talking to the important point that you make that IETF Network Slice
may have not just been for 5G but many use cases and from below I think pre
existing use cases.

So I would like to elaborate as I agree with you.

So basic concept of virtualization of a physical infrastructure started
decades ago with the concept of a VLAN ( Virtual LAN) and then transport
layer virtualization with ATM and Frame Relay concept of a LIS (Logical IP
Subnet) followed by MPLS/IP VPN RFC 4364 which gave us a virtualization of
the physical infrastructure traditional single customer  global table
routing to VPN overlay multi tenancy capabilities.  So RFC 4364 gave us the
ability to slice up the physical infrastructure allowing for multi tenancy
overlay virtualization.  RSVP-TE gave us the ability to steer traffic and
VPN to TE mapping basically providing a VPN overlay slice to be underpinned
to a discrete TE underlay path.  ACTN has further extended that capability
providing an abstraction TE controls into a Type 1 and 2 VN Network Slice.

I believe the concept of network slicing and VPN overlay underpinning to a
discrete underlay has been further extended with Segment Routing and SR-TE
capabilities to extend past VRF to RSVP-TE mapping to micro and macro flow
path steering moving the VPN overlay to underlay underpinning capabilities
of “network slicing” further along.

So the framework draft does mention in section 1.1 below ..

“ Driven largely by needs surfacing from 5G, the concept of network slicing
has gained traction ([NGMN-NS-Concept
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-07#ref-NGMN-NS-Concept>],
[TS23501
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-07#ref-TS23501>],
and [TS28530
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-07#ref-TS28530>
]).”

So the IETF network slice is a network slice that describes Technologies
standardized by the IETF to narrow the scope.

So in reality the concept of “network slicing” has been around  for
decades.

A key ingredient to IETF network slicing is RFC 4364 MPLS/IP VPN overlay
virtualization layer which has been around for decades used ubiquitously by
operators worldwide.

The framework of an IETF network slice and connectivity matrix is based on
the use of MPLS/IP VPN least common denominator overlay virtualization that
has existed for decades.

So now coming back full circle, which came first chicken or the egg - “5G
driving network slicing” or has has network slicing been a pre existing
condition that we are now fine tuning with discrete underlay resource
provisioning to accommodate 5G Network slicing being in-line with those 5G
 requirements, and then can as well to your point continue on with all the
pre existing condition use cases for network slicing that exists but now
being able to provide “IETF Network Slice” parity that has been developed
to be in sync with 5G network slicing requirements for operators, but now
also being able to reuse the IETF Network Slice for all pre existing
conditions of network slicing that have existed well before 5G came along.

Another thought is that IETF network slice is Technology agnostic, however
as there are requirements for each technology such as for example 3GPP,
thus parity must be maintained.  So it’s like Technology agnostic with a
caveat of dependence on the technology as far as parity as we see with 3GPP
SDO.

Many Thanks


Gyan

On Fri, Mar 4, 2022 at 6:43 PM Gyan Mishra <[e-mail]> wrote:

> Hi Kenichi / All
>
> Good point to bring up the 3GPP standards and development related to
> Network slicing within 3GPP.
>
> As TEAS WG is defining the framework for Network Slicing, how is parity
> maintained between two different SDOs, IETF and 3GPP on this common topic
>  of Network Slicing?
>
> I know we have other development areas such as optical for example where
> we have overlap between SDOs.
>
> I believe we do have an IETF to 3GPP liaison related to 3GPP development
> to keep abreast on developments works on either SDO.  But I wonder if let’s
> say our TEAS Network Slicing development work is being communicated to the
> 3GPP developers.
>
> As 3GPP 5G would be the major consumer of network slicing,  how do we keep
> the development synchronized as well not be divergent and contradictory.
>
> Worst would be if the work we are doing here is done in vain if the work
> is not being incorporated into the 3GPP standards.
>
> Kind Regards
>
> Gyan
>
> On Thu, Mar 3, 2022 at 11:18 PM Ogaki, Kenichi <[e-mail]> wrote:
>
>> Hi All,
>>
>> Interesting discussion.
>>
>> FYI, 3GPP defines slice SLOs as ServiceProfile in TS28.541 Clause
>> 6.3.3[1], which basically refers GSMA GST, NG.116[2].
>> Both specifications define "availability".
>>
>> NG.116 Clause 3.4.1 Availability
>> (Communication service) availability: percentage value of the amount of
>> time the end-to-end communication service is delivered according to an
>> agreed QoS, divided by the amount of time the system is expected to deliver
>> the end-to-end service according to the specification in a specific area,
>> see also 3GPP TS 22.261 [27].
>>
>> We understand that this means the confidence which satisfies *all*
>> (other) SLOs, e.g. throughput, latency, etc..., and should be negotiated
>> with the customer as SLA.
>> So, we believe any one of SLOs violates the value against "availability",
>> then that falls to penalty.
>>
>> Mission critical usecases like factory automation or AVG control may not
>> fit percentile SLO, since there may be a strict requirement, e.g. maximum
>> latency or deterministicy, for the application to properly work.
>>
>> [1]
>> https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3400
>> [2]https://www.gsma.com/newsroom/wp-content/uploads//NG.116-v5.0-7.pdf
>>
>> All the best,
>> Kenichi
>>
>> Get Outlook for iOS <https://aka.ms/o0ukef>
>> ------------------------------
>> *From:* Teas <[e-mail]> on behalf of Adrian Farrel <
>> [e-mail]>
>> *Sent:* Thursday, March 3, 2022 6:17 PM
>> *To:* [e-mail]; 'Joel M. Halpern'; 'Igor Bryskin';
>> 'TEAS WG'
>>
>> *Subject:* Re: [Teas] Upcoming changes to
>> draft-ietf-teas-ietf-network-slices
>>
>> OK. Useful discussion. I think that the slicing framework definition of
>> SLA ...
>>
>>    *  A Service Level Agreement (SLA) is an explicit or implicit
>>       contract between the customer of an IETF Network Slice service and
>>       the provider of the slice.  The SLA is expressed in terms of a set
>>       of SLOs and SLEs that are to be applied for a given connectivity
>>       construct between a sending SDP and the set of receiving SDPs, and
>>       may include commercial terms as well as any consequences for
>>       violating these SLOs and SLEs.
>>
>> ...can be extended by a view words to include "the extent to which
>> divergence from individual SLOs and SLEs can be tolerated"
>>
>> But I don't think we should go further than that in the framework.
>>
>> A
>>
>> -----Original Message-----
>> From: Teas <[e-mail]> On Behalf Of
>> [e-mail]
>> Sent: 03 March 2022 08:23
>> To: Joel M. Halpern <[e-mail]>; Igor Bryskin <
>> [e-mail]>; TEAS WG <[e-mail]>
>> Subject: Re: [Teas] Upcoming changes to
>> draft-ietf-teas-ietf-network-slices
>>
>> Hi all,
>>
>> Agree with Joel.
>>
>> I don't think that slicing comes with specifics on how these matters are
>> already handled in IP services. A randomly picked example can be found
>> here: https://www.cyberlynk.net/company-information/legal/ip-transit-sla/
>>
>> However, the slice modeling should be designed with provisions so that
>> advanced SLAs can be built.
>>
>> For example, draft-ietf-teas-ietf-network-slice-nbi-yang includes
>> attributes that are characterized with their max values, e.g.,
>>
>>       "network-slice-slo-one-way-latency": Indicates the maximum one-way
>>       latency between two NSE.
>>
>>       "network-slice-slo-two-way-latency": Indicates the maximum round-
>>       trip latency between two NSE.
>>
>> I suggest to consider updating the model to manipulate percentile values,
>> not only peak/min/avg values.
>>
>> Cheers,
>> Med
>>
>> > -----Message d'origine-----
>> > De : Teas <[e-mail]> De la part de Joel M. Halpern
>> > Envoyé : jeudi 3 mars 2022 01:12
>> > À : Igor Bryskin <[e-mail]>; TEAS WG <[e-mail]>
>> > Objet : Re: [Teas] Upcoming changes to draft-ietf-teas-ietf-network-
>> > slices
>> >
>> > The tolerances are likely to be different.  The SLA will have multiple
>> > terms.  I imagine (and my imagination is bad) terms of the form "for
>> > traffic set X, for parameter Y, the SLO is Z, and it will be met with
>> > confidence P, and penalty M."  Penalty might be separate with all sorts
>> > of complicated relationships between failures and penalties.
>> >
>> > Yours,
>> > Joel
>> >
>> > On 3/2/2022 7:09 PM, Igor Bryskin wrote:
>> > > I agree, but what if the tolerance is different wrt different SLOs
>> > > within the same SLA?
>> > >
>> > > Igor
>> > >
>> > > Sent from Yahoo Mail on Android
>> > > <
>> https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrow
>> > > th_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Glo
>> > > bal_YGrowth&af_sub3=EmailSignature>
>> > >
>> > >     On Wed, Mar 2, 2022 at 7:03 PM, Joel M. Halpern
>> > >     <[e-mail]> wrote:
>> > >     I think that is part of the difference between the SLO and the
>> > SLA.
>> > >     The
>> > >     SLO is an objective.  It may have measurement windows (e.g.
>> > average
>> > >     latency variation over 1 second periods).  It is either met or
>> > failed.
>> > >     The question of how often the operator commits to meeting it
>> > >     (90%...99.999%) and what happens if he fails too much are for the
>> > SLA,
>> > >     not the SLO as I understand them.
>> > >
>> > >     Yours,
>> > >     Joel
>> > >
>> > >     On 3/2/2022 6:53 PM, Igor Bryskin wrote:
>> > >      > Hi Adrian,
>> > >      > Good job!
>> > >      >
>> > >      > I wonder if we need a discussion on what does it mean exactly
>> > to
>> > >      > guarantee an SLO. Imagine that one of a NS service SLOs is not
>> > >     being met
>> > >      > once in a month for 10ms. Is this acceptabl? The answer could
>> > >     depend on
>> > >      > a client. For example.  IPTV client could be OK with that,
>> > while
>> > >     Remote
>> > >      > Surgery application client may be not.  The tolerance to the
>> > >     divergence
>> > >      > from an agreed upon SLO could be different from SLO to SLO
>> > .  So my
>> > >      > question is would it be a good idea to couple each SLO with SLO
>> > >      > divergence tolerance?
>> > >      >
>> > >      > Thanks,
>> > >      > Igor
>> > >      >
>> > >      > Sent from Yahoo Mail on Android
>> > >      >
>> > >
>> > <
>> https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth
>> > _AndroidEmailSig__AndroidUsers⁡_wl=ym⁡_sub1=Internal⁡_sub2=Global_YGrowt
>> > h⁡_sub3=EmailSignature
>> > >
>> > <
>> 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 Wed, Mar 2, 2022 at 5:20 PM, Jeff Tantsura
>> > >      >    <[e-mail] <mailto:[e-mail]
>> <[e-mail]>>>
>> > wrote:
>> > >      >    _______________________________________________
>> > >      >    Teas mailing list
>> > >      > [e-mail] <mailto:[e-mail] <[e-mail]>> <mailto:
>> [e-mail]
>> > >     <mailto:[e-mail] <[e-mail]>>>
>> > >      > https://www.ietf.org/mailman/listinfo/teas
>> > >     <https://www.ietf.org/mailman/listinfo/teas>
>> > >      >    <https://www.ietf.org/mailman/listinfo/teas
>> > >     <https://www.ietf.org/mailman/listinfo/teas>>
>> > >      >
>> > >      >
>> > >      > _______________________________________________
>> > >      > Teas mailing list
>> > >      > [e-mail] <mailto:[e-mail] <[e-mail]>>
>> > >      > https://www.ietf.org/mailman/listinfo/teas
>> > >     <https://www.ietf.org/mailman/listinfo/teas>
>> > >
>> > >
>> > >     _______________________________________________
>> > >     Teas mailing list
>> > >     [e-mail] <mailto:[e-mail] <[e-mail]>>
>> > >     https://www.ietf.org/mailman/listinfo/teas
>> > >     <https://www.ietf.org/mailman/listinfo/teas>
>> > >
>> >
>> > _______________________________________________
>> > Teas mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/teas
>>
>>
>> _________________________________________________________________________________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations
>> confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>> recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>> electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme
>> ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or privileged
>> information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and
>> delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have
>> been modified, changed or falsified.
>> Thank you.
>>
>> _______________________________________________
>> Teas mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/teas
>>
>> _______________________________________________
>> 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*
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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



*M 301 502-1347*