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

[Gyan Mishra <[e-mail]>]

Hi Kenichi

This hierarchical or top down approach topic came up on CCAMP when
discussing adoption call for  OTN slice draft below.

OTN Slicing

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


https://mailarchive.ietf.org/arch/msg/ccamp/DBmtlsuO5nszXJ1g5rDpij8Q6aA/

In the discussion the IETF slice top down approach was mentioned by Adrian
versus the bottom up approach by OTN slice which I mention in the thread.

I believe in that thread at the end of the discussion that Optical as well
as 3GPP or any other technology from any SDO could adapt to the top down
approach.

Responses in-line

Kind Regards

Gyan

On Mon, Mar 7, 2022 at 2:15 AM Ogaki, Kenichi <[e-mail]> wrote:

> Hi Gyan,
>
>
>
> >    Gyan> Agreed.  Good point.  As far as Super set thinking in a
> hierarchical terms or independent layering that have dependencies.  In
> terms of hierarchy IETF sits at the top layer and underneath would sit the
> individual Technologies such as 3GPP, Optical etc.  In my separate comment
> I was alluding to hierarchical or a layering which IETF Network slice would
> sit at the top of the hierarchy and being Technology agnostic and the
> individual Technologies would sit at the bottom layer.  I wonder if a
> comment on this layering topic should be in the framework draft?
>
>
>
> I may misunderstand your comments. What I mean "superset" is not
> hierarchical/layering concept. My "superset" means that of
> architectural/modeling concept comparing both architectures.
>
> In terms of SLO, as John also made 4)th comment in a different thread,
> IETF network slice supporting multiple sets of SLOs, which means a set of
> SLOs per connectivity construct, can cover that of 3GPP network slice
> supporting *a* set of SLOs according to their information model.
>
>  Gyan> I was referring to hierarchical top down approach per the OTN
> slicing adoption call discussion
>
> https://mailarchive.ietf.org/arch/msg/teas/ay5juQP80QTEOvQCxGWOH5EEjF0/
>
>
>
> As you said to Adrian, IETF network slice is consumed by 3GPP network
> slice as the underlying transport network. So, I'm not sure how we can
> cover the emerging slice architecture from a different SDO who will consume
> IETF network slice, or should touch on some specific SDOs to whom we can
> meet e.g. 3GPP, Optical.
>
>  Gyan> 3GPP is the driver of  the TEAS work in IETF Network Slicing.  So
> that  is the big question we have posed to the WG is that is IETF network
> slicing only for 3GPP or can it be used by other technologies such as
> Optical etc?
>
> Thanks,
>
> Kenichi
>
>
>
> *From:* Gyan Mishra <[e-mail]>
> *Sent:* Monday, March 7, 2022 3:28 AM
> *To:* 大垣 健一 <[e-mail]>
> *Cc:* [e-mail]; TEAS WG <[e-mail]>; TEAS WG
> Chairs <[e-mail]>; [e-mail]
> *Subject:* ***フリーメール*** Re: [Teas] Upcoming changes to
> draft-ietf-teas-ietf-network-slices
>
>
>
>
>
> Hi Kenichi / Adrian / Luis and all
>
>
>
> Thank you Adrian for your comments and I agree with everything you have
> stated.
>
>
>
> I commented on a separate thread on your topic of 5G being the Major
> consumer and agree to your POV that it is not the Major consumer, however
> our work MUST be good enough to support 3GPP.
>
>
>
> On Sun, Mar 6, 2022 at 6:06 AM Ogaki, Kenichi <[e-mail]> wrote:
>
> *************************************************************
> All attached files have been encrypted for security purposes.
> The password will be sent to you shortly in a separate email.
>
> KDDIメールシステムから添付ファイル暗号化のお知らせ
> 弊社では情報セキュリティを強化する為、メール添付ファイル自動
> 暗号化システムを導入しております。パスワードは別途、お知らせ
> 申し上げます。ご面倒をおかけいたしますが、ご理解賜りますよう
> お願いいたします。                              KDDIグループ
> *************************************************************
>
> Hi Adrian/Gyan/Luis and all,
>
>
>
> Thanks for your comments.
>
>
>
> I basically agree with Adrian's opinion.
>
>
>
> See comments[KO] inline, please.
>
>
>
> Thanks,
>
> Kenichi
>
>
>
> Get Outlook for iOS <https://aka.ms/o0ukef>
> ------------------------------
>
> *From:* Adrian Farrel <[e-mail]>
> *Sent:* Saturday, March 5, 2022 6:42 PM
> *To:* 'Gyan Mishra'; 大垣 健一
> *Cc:* 'TEAS WG'; 'TEAS WG Chairs'; [e-mail]
> *Subject:* RE: [Teas] Upcoming changes to
> draft-ietf-teas-ietf-network-slices
>
>
>
> Hi all,
>
>
>
> [Copying Gonzalo, the IETF’s liaison manager for the 3GPP relationship]
>
>
>
> I am not convinced that 5G will be **the** major consumer of IETF network
> slicing. But it is potentially **a** major consumer, so clearly our work
> must be good enough to support the 3GPP requirements.
>
>
>
> There are several points at which we need to check that we are not
> breaking what the 3GPP want to do.
>
>    - Is the framework general enough?
>    - Does the work on “mapping 3GPP slices to IETF slices” provide enough
>    information?
>    - Do the YANG models allow adequate configuration and reporting?
>
>
>
> [KO] Agree.
>
> Gyan> Agree
>
> I would suggest that the chairs might want to arrange for a liaison
> statement to the 3GPP to say:
>
>    - The framework is close to complete, and now would be an ideal time
>    to do a review
>    - Other work is progressing at the working group (point at some
>    drafts), and that input is always welcome
>    - The most effective way to contribute to and steer the work is by
>    direct input from individuals via the mailing list
>
>
>
> [KO] From the above points, we can only provide the framework draft for
> now. A mapping draft, e.g. draft-geng-teas-network-slice-mapping or Luis’s,
> is individual and not matured. If you say
> draft-ietf-teas-ietf-network-slice-nbi-yang as the YANG model, it's also
> not matured.
>
>
>
>     Gyan> Agreed
>
>
>
> In my understanding, the transport part of 3GPP network slice is not
> continuously discussed in 3GPP in terms of architecture, then they may not
> be able to be aware of what's the lack of IETF network slice if we only
> send the framework draft.
>
> In that sense, a mapping, gap analysis/applicability, draft should be a
> necessary piece.
>
>
>
>     Gyan> Agreed
>
>
>
> As for 3GPP network slice specification, I sometimes made comments to
> discussion threads about framework draft to avoid the inconsistency with
> other SDOs' work, especially 3GPP, as possible.
>
> I believe the current IETF network slice architecture is a superset of
> 3GPP network slice's one in terms of SLO, so not pessimistic.
>
>
>
> https://mailarchive.ietf.org/arch/msg/teas/u_0C1AlEjQaBZse7I6Y0hDr5QBE/
>
> https://mailarchive.ietf.org/arch/msg/teas/oU1b6qYIc7jDn-B-4vHAV0OrN68/
>
> https://mailarchive.ietf.org/arch/msg/teas/wE0w5zuFOVEeR4TPVYI_mv-NGMg/
>
>
>
>     Gyan> Agreed.  Good point.  As far as Super set thinking in a
> hierarchical terms or independent layering that have dependencies.  In
> terms of hierarchy IETF sits at the top layer and underneath would sit the
> individual Technologies such as 3GPP, Optical etc.  In my separate comment
> I was alluding to hierarchical or a layering which IETF Network slice would
> sit at the top of the hierarchy and being Technology agnostic and the
> individual Technologies would sit at the bottom layer.  I wonder if a
> comment on this layering topic should be in the framework draft?
>
>
>
> IMHO, a gap analysis is helpful, at first, based on their slice
> information model, TS28.541 Clause 6, which includes their slice related
> element relationship, SLO definition(ServiceProfile), transport
> endpoint(EP_Transport)[1] and SFC on N6 interface(N6Protection)[2]. How
> 3GPP network slice trying to use the transport network is also described in
> their slice lifecycle management related documents, TS28.530 Clause 4.7
> and, TS28.531 Clause 5.1 and 7.
>
>
>
> As we received a liaison from GSMA NG, they have E2E Network Slicing Work
> Item(ENSWI) and I believe one of their objectives is to resolve the issue
> among multiple SDOs to realize E2E Network Slicing. Then, the response with
> the above Adrian's points may be useful.
>
>
>
> https://mailarchive.ietf.org/arch/msg/teas/DZUhOW5m48tqj3CagfASM1BpDtg/
>
>
>
> Also, not 3GPP, but ORAN alliance WG9 is actively working for xHaul
> solution standardization using other transport SDOs' specific solutions. I
> believe this also impacts mobile NEP's implementations and some TEASer are
> actively involved.
>
>
>
>     Gyan> Excellent
>
>
>
> This may be beyond TEAS WG work, maybe related to DetNet, 3GPP SA2 started
> "Study on timing resiliency and TSC and URLLC enhancements" in Rel.18[3],
> which enhances URLLC slice with TSN requirement.
>
>
>
> [1]
> https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2020-07-16-3gpp-tsg-sa-wg5-teas-ls-on-adding-transport-information-in-3gpp-nrm-to-facilitate-cross-domain-oam-coordination-attachment-2.doc
>
> [2]
> https://www.3gpp.org/ftp/TSG_SA/WG5_TM/TSGS5_140e/Inbox/Drafts/S5-216247rev2%20Rel-17%20network%20slice%20protection%20on%20N6%20interface.docx
>
> [3]
> https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3995
>
>
>
>
>
> Of course, those of you active in 3GPP or with friends who are, can make
> this go smoother by simply arranging for the reviews and input.
>
>  Gyan> Agreed and great idea for sure
>
> Cheers,
>
> Adrian
>
>
>
> *From:* Gyan Mishra <[e-mail]>
> *Sent:* 04 March 2022 23:43
> *To:* Ogaki, Kenichi <[e-mail]>
> *Cc:* Igor Bryskin <[e-mail]>; Joel M. Halpern <
> [e-mail]>; TEAS WG <[e-mail]>; [e-mail];
> [e-mail]
> *Subject:* Re: [Teas] Upcoming changes to
> draft-ietf-teas-ietf-network-slices
>
>
>
> 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
> <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
>
> --
>
> *Gyan Mishra* <http://www.verizon.com/>
>
> *Network Solutions Architect * <http://www.verizon.com/>
>
> *Email [e-mail]* <http://www.verizon.com/>
>
> *M 301 502-1347* <http://www.verizon.com/>
>
>   <http://www.verizon.com/>
>
> -- <http://www.verizon.com/>
>
> [image: http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]
> <http://www.verizon.com/>
>
> *Gyan Mishra* <http://www.verizon.com/>
>
> *Network Solutions Architect * <http://www.verizon.com/>
>
> *Email [e-mail]* <http://www.verizon.com/>
>
> *M 301 502-1347* <http://www.verizon.com/>
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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



*M 301 502-1347*