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

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

Jimmy,

Snipped, comments inline.

Yours Irrespectively,

John


Juniper Business Use Only

> -----Original Message-----
> From: Dongjie (Jimmy) <[e-mail]>
> Sent: Tuesday, August 10, 2021 11:03 PM
> To: John E Drake <[e-mail]>; Lizhenbin <[e-mail]>;
> [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/draf
> > 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/draf
> > 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]
> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/te
> > > as
> > > __;!!N
> > > Et6yMaO-gk!Q0ycOf0ELxT6mG1GbnO4LSL-Q99J4uu7jfdUtBECaI-
> > > O08HqD31TGJciNjuxL2A$
> >
> > _______________________________________________
> > Teas mailing list
> > [e-mail]
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas
> > __;!!NEt6yMaO-gk!TCiJHCZCwFgwpuFoujxVlZ4r9F6mLpE4nJ-9zpqkY-kls-
> ROxL4C2
> > _xNDCrPaNQ$