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

[[e-mail]]

Hi Joel,

IMO, the traditional five-tuple and DSCP may be not enough for more refined traffic identification, the reason has been described in section 3.1 of https://www.ietf.org/archive/id/draft-peng-teas-network-slicing-04.txt

If a slice-realted identifier is neccessary introduced in the management/control/forwarding plane, then I think SA-ID defined in https://datatracker.ietf.org/doc/draft-bestbar-teas-ns-packet/  contains all concepts that VTN-ID want to express, see below:
1) SA-ID defined the concept of multple slice streams mapping to a single slice-aggregate, multiple slice-aggregates mapping to a single IGP MT/Flex-algo, while VTN-ID just defined the concept of one slice mapping to one VTN-ID, and multiple VTN-ID mapping to a single IGP MT/Flex-algo. 
2) SA-ID defined the concept of customized topology and referrenced topology, for customized mode  it can use affinity rules or SA-ID directly (so that it is nature to support inter-domian case and other limited scenerias that referrence mode is impossible), for referrenced mode it can referr to IGP MT/Flex-algo and TE topology, while VTN-ID just defined the concept of VTN-ID refferring to IGP MT/Flex-algo. 
3) SA-ID defined the concept of SA-ID related flow distinciton, such as SA-ID related SIDs allocation,  GISS carried in packets, while VTN-ID just defined the concept of VTN-ID carried in packets.

Perhaps, for the above gap, the drafts related to VTN has been updated or is being updated, but we SHOULD respect the originality, such as the discussion in https://mailarchive.ietf.org/arch/msg/spring/sgyRpAW5kzcUCdat9FtW15PPbRM/

Regards
PSF


------------------原始邮件------------------
发件人：JoelM.Halpern
收件人：Dongjie (Jimmy);[e-mail];
日 期 ：2021年08月14日 00:02
主 题 ：Re: [Teas] New term for the underlay construct used for slice realization
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

_______________________________________________
Teas mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/teas