Re: [Teas-ns-dt] [Teas] FW: New Version Notification for draft-nsdt-teas-ietf-network-slice-definition-00.txt

[Kiran Makhijani <[e-mail]>]

Hi Dongjie and all, 
Thanks for sharing this just in time. I pushed changes but with edits. In general I am ok that you want to split it into 3 categories, 

1. I was not personally convinced that service continuity is the right term. For now I am calling it service assurance. 

2.  We should have explained isolation briefly first, then jump into  ask from consumer. (readjusted text in 01)

3.  > On Traffic separation  " On the other hand, traffic of
> other network slices or services must not be shared to the endpoints of this
> network slice."
I find this statement odd. It is fundamental to networks that traffic is delivered accurately between the specified endpoints (with or without slices). However, I can see value in saying that policies or other constraints of one slice should not impact other (modified in revision -01). We will need to revisit this text.

4. I think what 5G use case does not relate to the text/document and can be removed.

Thanks
Kiran

> -----Original Message-----
> From: Dongjie (Jimmy) <[e-mail]>
> Sent: Thursday, October 29, 2020 6:51 PM
> To: Kiran Makhijani <[e-mail]>; [e-mail]; teas-
> [e-mail]
> Subject: RE: [Teas] FW: New Version Notification for draft-nsdt-teas-ietf-
> network-slice-definition-00.txt
> 
> [have the discussion in design team first]
> 
> Hi Kiran, Adrian and Team,
> 
> Recently Luis, Jeff and I had some discussion on isolation and produced the
> text below which consolidates with the text in section 9 of the current
> definition draft. Please review and share your opinions on it, thanks.
> 
> Best regards,
> Jie (on behalf of Luis and Jeff)
> 
> -------
> 9.  Isolation in IETF Network Slices
> 
> 9.1. Isolation as an IETF Network Slice Requirement
> 
> A customer may request, either explicitly or implicitly through the description
> of SLOs and attributes that the IETF Network Slice delivered to them is
> isolated from any other network slices of services delivered to any other
> customers. This could be the requirement of network slices for e.g. critical
> services, emergencies, etc. That is, that changes to the other network slices
> of services do not have any negative impact on the delivery of the IETF
> network slice.
> 
> This requirement may be met by simple conformance with other SLOs. For
> example, traffic congestion (interference from other services) might impact
> the latency experienced by an IETF Network Slice. Thus, in this example,
> conformance to a latency SLO would be the primary requirement for delivery
> of the IETF network slice service, and isolation from other services might be
> only a means to that end.
> 
> In a more general sense, isolation can be interpreted as several detailed
> requirements:
> 
> 1)	Traffic separation. Traffic of one network slice must not be shared
> with the endpoints in other network slices. On the other hand, traffic of
> other network slices or services must not be shared to the endpoints of this
> network slice.
> 
> 2)	Interference avoidance. Changes in other network slices should not
> have negative impact to the SLOs of the network slice. Here the changes in
> other network slice may include the changes in connectivity, traffic volume,
> traffic pattern, etc.
> 
> 3)	Service continuity. The IETF Network Slice with a high degree of
> isolation will provide service continuity even in case of network situations
> producing general service degradation (e.g., major congestion events, etc.).
> This could imply the reservation of resources in the network to be used for a
> reduced set of IETF Network Slices.
> 
> How delivery of isolation is achieved in the realization of an IETF network slice
> is implementation and technology dependent.  The customer of a network
> slice may not be aware of how the isolation requirement is achieved. The
> realization of the network slice isolation may further depend on how a
> network operator decides to operate its network and deliver services on top
> of it.
> 
> 9.2. Isolation in realization of IETF Network Slice
> 
> The realization of isolation is implementation and technology dependent.
> The isolation requirement can be achieved with existing, in-development,
> and potential new technologies in IETF.
> 
> Isolation may be achieved in the underlying network by various forms of
> resource partitioning ranging from dedicated allocation of resources for a
> specific IETF Network Slice, to sharing or resources with safeguards.
> 
> For example, traffic separation between different IETF network slices may be
> achieved using VPN technologies, such as L3VPN, L2VPN, EVPN, etc. as well
> as optical and or LSP/tunnel levels.
> 
> Interference avoidance may be achieved by network capacity planning,
> allocating dedicated network resources, traffic policing or shaping, prioritizing
> in using shared network resources, etc. Finally, service continuity may be
> ensured by reserving backup paths for critical traffic, dedicating specific
> network resources for a selected number of network slices, etc.
> 
> 9.3. Relationship with Isolation in 5G Network Slice
> 
> In the context of 5G network slice, "isolation level" is listed as one of the
> attributes which can be used to characterize the type of network slice [GSMA
> Generic Network Slice Template]. For 5G network slice, different types of
> isolation are considered, including physical and logical isolation. Physical
> isolation refers to different physical network entities, and logical isolation is
> further classified into virtual resource isolation, network function isolation
> and tenant/service isolation.
> 
> The isolation attribute of IETF network slice may be considered as
> corresponding to physical or virtual resource isolation and tenant/service
> isolation in 5G network slice.
> 
> > -----Original Message-----
> > From: Teas-ns-dt [mailto:[e-mail]] On Behalf Of
> > Kiran Makhijani
> > Sent: Wednesday, October 28, 2020 11:53 PM
> > To: [e-mail]; [e-mail]; 'TEAS WG'
> > <[e-mail]>
> > Subject: Re: [Teas-ns-dt] [Teas] FW: New Version Notification for
> > draft-nsdt-teas-ietf-network-slice-definition-00.txt
> >
> > Thanks Adrian,
> > According to authors the current text in this document is just enough
> > to provide clarity on the IETF network slice concept.
> > I remember you wanted current section 5 to be removed but we felt it's
> > important and pruned it quite a bit - we will further combine section
> > 5 and
> > 10 to define end-to-end slices relationship and the structure in one place.
> > Other than that, we are waiting for revision on isolation contribution
> > from Jie, Luis, and Jeff.
> >
> > Yes, end-to-end slicing will need quite a bit of explanation but
> > minimal description here is also important to show the scope of IETF
> > network slices in the broader concept.
> >
> > I hope that the mailing list this time agrees that it is a reasonable
> > terminology-set.
> > -Kiran
> >
> >
> > > -----Original Message-----
> > > From: Adrian Farrel <[e-mail]>
> > > Sent: Thursday, October 22, 2020 1:44 AM
> > > To: Kiran Makhijani <[e-mail]>; [e-mail];
> > > 'TEAS
> > WG'
> > > <[e-mail]>
> > > Subject: RE: [Teas] FW: New Version Notification for
> > > draft-nsdt-teas-ietf- network-slice-definition-00.txt
> > >
> > > Kiran, all,
> > >
> > > I want to thank the authors of this draft for their work and for listening.
> > > This version of the draft is a *substantial* improvement.
> > >
> > > Of course, I still have some issues I'd like to work through. Some
> > > of my concerns are "just" language usage where the choice of words
> > > or phrasing means something that I don't think the authors intend.
> > > Other concerns are about the details. But all in all, this is going
> > > in the right
> > direction.
> > >
> > > I still think there is too much text in this definitions document. I
> > > think that is a natural result of having several documents in the
> > > pipe at the same time. There is explanation of how things work and
> > > hang together that, in my opinion, should relocate to other
> > > documents - maybe the framework, maybe dedicated applicability
> > > statements. For example, I can see value in a document explaining
> > > how IETF network slices fit into the models of "end-to-end network
> > > slices" as conceived in
> > other SDOs.
> > >
> > > Best,
> > > Adrian
> > >
> > > -----Original Message-----
> > > From: Teas <[e-mail]> On Behalf Of Kiran Makhijani
> > > Sent: 22 October 2020 07:12
> > > To: [e-mail]; TEAS WG <[e-mail]>
> > > Subject: [Teas] FW: New Version Notification for
> > > draft-nsdt-teas-ietf-network- slice-definition-00.txt
> > >
> > > Hello Teas and teas-ns-dt,
> > > FYI: Please find new version of  IETF network slices (previously
> > > called transport
> > > slices) definition document.
> > >
> > > This is still a work in progress document but several comments and
> > > feedback received till now have been addressed. We want to share
> > > updates so far and look forward to further comments and discussion.
> > >
> > > Thanks
> > > -Authors
> > >
> > > -----Original Message-----
> > > From: [e-mail] <[e-mail]>
> > > Sent: Wednesday, October 21, 2020 11:00 PM
> > > To: Kiran Makhijani <[e-mail]>; Luis Contreras
> > > <[e-mail]>; Reza Rokui
> > > <[e-mail]>; Shunsuke Homma
> > > <[e-mail]>; Jeff Tantsura
> > > <[e-mail]>; Luis M. Contreras
> > > <[e-mail]>
> > > Subject: New Version Notification for
> > > draft-nsdt-teas-ietf-network-slice-definition-00.txt
> > >
> > >
> > > A new version of I-D,
> > > draft-nsdt-teas-ietf-network-slice-definition-00.txt
> > > has been successfully submitted by Kiran Makhijani and posted to the
> > > IETF repository.
> > >
> > > Name:		draft-nsdt-teas-ietf-network-slice-definition
> > > Revision:	00
> > > Title:		Definition of IETF Network Slices
> > > Document date:	2020-10-21
> > > Group:		Individual Submission
> > > Pages:		17
> > > URL:
> > >
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> > w.
> > > ie
> > > tf.o
> > > rg%2Farchive%2Fid%2Fdraft-nsdt-teas-ietf-network-slice-definition-
> > > 00.txt&amp
> > > ;data=04%7C01%7Ckiranm%40futurewei.com%7C80aac7efa01d43e055d2
> > 08d
> > > 8764fa8e5%7C
> > >
> > 0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637389431798734419
> > %7
> > > CUnknown%7CTW
> > >
> >
> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> > VC
> > > I6Mn0%3D
> > > %7C2000&amp;sdata=7wm50bc73lEQm0WsZuuDrtMBr0hhmz3dUsSHLUji
> > 5r8
> > > %3D&amp;reserve
> > > d=0
> > > Status:
> > >
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> > > tra
> > > cke
> > > r.ietf.org%2Fdoc%2Fdraft-nsdt-teas-ietf-network-slice-definition%2F&
> > > am
> > > p;data
> > >
> > =04%7C01%7Ckiranm%40futurewei.com%7C80aac7efa01d43e055d208d876
> > 4f
> > > a8e5%7C0fee8
> > >
> > ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637389431798734419%7CU
> > nk
> > > nown%7CTWFpbGZ
> > >
> >
> sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M
> > n
> > > 0%3D%7C20
> > >
> >
> 00&amp;sdata=diwg0Oe8QVWtuRFoP21aAAN%2FQ046hCe%2F1DI5vNgOH0
> > 8
> > > %3D&amp;reserved
> > > =0
> > > Htmlized:
> > >
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> > > tra
> > > cke
> > > r.ietf.org%2Fdoc%2Fhtml%2Fdraft-nsdt-teas-ietf-network-slice-
> > > definition&amp;
> > >
> > data=04%7C01%7Ckiranm%40futurewei.com%7C80aac7efa01d43e055d208
> > d8
> > > 764fa8e5%7C0
> > >
> > fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637389431798734419%
> > 7C
> > > Unknown%7CTWF
> > >
> >
> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV
> > CI
> > > 6Mn0%3D%
> > >
> >
> 7C2000&amp;sdata=H%2BuJYcBjXiSrz1raGpMrRthMlWHAAjvdZIQuOcAp1YE
> > %3
> > > D&amp;reserv
> > > ed=0
> > > Htmlized:
> > >
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool
> > > s.ie
> > > tf
> > > .org%2Fhtml%2Fdraft-nsdt-teas-ietf-network-slice-definition-
> > > 00&amp;data=04%7
> > >
> > C01%7Ckiranm%40futurewei.com%7C80aac7efa01d43e055d208d8764fa8e5
> > %
> > > 7C0fee8ff2a3
> > >
> > b240189c753a1d5591fedc%7C1%7C1%7C637389431798744414%7CUnkno
> > wn
> > > %7CTWFpbGZsb3d8
> > >
> >
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> > D
> > > %7C2000&am
> > >
> >
> p;sdata=ZMr1EeR5CXXBvuPd0SndoJYxehAdgAmmaLkEz%2BkXrXE%3D&amp;
> > re
> > > served=0
> > >
> > >
> > > Abstract:
> > >    This document provides a definition of the term "IETF Network Slice"
> > >    for use within the IETF and specifically as a reference for other
> > >    IETF documents that describe or use aspects of network slices.
> > >
> > >    The document also describes the characteristics of an IETF network
> > >    slice, related terms and their meanings, and explains how IETF
> > >    network slices can be used in combination with end-to-end network
> > >    slices or independent of them.
> > >
> > >
> > >
> > >
> > >
> > > Please note that it may take a couple of minutes from the time of
> > > submission until the htmlized version and diff are available at
> tools.ietf.org.
> > >
> > > The IETF Secretariat
> > >
> > >
> > > _______________________________________________
> > > Teas mailing list
> > > [e-mail]
> > >
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> > w.
> > > ie
> > tf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=04%7C01%7Ckiranm%40f
> > utu
> > >
> > rewei.com%7C6dad12e7b3d147f151ce08d876669af2%7C0fee8ff2a3b24018
> > 9c
> > >
> > 753a1d5591fedc%7C1%7C0%7C637389530342292715%7CUnknown%7CTW
> > Fp
> > >
> >
> bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC
> I
> > 6
> > >
> > Mn0%3D%7C1000&amp;sdata=KTwJI1b62%2BemHwnZjOgc8v446%2Bgxhl8
> > N3
> > > Gy4QP6BdU0%3D&amp;reserved=0
> >
> > --
> > Teas-ns-dt mailing list
> > [e-mail]
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> w.
> > ietf.org%2Fmailman%2Flistinfo%2Fteas-ns-
> dt&amp;data=04%7C01%7Ckiranm%4
> >
> 0futurewei.com%7Ce7895b66ecb841db0ae808d87c764b0e%7C0fee8ff2a3b24
> 0189c
> >
> 753a1d5591fedc%7C1%7C0%7C637396194811416805%7CUnknown%7CTWFp
> bGZsb3d8ey
> >
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C100
> >
> 0&amp;sdata=QDfpFqck3fcgEIIqbu1G%2F%2BOFzyp4fnkaRixDWDQxuy4%3D
> &amp;res
> > erved=0