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

["Dongjie (Jimmy)" <[e-mail]>]

Hi Kiran, 

Thanks a lot for the update. 

Please see some replies inline:

> -----Original Message-----
> From: Kiran Makhijani [mailto:[e-mail]]
> Sent: Tuesday, November 3, 2020 7:30 AM
> To: Dongjie (Jimmy) <[e-mail]>; [e-mail];
> [e-mail]
> Subject: RE: [Teas] FW: New Version Notification for
> draft-nsdt-teas-ietf-network-slice-definition-00.txt
> 
> 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.

OK, we can discuss the appropriate term for it. 
> 
> 2.  We should have explained isolation briefly first, then jump into  ask from
> consumer. (readjusted text in 01)

OK, thanks. 

> 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.

This item is to cover the requirement of mis-delivery both in normal case and in some special cases (e.g. attack) I agree this is a basic requirement, and can be easily met with existing technologies, while it is listed here for completeness of the requirements.  

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

Do you mean the text about "isolation level" in GST? It is just to provide information about the description of isolation in 5G community, and the possible mapping to IETF network slice. We don't have opinion on whether it should be in the NSDT documents, and which document it belongs to.

Best regards,
Jie

> 
> 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%7C80aac7efa01d43e055d
> 2
> > > 08d
> > > > 8764fa8e5%7C
> > > >
> > >
> 0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637389431798734419
> > > %7
> > > > CUnknown%7CTW
> > > >
> > >
> > FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> > > VC
> > > > I6Mn0%3D
> > > > %7C2000&amp;sdata=7wm50bc73lEQm0WsZuuDrtMBr0hhmz3dUsSHLU
> ji
> > > 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%2
> > > > F&
> > > > 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%7C0fee8ff2a3b2
> 4
> > 0189c
> > >
> >
> 753a1d5591fedc%7C1%7C0%7C637396194811416805%7CUnknown%7CTWF
> p
> > bGZsb3d8ey
> > >
> >
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> > 7C100
> > >
> >
> 0&amp;sdata=QDfpFqck3fcgEIIqbu1G%2F%2BOFzyp4fnkaRixDWDQxuy4%3D
> > &amp;res
> > > erved=0