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

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

Return-Path: <jmh@joelhalpern.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830213A1928 for <teas@ietfa.amsl.com>; Tue, 10 Aug 2021 12:20:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbdCno0_CRLi for <teas@ietfa.amsl.com>; Tue, 10 Aug 2021 12:20:01 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ED943A1925 for <teas@ietf.org>; Tue, 10 Aug 2021 12:20:01 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4GkjSw6NM1z6G9pW; Tue, 10 Aug 2021 12:20:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; 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 a2.tigertech.net
Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (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 maila2.tigertech.net (Postfix) with ESMTPSA id 4GkjSv57z5z6G96f; Tue, 10 Aug 2021 12:19:59 -0700 (PDT)
To: John E Drake <jdrake=40juniper.net@dmarc.ietf.org>, Lizhenbin <lizhenbin@huawei.com>, "teas@ietf.org" <teas@ietf.org>
References: <2ae53e44d60548e6ac961ac992615e9b@huawei.com> <BY3PR05MB80819A0E7F8CAFD5BAE79A91C7F79@BY3PR05MB8081.namprd05.prod.outlook.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <ebfdd26c-8ee5-9820-7824-273ea86b135d@joelhalpern.com>
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: <BY3PR05MB80819A0E7F8CAFD5BAE79A91C7F79@BY3PR05MB8081.namprd05.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/vonTTcpNpXVIA0Z7M52Uhd9xxJQ>
Subject: Re: [Teas] New term for the underlay construct used for slice realization
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=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.

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
>