Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

peng.shaofu@zte.com.cn Sun, 07 February 2021 10:14 UTC

Return-Path: <peng.shaofu@zte.com.cn>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2362B3AFB92; Sun, 7 Feb 2021 02:14:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level:
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 3VoJXx8w5lnp; Sun, 7 Feb 2021 02:14:57 -0800 (PST)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (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 0E7CF3AFB04; Sun, 7 Feb 2021 02:14:55 -0800 (PST)
Received: from mxct.zte.com.cn (unknown [192.168.164.215]) by Forcepoint Email with ESMTPS id AF64BE8BF6F37D1874DB; Sun, 7 Feb 2021 18:14:52 +0800 (CST)
Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) by Forcepoint Email with ESMTPS id 93AE0DDD731836876CCC; Sun, 7 Feb 2021 18:14:52 +0800 (CST)
Received: from njxapp02.zte.com.cn ([10.41.132.201]) by mse-fl1.zte.com.cn with SMTP id 117AEjY0091215; Sun, 7 Feb 2021 18:14:46 +0800 (GMT-8) (envelope-from peng.shaofu@zte.com.cn)
Received: from mapi (njxapp02[null]) by mapi (Zmail) with MAPI id mid201; Sun, 7 Feb 2021 18:14:45 +0800 (CST)
Date: Sun, 7 Feb 2021 18:14:45 +0800 (CST)
X-Zmail-TransId: 2afa601fbd9506bc66ad
X-Mailer: Zmail v1.0
Message-ID: <202102071814457687137@zte.com.cn>
In-Reply-To: <b0bd9a208dd94376bdb8277bde3c0ae1@huawei.com>
References: MN2PR13MB42061AD1E295598F1F2726BDD2BB9@MN2PR13MB4206.namprd13.prod.outlook.com, 202102071153129945093@zte.com.cn, b0bd9a208dd94376bdb8277bde3c0ae1@huawei.com
Mime-Version: 1.0
From: <peng.shaofu@zte.com.cn>
To: <jie.dong@huawei.com>
Cc: <james.n.guichard@futurewei.com>, <spring@ietf.org>, <spring-chairs@ietf.org>
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn 117AEjY0091215
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/sgyRpAW5kzcUCdat9FtW15PPbRM>
Subject: Re: [spring] =?utf-8?q?WG_Adoption_Call_for_draft-dong-spring-sr-for?= =?utf-8?q?-enhanced-vpn?=
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Feb 2021 10:14:59 -0000

Hi Jie,






Thanks for you reply. 


Please see in-line [PSF]






Regards,


PSF






 

 




From: spring [mailto:spring-bounces@ietf.org] On Behalf Of peng.shaofu@zte.com.cn
 Sent: Sunday, February 7, 2021 11:53 AM
 To: james.n.guichard@futurewei.com
 Cc: spring@ietf.org; spring-chairs@ietf.org
 Subject: Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn




 

 

Hi WG/authors,

 

I have to point out that the VTN-ID in draft-dong-spring-sr-for-enhanced-vpn is actually the AII in draft-peng-teas-network-slicing, just a new name. That can be seen from the evolution of the historical versions of the these two drafts. 

 

[Jie] The VTN (virtual network) concept is introduced in draft-ietf-teas-enhanced-vpn, which is long before the draft you mentioned.

In control plane, a VTN can be identified by existing control plane IDs, and VTN-ID is used when multiple VTNs share the same topology. IMO this is different from what the AII is used for.




[PSF] No, Let's look at the timeline. 

[PSF] draft-peng-lsr-network-slicing-00 (February 25, 2019) first discussed the introduction of slice based identifier in control plane and forwarding plane, which we call AII.

[PSF] Before that, the previous control plane schemes of Enhanced VPN, such as draft-dong-lsr-sr-enhanced-vpn-01 (October 22, 2018), have been discussed always based on MTR ID. You originally think that a slice is an MTR.

