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

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

Hi Joel,

Since usually the set of resources are allocated on a subset of the nodes and links in the underlay network, there is a need to specify the sub-topology on which the resources are allocated. That's why we say "VTN is associated with a logical topology", and it aligns with what you said "it needs to be tied to a topology where it is supported". So, I hope we agree that it is "a set of resources provisioned in a sub-topology". 

And I agree we don't need to introduce a new topology identifier. There are well-defined mechanisms (e.g. MT, Flex-Algo) to specify the sub-topology, and it just need to refer to an existing "topology identifier".

As for "it is not a forwarding construct", may I know your definition of "forwarding construct"? To me the resources are allocated in the forwarding plane, thus it should be considered as a "forwarding construct". Please note this is a general discussion about the functionality of this construct, which can be applicable to different data plane encapsulations.

Best regards,
Jie

> -----Original Message-----
> From: Teas [mailto:[e-mail]] On Behalf Of Joel M. Halpern
> Sent: Friday, August 13, 2021 9:30 PM
> To: Dongjie (Jimmy) <[e-mail]>; [e-mail]
> Subject: Re: [Teas] New term for the underlay construct used for slice
> realization
> 
> If, as per the bestbar draft and the discussion of VTN-ID on 6man, this
> construct is NOT a forwarding construct, then I do not see how it
> identifies a sub-topology.   It needs to be tied to a topology where it
> is supported.  But since it is not the forwarding construct, it doesn't need to
> identify that topology as far as I can tell.
> 
> Yours,
> Joel
> 
> On 8/13/2021 8:11 AM, Dongjie (Jimmy) wrote:
> > Hi John,
> >
> > Thanks for your clarification. I think we are mostly aligned.
> >
> > My hope is the new term could reflect the two basic attributes of the
> underlay construct: partitioned resource and a (sub-)topology.
> >
> > Best regards,
> > Jie
> >
> >> -----Original Message-----
> >> From: Teas [mailto:[e-mail]] On Behalf Of John E Drake
> >> Sent: Wednesday, August 11, 2021 8:38 PM
> >> To: Dongjie (Jimmy) <[e-mail]>; Lizhenbin
> >> <[e-mail]>; [e-mail]
> >> 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]>
> >>> 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/d
> >>>> r
> >>>> af
> >>>> 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/d
> >>>> r
> >>>> af
> >>>> 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/t
> >>>> e
> >>>> as
> >>>> __;!!NEt6yMaO-gk!TCiJHCZCwFgwpuFoujxVlZ4r9F6mLpE4nJ-9zpqkY-kls-
> >>> ROxL4C2
> >>>> _xNDCrPaNQ$
> >>
> >> _______________________________________________
> >> 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