IETF Logo Mail Archive

Re: [Teas] A draft on the framework for end-to-end IETF network slicing

"Joel M. Halpern" <jmh@joelhalpern.com> Fri, 14 May 2021 16:50 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 93B1E3A38CB for <teas@ietfa.amsl.com>; Fri, 14 May 2021 09:50:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, RCVD_IN_DNSWL_BLOCKED=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 6TpzchNcW2k0 for <teas@ietfa.amsl.com>; Fri, 14 May 2021 09:50:19 -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 DBA9C3A38C9 for <teas@ietf.org>; Fri, 14 May 2021 09:50:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4FhZJq01njz6G9cH; Fri, 14 May 2021 09:50:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1621011019; bh=VAIDigpnqbUFnP/LsWA9eeUOVOI/9RVfQydoYtHaIq0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=WBEg/HA+1+4mT3ze0EsI1A+1Wj5GMwZizqbQkly4PWx5Zbza4AFgaQ3oNQ0JVBBhC mdLAy41l1ZxpydudOUcmCHEJ+TdttCxjPwiKGLRLvo9vbUAuZmDlf6/HhrBKPMyMvh FDF5ZLeE12rp/pWLlmPMIh70KLnV4I0vaGLuarTo=
X-Quarantine-ID: <wBWGAVSy_yIe>
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (unknown [50.225.209.66]) (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 4FhZJp3DdGz6G7rG; Fri, 14 May 2021 09:50:18 -0700 (PDT)
To: Igor Bryskin <i_bryskin@yahoo.com>, "teas@ietf.org" <teas@ietf.org>
References: <c7bb7462db8f4149912d644adbd4760b@huawei.com> <e8e5e968-f6af-a910-d2ec-510fc98ff1d6@joelhalpern.com> <16d8b18dc5574d728842f086227efa97@huawei.com> <db806eb6-7d24-b0ce-4bd7-a286cfb08b98@joelhalpern.com> <1461772929.643501.1621010751444@mail.yahoo.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <3f58f32a-e6ca-e425-75d0-c7a07dfbe094@joelhalpern.com>
Date: Fri, 14 May 2021 12:50:17 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1
MIME-Version: 1.0
In-Reply-To: <1461772929.643501.1621010751444@mail.yahoo.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/51j7FIOwYrK_82RFM3KV5tAlaUQ>
Subject: Re: [Teas] A draft on the framework for end-to-end IETF network slicing
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: Fri, 14 May 2021 16:50:25 -0000

The answer seems to depend upon ones perspective.  While I have an 
opinion (maybe even several) about where our IETF network slice 
(service or interface) definitions will end up, I do not speak for the 
community.  Until we have arrived, I will treat these things as distinct.

On 5/14/2021 12:45 PM, Igor Bryskin wrote:
> Hi Joel,
> 
> Suppose a TE service/tunnel is requested and set up connecting access 
> points A and B across the network. Can I consider such a tunnel as a 
> trivial IETF network slice? If not, why? If yes. why not to reduce, 
> generally speaking, the  IETF network slice problem to the problem of 
> p2p and p2mp TE tunnels interconnecting IETF slice end points? For 
> example, we have spent a lot of time discussing e2e multi-domain TE 
> tunnels and how their segments in each domain are identified, 
> associated, etc. Is it necessary or useful in your opinion to repeat the 
> discussion in the context of slicing?
> 
> 
> Thanks,
> Igor
> 
> 
> On Friday, May 14, 2021, 12:05:44 AM EDT, Joel M. Halpern 
> <jmh@joelhalpern.com> wrote:
> 
> 
> Do you mean traffic monitoring at the domain edges?  Or inside the
> domain?  If at the domain edges, then any mapping technology can also be
> used for monitoring.
> If inside the domain, this places a significant disaggregated statistics
> collection load on the internals of the network.
> Edge-to-Edge monitoring by the consumer (client? customer?) of the
> component is clealry useful.  But does not requrie such identification.
>    Nor does it requrie internal disaggregated state reporting.
> the internals presumably will monitor the aggregated behavior.  Which
> again does not require the identification.
> 
> Yours,
> Joel
> 
> On 5/13/2021 11:54 PM, Dongjie (Jimmy) wrote:
>  > Hi Joel,
>  >
>  > Thanks for your comments.
>  >
>  > The requirement of carrying network slice related identifier in the 
> data packet was described in 
> draft-dong-teas-enhanced-vpn-vtn-scalability and other relevant 
> documents. Currently there are several proposals about the encapsulation 
> of network slice related identifiers. Based on that, this document 
> further describes the considerations about the multi-domain IETF network 
> slice scenario, and the interaction with other technical domains for 5G 
> end-to-end network slicing.
>  >
>  > You are right that the path selection, resource allocation and 
> traffic handling would be based on the identifiers internal to a network 
> domain. As described in this draft, the end-to-end network slice 
> identifier may be used for traffic monitoring at the end-to-end network 
> slice granularity.
>  >
>  > Best regards,
>  > Jie
>  >
>  >> -----Original Message-----
>  >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com 
> <mailto:jmh@joelhalpern.com>]
>  >> Sent: Thursday, May 13, 2021 12:49 PM
>  >> To: Dongjie (Jimmy) <jie.dong@huawei.com 
> <mailto:jie.dong@huawei.com>>; teas@ietf.org <mailto:teas@ietf.org>
>  >> Subject: Re: [Teas] A draft on the framework for end-to-end IETF network
>  >> slicing
>  >>
>  >> It is not at all clear that any identifiers are needed inside the 
> various networks,
>  >> and specifically it is not clear that an internal identifier for the 
> end-to-end
>  >> network slice is needed at the level of the IETF network slice as is 
> being defined
>  >> by teas.  Since path selection, QoS parameter handling, and resource
>  >> allocation needs to be handled in aggregate, it seems likely that no 
> such
>  >> identifier is needed.
>  >>
>  >> Yours,
>  >> Joel
>  >>
>  >> On 5/12/2021 10:53 PM, Dongjie (Jimmy) wrote:
>  >>> Hi WG,
>  >>>
>  >>> Recently we published a draft on the framework for end-to-end IETF
>  >>> network slicing:
>  >>> 
> https://datatracker.ietf.org/doc/html/draft-li-teas-e2e-ietf-network-s 
> <https://datatracker.ietf.org/doc/html/draft-li-teas-e2e-ietf-network-s>
>  >>> licing
>  >>> 
> <https://datatracker.ietf.org/doc/html/draft-li-teas-e2e-ietf-network- 
> <https://datatracker.ietf.org/doc/html/draft-li-teas-e2e-ietf-network->
>  >>> slicing>
>  >>>
>  >>> This document describes the scenarios of end-to-end network slicing,
>  >>> and the framework of network slice mapping between different network
>  >>> segments and network domains. Multiple network slice related
>  >>> identifiers are defined to covers different network scopes.
>  >>>
>  >>> The network slice related identifiers of different network scopes can
>  >>> be instantiated with MPLS or IPv6 data plane, which are further
>  >>> described in the following drafts:
>  >>>
>  >>> 
> https://datatracker.ietf.org/doc/draft-li-mpls-e2e-ietf-network-slicin 
> <https://datatracker.ietf.org/doc/draft-li-mpls-e2e-ietf-network-slicin>
>  >>> g/
>  >>> 
> <https://datatracker.ietf.org/doc/draft-li-mpls-e2e-ietf-network-slici 
> <https://datatracker.ietf.org/doc/draft-li-mpls-e2e-ietf-network-slici>
>  >>> ng/>
>  >>>
>  >>> 
> https://datatracker.ietf.org/doc/html/draft-li-6man-e2e-ietf-network-s 
> <https://datatracker.ietf.org/doc/html/draft-li-6man-e2e-ietf-network-s>
>  >>> licing
>  >>> 
> <https://datatracker.ietf.org/doc/html/draft-li-6man-e2e-ietf-network- 
> <https://datatracker.ietf.org/doc/html/draft-li-6man-e2e-ietf-network->
>  >>> slicing>
>  >>>
>  >>> 
> https://datatracker.ietf.org/doc/html/draft-li-spring-sr-e2e-ietf-netw 
> <https://datatracker.ietf.org/doc/html/draft-li-spring-sr-e2e-ietf-netw>
>  >>> ork-slicing
>  >>> 
> <https://datatracker.ietf.org/doc/html/draft-li-spring-sr-e2e-ietf-net 
> <https://datatracker.ietf.org/doc/html/draft-li-spring-sr-e2e-ietf-net>
>  >>> work-slicing>
>  >>>
>  >>> Your review and comments are welcome. (Comments on the specific data
>  >>> plane draft can go to the corresponding WG mail list).
>  >>>
>  >>> Best regards,
>  >>>
>  >>> Jie
>  >>>
>  >>>
>  >>> _______________________________________________
>  >>> Teas mailing list
>  >>> Teas@ietf.org <mailto:Teas@ietf.org>
>  >>> https://www.ietf.org/mailman/listinfo/teas 
> <https://www.ietf.org/mailman/listinfo/teas>
>  >>>
> 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org <mailto:Teas@ietf.org>
> https://www.ietf.org/mailman/listinfo/teas 
> <https://www.ietf.org/mailman/listinfo/teas>

v2.23.0 | Report a Bug | By Email