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:teas-bounces@ietf.org] On Behalf Of John E Drake
>> Sent: Wednesday, August 11, 2021 8:38 PM
>> To: Dongjie (Jimmy) <jie.dong@huawei.com>; Lizhenbin
>> <lizhenbin@huawei.com>; teas@ietf.org
>> 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) <jie.dong@huawei.com>
>>> Sent: Tuesday, August 10, 2021 11:03 PM
>>> To: John E Drake <jdrake@juniper.net>; Lizhenbin
>>> <lizhenbin@huawei.com>; teas@ietf.org
>>> 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/dr
>>>> 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/dr
>>>> 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
>>>>> Teas@ietf.org
>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/
>>>>> te
>>>>> as
>>>>> __;!!N
>>>>> Et6yMaO-gk!Q0ycOf0ELxT6mG1GbnO4LSL-Q99J4uu7jfdUtBECaI-
>>>>> O08HqD31TGJciNjuxL2A$
>>>>
>>>> _______________________________________________
>>>> Teas mailing list
>>>> Teas@ietf.org
>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/te
>>>> as
>>>> __;!!NEt6yMaO-gk!TCiJHCZCwFgwpuFoujxVlZ4r9F6mLpE4nJ-9zpqkY-kls-
>>> ROxL4C2
>>>> _xNDCrPaNQ$
>>
>> _______________________________________________
>> Teas mailing list
>> Teas@ietf.org
>> https://www.ietf.org/mailman/listinfo/teas
> 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
> 