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

xiong.quan@zte.com.cn Wed, 29 July 2020 04:44 UTC

Return-Path: <xiong.quan@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 9F01A3A0E2E; Tue, 28 Jul 2020 21:44:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 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] 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 D05Oe9F4lHiU; Tue, 28 Jul 2020 21:44:03 -0700 (PDT)
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 D69423A0E25; Tue, 28 Jul 2020 21:44:02 -0700 (PDT)
Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id 8A6F9DF8CC8B43B5A661; Wed, 29 Jul 2020 12:44:00 +0800 (CST)
Received: from njxapp02.zte.com.cn ([10.41.132.201]) by mse-fl2.zte.com.cn with SMTP id 06T4hxYU048608; Wed, 29 Jul 2020 12:43:59 +0800 (GMT-8) (envelope-from xiong.quan@zte.com.cn)
Received: from mapi (njxapp03[null]) by mapi (Zmail) with MAPI id mid201; Wed, 29 Jul 2020 12:43:58 +0800 (CST)
Date: Wed, 29 Jul 2020 12:43:58 +0800
X-Zmail-TransId: 2afb5f20fe8edac284ba
X-Mailer: Zmail v1.0
Message-ID: <202007291243587638486@zte.com.cn>
Mime-Version: 1.0
From: xiong.quan@zte.com.cn
To: james.n.guichard@futurewei.com
Cc: spring@ietf.org, spring-chairs@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 06T4hxYU048608
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/j2ny1FMendtsqPsfoRU-4pGlz-U>
Subject: Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-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: Wed, 29 Jul 2020 04:44:06 -0000

Dear Chairs and Authors,

I have reviewed the draft in details. I don't think the draft is ready to be adopted.
In my view, the draft does not propose any new mechanism or idea beyond the existing solutions that have already been provided.

The following are my questions about the description of the main sections.
 
Question 1, In sectoin 2 “This section describes the mechanisms of using SR SIDs to identify the additional resource information of virtual networks or paths with the two SR data plane instantiations: SR-MPLS and SRv6."
The mechanism is not specified clearly. For SR-MPLS it mentioned serveral existing approaches to partition link resource, but it does not mention the mechanism, for example, how to identify each type of resource in SR architecture and how to allocate a SID for a specific resource and associate it. The whole section is the repeated informational statement that may add resources semantics to existing SIDs, no detailed mechanism actually. For SRv6 it focus on virtual network and suggest different Locators for different VNs, that is already well known to us according to section 13.2 of draft-ietf-lsr-flex-algo. Actually no mechanism too.
 
Question 2, In section 3 “A distributed control plane can be used for the collection and distribution of the network topology and resource information of the virtual networks among network nodes.”
Although the details of control plane are out of its scope, we have not seen the analysis how many kinds of resources are there at present or future potentially and the overview of the announcement of these resources within SR architecture.
 
Question 3, In section 4 “The subset of network topology and network resources together constitute a virtual network" and "Following the segment routing paradigm, the network topology and resource is represented using a group of dedicated SIDs. The group of prefix-SIDs and adj-SIDs allocated for a virtual network will be used by network nodes and the network controller to construct an SR based virtual network, which is considered as the underlay network for the service. "
SR based virtual network is a vague statement and need to be defined clearly. The virtual network is never created by SIDs, and SIDs are just the attribute of VN that is created by other means. In the link-state database, it is the virtual network identifier that distinguishes different VN, so it is strange to use a group of SIDs to represent a VN. Although VN specific SIDs will be allocated after SR is combined with VN, but using VN specific SIDs to represent VN is to reverse causality. The so-called SR based virtual network is an external manifestation of SR combined with VN. There is a VN specific SID list for an SR path within the specific VN, but not a so-called SR based virtual network.
 
Question 4, In section 4.1 "When a service request is received from a tenant, the controller computes the subset of the network topology, along with the set of the resources needed on each network segment (e.g. links and nodes) in the topology to meet the tenant's service requirements."
This is just a simple informational statement. We have not seen the overview analysis that during path computation how to perceive or trigger these partitioned resources then for reservation within SR architecture. The section is just a statement that we all known.
 
Question 5, In section 4.2 "The network resources are allocated on a per virtual network basis, and represented by a group of SIDs. Such group of dedicated SIDs, e.g. prefix-SIDs and adj-SIDs are used to represent the virtual network and the network resources allocated on each network segment for this virtual network."
It is a repeated description. We have not seen the overview analysis that how many kinds of resources are there at present or future potentially. The resouce is pre-existing or dynamically triggered ? Is there overview analysis that how to idenftify each resouce (especially if there are new type of resouce this document want to introduce ?) and allocate SID for these resources within SR architecture?
 
Question 6, In section 4.3 "each network node SHOULD advertise the identifiers of the virtual networks it participates in, together with the group of SIDs and the associated resource attributes both to other nodes in the network and to the controller. This can be achieved by IGP extensions in [I-D.dong-lsr-sr-enhanced-vpn] and BGP-LS extensions in[I-D.dong-idr-bgpls-sr-enhanced-vpn]."
This section describes that it is the identifier of VN as the KEY to create VN, and VN specific SIDs are just attributes. So that the so-called SR based Virtual Network is a vague statement. It is clear that path computation can be within VN, but not clear within SR based VN (i.e., a group of SIDs). Maybe we can say some KEY based VN, eg, MT based VN, algorithm based VN, etc. For example, we can use algorithm to represent a flex-algo plane, and we all know different flex-algo plane has different algorithm-based SID, so the declaration of using a group of algorithm-based SIDs to represent a flex-algo plane does not introduce any more information than using algorithm itself. Such declaration is like a market strategy, new in order to be different. BTW, this document and the above IGP extensions [I-D.dong-lsr-sr-enhanced-vpn] and BGP-LS extensions [I-D.dong-idr-bgpls-sr-enhanced-vpn] implys that resouce-meanning and enhance vpn are relevant.
Could you please clarify them? Thanks!

 
Best Regards,
Quan