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

"Joel M. Halpern" <> Tue, 10 August 2021 19:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 830213A1928 for <>; Tue, 10 Aug 2021 12:20:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qbdCno0_CRLi for <>; Tue, 10 Aug 2021 12:20:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3ED943A1925 for <>; Tue, 10 Aug 2021 12:20:01 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4GkjSw6NM1z6G9pW; Tue, 10 Aug 2021 12:20:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=2.tigertech; t=1628623200; bh=Y6xQeCAvms/5OBiQ5eZpHvzrwqRmyDv/9fv94uGHNLU=; h=Subject:To:References:From:Date:In-Reply-To:From; b=lXeiu0TTsLweVN0sAzeKKPZ2dmWHfV+eR5saGlR3aAJuNU6VehmArUhLnfmUSAIrg SnBFDwk0msy9wspmR1umBVwSgpRJ/LjZGEetzzoc2ORjkgJ2ZRQ4Wl9jXHsL3NlYUu 4WTNiTMbgtF+E8RX20weaH65ejoysKhnEfmHtQP0=
X-Quarantine-ID: <EAt2rls2psxf>
X-Virus-Scanned: Debian amavisd-new at
Received: from [] ( []) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPSA id 4GkjSv57z5z6G96f; Tue, 10 Aug 2021 12:19:59 -0700 (PDT)
To: John E Drake <>, Lizhenbin <>, "" <>
References: <> <>
From: "Joel M. Halpern" <>
Message-ID: <>
Date: Tue, 10 Aug 2021 15:19:58 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Teas] New term for the underlay construct used for slice realization
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Aug 2021 19:20:07 -0000

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.


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 <> On Behalf Of Lizhenbin
>> Sent: Tuesday, August 10, 2021 11:21 AM
>> To:
>> 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:
>> 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:  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
>> Et6yMaO-gk!Q0ycOf0ELxT6mG1GbnO4LSL-Q99J4uu7jfdUtBECaI-
>> O08HqD31TGJciNjuxL2A$
> _______________________________________________
> Teas mailing list