[PSF] After that, the later control plane schemes of Enhanced VPN, such as draft-dong-lsr-sr-enhanced-vpn-02 (November 4, 2019), also discussed the introduction of slice based identifier in control plane and forwarding plane, which you call TNSI.

[PSF] In fact, VTN was formally defined till in draft-ietf-teas-enhanced-vpn-05 (2020.2.18). Before that, you mentioned that it is a sub topology that is a virtual SR network composed of a group of SIDs (with associated resources). However, it does not describe how to create this virtual SR network. That is the key issue. Note that the so-called "using a set of SIDs to form a virtual SR network" is putting the cart before the horse. My means is that, for example, people can create Flex-algo plane based on the key ID, i.e, algorithm with its related FAD, while SID per algorithm is just an attribute of the created Flex-algo plane. Nobody knows how the Flex-algo plane is created just according to "a set of SIDs per algorithm". 

[PSF] Anyway, what I mentioned is a slice based ID introduced in the control and forwarding plane, but you mention VTN concept, they are NOT the same thing. Once the slice based ID is introduced, it can be used to distinguish which slice the service belongs to, and that is not related with whether different slice can or not share the same topology. 




I draw your attention to draft draft-peng-teas-network-slicing which analyzes in detail the reasons for the introduction of slice identifier (AII) in the network, and maintains the resource partition of each slice and the allocation of SID per AII in the network. All this happened before draft-dong-spring-sr-for-enhanced-vpn.

 

[Jie] If you follow the SPRING WG closely, you would know that the first version of draft-dong-spring-sr-for-enhanced-vpn was submitted in March 2018, which is one and a half year earlier than the draft you mentioned.

And if you want people to read or discuss another draft, you could start a thread in the WG which the draft belongs to.

 

[PSF] Sure, but it seems that it has no substance mechanism to create the virtual SR network? You might say "using a set of SIDs to form a virtual SR network", that is  putting the cart before the horse IMO.



In addition, the idea that multiple slices share the same virtual topology (such as flex-algo) is also copied from draft-bestbar-teas-ns-packet, which can significantly reduce the state in the network, especially without maintaining SPT per slice, which means that multiple SIDs per slice can share the forwarding action of SPT per VN and at the same time can do resource guarantee by SID per slice (or slice-id in packet).

 

[Jie] The mechanism of multiple VTNs sharing the same topology was first described in draft-dong-teas-enhanced-vpn-vtn-scalability one year ago in Feb 2020. Further discussion about the scalability optimizations in that document will happen in the TEAS WG.




[PSF] Thanks for clarification for this point. draft-bestbar-spring-scalable-ns clearly desribed that multiple per slice Prefix-SIDs (Slice Prefix-SIDs) can be assigned for the same prefix such that they all share the same IGP computed path over one topology and optimized for one algorithm to allow the steering of traffic to the same prefix along a path but over different network slices. If that is exactly what did draft-dong-teas-enhanced-vpn-vtn-scalability(5.1. Control Plane Optimization) want to do, I suggest adding an explicit description similar as draft-bestbar-spring-scalable-ns.




 

Best regards,

Jie

 

Thus, from a purely technical point of view, I see no reason for this document to be adopted. 

 

Regards,

PSF

 

 

 


原始邮件



发件人:JamesGuichard



收件人:spring@ietf.org;



抄送人:spring-chairs@ietf.org;



日 期 :2021年01月27日 19:47



主 题 :[spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn




_______________________________________________
 spring mailing list
 spring@ietf.org
 https://www.ietf.org/mailman/listinfo/spring


Dear WG:


 


This message starts a 2 week WG adoption call for https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/ ending February 10th 2021.


 


After review of the document please indicate support (or not) for WG adoption to the mailing list and if you are willing to work on the document, please state this explicitly. This gives the chairs an indication of the energy level of people in the working group willing to work on this document. Please also provide comments/reasons for your support (or lack thereof) as this is a stronger way to indicate your (non) support as this is not a vote.


 


Thanks!


 


Jim, Bruno & Joel