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

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

Hi John, 

Please see inline:

> -----Original Message-----
> From: Teas [mailto:[e-mail]] On Behalf Of John E Drake
> Sent: Wednesday, August 11, 2021 3:12 AM
> To: Lizhenbin <[e-mail]>; [e-mail]
> Subject: Re: [Teas] New term for the underlay construct used for slice
> realization
> 
> Hi,
> 
> Comments inline.
> 
> Yours Irrespectively,
> 
> John
> 
> 
> Juniper Business Use Only
> 
> > -----Original Message-----
> > From: Teas <[e-mail]> On Behalf Of Lizhenbin
> > Sent: Tuesday, August 10, 2021 11:21 AM
> > To: [e-mail]
> > 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.

Since a VTN comprises a subset of the underlay network topology and a set of partitioned resources allocated from the physical network, my understanding is that itself is not a physical network. And since multiple VTNs can be created based on the same physical network, this can be considered as some level of virtualization of the network infrastructure. This is analogous to the VM (Virtual Machine) which is allocated with a subset of the resources from the physical server. 

I agree the term "transport" has always been controversial, our intent was to find a key word to refer to the underlay network and distinguish it from the overlay virtual networks. 

Alternatively, the letter "T" in VTN may be interpreted as "TE".

> >
> > 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

[Jie] I guess you mean "Yes" to the latter case, which is "it should be generalized for more possible uses", is my understanding correct?

> 
> >
> > 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-segmen
> 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. 

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/teas
> > __;!!N
> > Et6yMaO-gk!Q0ycOf0ELxT6mG1GbnO4LSL-Q99J4uu7jfdUtBECaI-
> > O08HqD31TGJciNjuxL2A$
> 
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas