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

["Joel M. Halpern" <[e-mail]>]

I was using "forwarding construct" in the sense of "the information that 
determines where to send the packet."  (I will grant it is a bit fuzzy. 
  The Forwarding construct can select a group, adn non-forwarding 
information may be used within that, such as the 5-tuple.)

The point I am concerned with, that I believe you have confirmed below, 
is that the resource information does not determine the forwarding path 
(although there needs to be a suitable relationship as you say).  It, 
like the five-tuple and the DSCP, is concerned with what resources are 
sued to forward once the path is selected.

Yours,
Joel

On 8/13/2021 11:52 AM, Dongjie (Jimmy) wrote:
> 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