Re: [Teas] New term for the underlay construct used for slice realization

[John E Drake <[e-mail]>]

Hi,



comments inline.



Yours Irrespectively,



John



> -----Original Message-----

> From: Kiran Makhijani <[e-mail]>

> Sent: Wednesday, August 11, 2021 11:00 AM

> To: John E Drake <[e-mail]>; Dongjie (Jimmy)

> <[e-mail]>; Lizhenbin <[e-mail]>; [e-mail]

> Subject: Re[2]: [Teas] New term for the underlay construct used for slice

> realization

>

> [External Email. Be cautious of content]

>

>

> Hi John, (and all),

>

> Two very basic clarification questions:

> 1. How do we differentiate between  the slice-segments that are resource-

> aware vs those that are not? I had assumed that since a slice has an SLO, it will

> need network resource allocations in some form.



[JD]  If you are referring to an IETF Network Slice Service, by definition it has no underlay network resource awareness.



>

> 2. Is it ok to assume that the customer view of slice is an 'IETF network slice

> service' and the 'IETF slice realization' of that service in a provider network is

> raises the question of underlay and overlay constructs. Am I right?



[JD]  We provide overlay services, including but not limited to, IETF Network Slice Services over a common underlay network.



> (a) if so, then we are acknowledging  the presence of another layer of

> abstraction (for realization). It could be underlay/overlay or aggregate/??.



[JD]  This has been integral to the IETF network slice work from its inception.



> Then

> the term 'slice aggregate' is better and my preference, it is easier to see that

> different slice-services are aggregated into a single construct  in a provider

> network.


[JD]  There is a set of IETF Network Slice Services which are mapped to a set of partitioned underlay network topologies (or whatever term on which we decide), as are other overlay network services.



> Use of underlay/overlay are confusing.



[JD] I'm sorry.  This has been  IETF and industry standard terminology for years.



> (b) for a leaner provisioning, I would also prefer to see it documented that the

> aggregate is optional and it should be possible to directly map a slice-service to

> physical or real resources in the network.

> specifically useful when a single domain is carving out slices for different

> purposes.



[JD]  As I noted to Joel,  resource partitions are an optional tool that enables enhanced DiffServ support for a multiplicity of overlay services.  I.e., it is not IETF Network Slice Service-specific.



>

> Thanks

> Kiran

>

>

> ------ Original Message ------

> From: "John E Drake" <jdrake=[e-mail]<mailto:jdrake=[e-mail]>>

> To: "Dongjie (Jimmy)" <[e-mail]<mailto:[e-mail]>>; "Lizhenbin"

> <[e-mail]<mailto:[e-mail]>>; "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>

> Sent: 8/11/2021 5:38:05 AM

> Subject: Re: [Teas] New term for the underlay construct used for slice realization

>

> >Jimmy,

> >

> >Snipped, comments inline.

> >

> >Yours Irrespectively,

> >

> >John

> >

> >

> >Juniper Business Use Only

> >

> >>  -----Original Message-----

> >>  From: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>

> >>  Sent: Tuesday, August 10, 2021 11:03 PM

> >>  To: John E Drake <[e-mail]<mailto:[e-mail]>>; Lizhenbin

