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

From: Zhuangzhuang Qin(联通北京市北京市分公司) <[email-masked]>
Date: Fri, 17 Jul 2020 06:23:40 +0000

Hi WG,

From the  service provider's perspective ,  we  really need some SR enhancement for virtual networks & resource awareness. So I support adoption the draft  firstly and more deep discussions about control-plane should be  done.

Best Regards

ZhuangZhuang Qin ([email-masked])

ChinaUnicom

如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 [email-masked]，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received this email in error please notify us immediately by e-mail. Please reply to [email-masked] ,you can unsubscribe from this mail. We will immediately remove your information from send catalogue of our.

---

From: "Francois Clad (fclad)" <[email-masked]>
Date: Tue, 21 Jul 2020 16:18:09 +0000

Hi,

As a co-author, I support the adoption of this draft.

Thanks,
Francois

From: spring <[email-masked]> on behalf of James Guichard <[email-masked]>
Date: Wednesday 15 July 2020 at 13:17
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Dear WG:

This email begins a 2 week WG adoption call for https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/ ending Wednesday 29th July 2020.

Please speak up if you support or oppose adopting this document into the WG. Please also provide comments/reasons for that support (or lack thereof). Silence will not be considered consent.

Thanks!

Jim, Joel & Bruno

---

From: Yingzhen Qu <[email-masked]>
Date: Mon, 27 Jul 2020 00:19:12 +0000

I support the adoption of this draft. The proposal provides a useful extension of SR regarding network resources.

I have the following suggestions for the authors to consider:

  *   The draft is very slicing/virtual network focused, however the proposal can be used in generic cases, e.g. with SR-TE. I’d suggest adding some text or use cases, or as a special case of a virtual network.
  *   About scalability especially in SR-MPLS, the label range is limited. It’s mentioned in section 2.1, but could use some elaborations.

Thanks,
Yingzhen

From: spring <[email-masked]> on behalf of James Guichard <[email-masked]>
Date: Wednesday, July 15, 2020 at 4:17 AM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn
Resent-From: <[email-masked]>

Dear WG:

This email begins a 2 week WG adoption call for https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dong-spring-sr-for-enhanced-vpn%2F&data=02%7C01%7Cyingzhen.qu%40futurewei.com%7C62940ff55d094466bef508d828b0b08d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637304086634789052&sdata=Q3G9%2F7b4cyRLRpre%2B%2F%2BVLMJYY88ut0GbceKauulQXG0%3D&reserved=0> ending Wednesday 29th July 2020.

Thanks!

Jim, Joel & Bruno

---

From: <[email-masked]>
Date: Wed, 29 Jul 2020 12:43:58 +0800 (CST)

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