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

"Joel M. Halpern" <> Fri, 14 May 2021 04:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3D8053A2104 for <>; Thu, 13 May 2021 21:05:35 -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 Dbvi8NKiwOIj for <>; Thu, 13 May 2021 21:05:30 -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 912673A2106 for <>; Thu, 13 May 2021 21:05:30 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4FhFLK5pxCz6G9n7; Thu, 13 May 2021 21:05:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=2.tigertech; t=1620965129; bh=CUlISy03bzBb+QKctZTVfRO4HCFZaZSW9qMiFM2F0R4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=afdSRwA+aL6GdKNcplO4nPIxfDZgGlej+QQBmgy8INdsX2r3udRi2j7aRoD4DJe6f s7Zj4s1cNqzMZyuHcKMz18P5f7KpXDibURWSP/XfOG6HTT4Pwd1Ufi8lj+uR4Fp4E2 q6WrNF1ahVv5eXBRARmDnTVs03hJSKB/Gs16rMmQ=
X-Quarantine-ID: <wBIJoQSJFZcx>
X-Virus-Scanned: Debian amavisd-new at
Received: from [] (unknown []) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4FhFLJ6mPxz6G9n5; Thu, 13 May 2021 21:05:28 -0700 (PDT)
To: "Dongjie (Jimmy)" <>, "" <>
References: <> <> <>
From: "Joel M. Halpern" <>
Message-ID: <>
Date: Fri, 14 May 2021 00:05:27 -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: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Teas] A draft on the framework for end-to-end IETF network slicing
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: Fri, 14 May 2021 04:05:35 -0000

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.


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 []
>> Sent: Thursday, May 13, 2021 12:49 PM
>> To: Dongjie (Jimmy) <>;
>> 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:
>>> licing
>>> <
>>> 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:
>>> g/
>>> <
>>> ng/>
>>> licing
>>> <
>>> slicing>
>>> ork-slicing
>>> <
>>> 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