> >><[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>

> >>  Subject: RE: New term for the underlay construct used for slice

> >>realization

> >>

> >>  [External Email. Be cautious of content]

> >>

> >underlay construct for network slice realization bound to

> >>  > > network slice services? That is, is the underlay construct only

> >> for  > > use in network slicing, or should it be generalized for more possible

> uses?

> >>  >

> >>  > [JD] Absolutely yes

> >>

> >>  [Jie] I guess you mean "Yes" to the latter case, which is "it should

> >> be generalized  for more possible uses", is my understanding correct?

> >

> >[JD]  Yes to the latter

> >

> >>

> >>  >

> >>  > >

> >>  > > 2.      If the answer to question 1 is YES, should it reflect the following

> >>  > > characteristics?

> >>  > >

> >>  > > a.      It is about the underlay

> >>  > > b.      It is about the partitioned resources used to deliver the network

> slice

> >>  > > services

> >>  > > c.      It allows the 1:1, N:1, and 1:N mapping models between the

> network

> >>  > slice

> >>  > > services and the underlay construct. The 1:1 and N:1 mapping may

> >> be  > > straightforward. Does it also make sense to divide the

> >> elements or  > > traffic flows in a single network slice service to

> >> carry them in  > > different  > underlay constructs?

> >>  >

> >>  > [JD]  Yes to all of the above.  Please see:

> >>  >

> >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dra<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/dra>

> >> f  > t-drake-bess-enhanced-vpn-06__;!!NEt6yMaO-

> >>  gk!TCiJHCZCwFgwpuFoujxVlZ4r9

> >>  > F6mLpE4nJ-9zpqkY-kls-ROxL4C2_xNaR2ImI4$

> >>  > >

> >>  > > Lastly, here are some candidates of the "new term":

> >>  > >

> >>  > > Option 1: The network slice service is called "overlay slice",

> >> then  > > the underlay construct is called "underlay slice".

> >>  > >

> >>  > > Option 2: The network slice service is called "service slice",

> >> then  > > the underlay construct is called "resource slice".

> >>  >

> >>  > [JD]  I don't think we need another term for what we are already

> >> > calling an 'IETF Network Slice Service'.  Adrian and I are

> >> considering  > the term 'resource partition' to describe the

> >> partitioning of underlay  > network resources in support of various

> >> overlay services such as IETF Network  Slice Services.

> >>  > This is congruent with the ideas expressed in:

> >>  >

> >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dra<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/dra>

> >> f  > t-ietf-spring-resource-aware-segmen__;!!NEt6yMaO-

> >>  gk!TCiJHCZCwFgwpuFouj

> >>  > xVlZ4r9F6mLpE4nJ-9zpqkY-kls-ROxL4C2_xNxEfwaXg$

> >>  > ts-03.  What this allows one to build is an 'partitioned underlay

> >> > network topology'.

> >>

> >>  [Jie] Agree that here we are talking about the term for the underlay

> construct.

> >>  "Resource partition" captures one of its key characteristics, while

> >> IMO another  thing the term needs to reflect is that the resource

> >> partition is needed on a  subset of the links and nodes (rather than

> >> on a single node or link) in the physical  network, which together builds a

> logical network topology.

> >

> >[JD]  In my initial email, above, I was proposing 'partitioned underlay network

> topology'

> >

> >>

> >>  Best regards,

> >>  Jie

> >>

> >>  >

> >>  > >

> >>  > > Your opinion about these candidates are much appreciated. You

> >> may  > > also propose other new term if it complies with the above two

> points.

> >>  >

> >>  > [JD]  I think you have exceeded your remit.

> >>  >

> >>  > >

> >>  > >

> >>  > >

> >>  > > Best Regards,

> >>  > > Robin

> >>  > >

> >>  > > _______________________________________________

> >>  > > Teas mailing list

> >>  > > [e-mail]<mailto:[e-mail]>

> >>  > >

> >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/te<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/te>

> >>  > > as

> >>  > > __;!!N

> >>  > > Et6yMaO-gk!Q0ycOf0ELxT6mG1GbnO4LSL-Q99J4uu7jfdUtBECaI-

> >>  > > O08HqD31TGJciNjuxL2A$

> >>  >

> >>  > _______________________________________________

> >>  > Teas mailing list

> >>  > [e-mail]<mailto:[e-mail]>

> >>  >

> >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tea<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/tea>

> >> s  > __;!!NEt6yMaO-gk!TCiJHCZCwFgwpuFoujxVlZ4r9F6mLpE4nJ-9zpqkY-kls-

> >>  ROxL4C2

> >>  > _xNDCrPaNQ$

> >

> >_______________________________________________

> >Teas mailing list

> >[e-mail]<mailto:[e-mail]>

> >https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas_<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas_>

> >_;!!NEt6yMaO-

> gk!SCERgAZ566ZJbmstSAXS9FCSjdfU15Z795qJU4cO3Z4kXx8JLdcPEdSp4VsBkqM$




Juniper Business Use Only