Re: [Teas] Some comments on draft-ali-teas-spring-ns-building-blocks Tue, 03 August 2021 10:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E8D373A1E6D; Tue, 3 Aug 2021 03:52:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lGmNZHzZIjO5; Tue, 3 Aug 2021 03:52:53 -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 129D93A1E71; Tue, 3 Aug 2021 03:52:52 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTPS id EA77B4FEB3D3CE0505B0; Tue, 3 Aug 2021 18:49:21 +0800 (CST)
Received: from (unknown []) by Forcepoint Email with ESMTPS id C1723CE251E0F1707950; Tue, 3 Aug 2021 18:49:21 +0800 (CST)
Received: from ([]) by with SMTP id 173AmtBb065490; Tue, 3 Aug 2021 18:48:55 +0800 (GMT-8) (envelope-from
Received: from mapi (njxapp01[null]) by mapi (Zmail) with MAPI id mid201; Tue, 3 Aug 2021 18:48:55 +0800 (CST)
Date: Tue, 3 Aug 2021 18:48:55 +0800 (CST)
X-Zmail-TransId: 2af961091f1791043e22
X-Mailer: Zmail v1.0
Message-ID: <>
In-Reply-To: <>
Mime-Version: 1.0
From: <>
To: <>
Cc: <>, <>, <>
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: 173AmtBb065490
Archived-At: <>
Subject: Re: [Teas] =?utf-8?q?Some_comments_on_draft-ali-teas-spring-ns-build?= =?utf-8?q?ing-blocks?=
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, 03 Aug 2021 10:52:58 -0000

Hi Zhibo,

See in-line [PSF].


抄送人:Dongjie (Jimmy);;;
日 期 :2021年08月03日 17:20
主 题 :RE: [Teas]  Some comments on draft-ali-teas-spring-ns-building-blocks

Both the VTN and AII identify the underlay of the slice. 
[PSF] that is right.

However, the VTN-ID is not used as an identifier of the control plane topology. Instead, the topology of the slice is defined by referencing an existing multi-topology technology.
VTN-ID defines the topology and resources of a slice by decoupling the topology and resources, which are different from AII. 
[PSF] Whether it is customizing slice's own topology (such as AII) or referencing an existing topology (such as VTN-ID), there is a logical topology for slice. So VTN-ID is also actually an identifier of logical topology. And, both AII and VTN-ID are used to identify resouce. So, the smallest difference for AII and VTN-ID is the flavor to create the logical topology. Note that draft-bestbar-teas-ns-packet contains both customizing and referencing flavor.

As mentioned in the previous email, the agreement is to find a common new term for network slice realization.
[PSF] Agree, alignment with some new term, but not VTN according to Dongjie's original mail.

Best regards,
-----Original Message-----
From: Teas [] On Behalf Of
Sent: Tuesday, August 3, 2021 12:37 PM
To: Huzhibo <>
Cc: Dongjie (Jimmy) <>om>;;
Subject: Re: [Teas] Some comments on draft-ali-teas-spring-ns-building-blocks

Hi Zhibo,

First, when aii was proposed in draft-peng-teas-network-slicing to introduce slice identifier to underlay network, it was not good just to change its name as vtn-id in redundant draft, for example, just open and to see the repeat and overlap.
Second, SA-ID defined in draft-bestbar-teas-ns-packet has completely covered aii and vtn-id, especially when the mapping of slice and Slice-Aggregate is 1:1.
So that there is not any reason for you to continue to update vtn-id concept, and even ask other proposals to be alignment with VTN.


收件人:彭少富10053815;Dongjie (Jimmy);
日 期 :2021年08月02日 20:21
主 题 :RE: Re:[Teas] Some comments on draft-ali-teas-spring-ns-building-blocks
The discussion Jie referred to was the about the terminology alignment between VTN, Slice Aggregate, etc. in several active network slice related drafts. With the "merging" of draft-peng-teas-network-slicing into draft-bestbar-teas-ns-packet, it is not clear whether the term "AII" has been totally replaced by "Slice Aggregate", or you still plan to work on it separately?
After the discussion among the authors of several drafts, the agreement is to find a common new term for network slice realization, so that those drafts could refer to that new term. This is also what we suggested to the authors of draft-ali-teas-spring-ns-building-blocks for better terminology alignment.
Best regards,
-----Original Message-----
From: []
Sent: Monday, August 2, 2021 5:39 PM
To: Dongjie (Jimmy) <>
Subject: Re:[Teas] Some comments on draft-ali-teas-spring-ns-building-blocks
Hi Dongjie,
Seeing that you openly mention VTN-ID, I have to remind you again that the VTN-ID is just the A-I-I of draft-peng-teas-network-slicing which analyzes the necessity of introducing slice identifier into underlay network. I believe you never thought about dealing with the overlap of VTN-ID and A-I-I, so how can you ask other drafts to do so?
Again, you may say that the A-I-I related scheme described by draft-peng-teas-network-slicing has scalability problems ... ... so that VTN-ID is not A-I-I... ...
抄送人:TEAS WG;
日 期 :2021年08月02日 17:07
主 题 :[Teas] Some comments on draft-ali-teas-spring-ns-building-blocks
Teas mailing list
Hi authors,
Thanks for the presentation in the TEAS session in last week. Here are some comments on this draft:
1.      As discussed on the TEAS meeting, the terminologies in several drafts related to network slicing realization will be aligned, thus it is suggested the terminology in this document also aligns with the "new term"  to be proposed.
2.      As this document lists the SR technologies which can be used for network slice realization in SR networks, the suggestion is it should also describe and reference draft-ietf-spring-resource-aware-segments and  draft-ietf-spring-sr-for-enhanced-vpn which specifies the extensions to SR segments and the mechanisms to provide SR based VTNs.
3.      Section 8 of this document describes the "stateless network slice ID" concept and the mechanisms with different data planes. The general mechanism of introducing dedicated VTN identifier in data packet for per-VTN  packet processing was described in draft-dong-teas-enhanced-vpn-vtn-scalability, thus there is some overlap in this part which needs to be solved in future versions.
Best regards,