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

While I mostly agree with John's descriptions below, I am a bit 
concerned by the suggestion of "partition".  While some of the use cases 
seem to be describable as partitions, not all of them are.  In general, 
what I have observed when combining statistical multiplexing with 
traffic engineering we rarely want true partitioning.

Yours,
Joel

On 8/10/2021 3:11 PM, John E Drake wrote:
> Hi,
> 
> Comments inline.
> 
> Yours Irrespectively,
> 
> John
> 
> 
> Juniper Business Use Only
> 
>> -----Original Message-----
>> From: Teas <teas-bounces@ietf.org> On Behalf Of Lizhenbin
>> Sent: Tuesday, August 10, 2021 11:21 AM
>> To: teas@ietf.org
>> Subject: [Teas] New term for the underlay construct used for slice realization
>>
>> [External Email. Be cautious of content]
>>
>>
>> Hi Folks,
>>
>> On the TEAS meeting in IETF 111, it was discussed that a common "new term"
>> will need to be proposed for the underlay construct used for slice realization.
>>
>> There have been several related terminologies:
>>
>> 1.      VTN (Virtual Transport Network)
>>
>> In the early days of network slicing discussion in IETF, it was suggested that the
>> technology in IETF should be neutral and not bound to network slicing only.
>> Following this approach, the term VTN is defined in the enhanced VPN draft
>> already adopted and progressing in TEAS. It is expected that the VTNs with
>> guaranteed resources can also be applicable to services other than network
>> slices. The VPN+ architecture allows flexible mapping (including 1:1, N:1 and 1:N
>> mapping) between the overlay VPN services and the underlay VTNs. Since VTN is
>> a generic term, in the context of network slicing we may still need a specialized
>> term.
> 
> [JD]  I never liked this term because what it is describing is real not virtual and because the IETF does not build transport networks.  I.e., what it is describing is a subset of the underlay network topology with partitioned resources.
> 
>>
>> 2.      Slice Aggregate
>>
>> It is claimed that the scope of Slice Aggregate is tied to the scope of IETF
>> network slices. This term implies an aggregation of one or more IETF network
>> slices into an aggregate construct, so that only a 1:1 and N:1 mapping of
>> network slice service to underlay construct can be achieved. However, if this is a
>> mapping of network slice traffic streams to underlay constructs, then it may be
>> possible to map network slice services to the underlay construct as 1:1, N:1 and
>> 1:N, but the name may be confusing because it is not the slices that are
>> aggregated.
> 
> [JD]  This term never resonated with me because it is slice specific and because, as Adrian pointed out, it's actually used to describe multiple, incompatible ideas.
> 
>>
>> With this background in mind, now we can discuss how to define the new term.
>> Here are some points for the WG to consider:
>>
>> 1.      Should the 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
> 
>>
>> 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://datatracker.ietf.org/doc/html/draft-drake-bess-enhanced-vpn-06
>>
>> 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://datatracker.ietf.org/doc/html/draft-ietf-spring-resource-aware-segments-03.  What this allows
> one to build is an 'partitioned underlay network topology'.
> 
>>
>> 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/teas__;!!N
>> Et6yMaO-gk!Q0ycOf0ELxT6mG1GbnO4LSL-Q99J4uu7jfdUtBECaI-
>> O08HqD31TGJciNjuxL2A$
> 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
> 