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

From: James Guichard <[email-masked]>
Date: Wed, 15 Jul 2020 11:16:51 +0000

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: Zhuangshunwan <[email-masked]>
Date: Wed, 15 Jul 2020 12:28:04 +0000

Hi Jim, Joel & Bruno,

This document proposes a reasonable enhancement to SR, which makes SR a suitable technology for wider range of services and network scenarios.
I support the WG adoption of this useful document.

Thanks,
Shunwan

From: spring [mailto:[email-masked]] On Behalf Of James Guichard
Sent: Wednesday, July 15, 2020 7:17 PM
To: [email-masked]
Cc: [email-masked]
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Dear WG:

Thanks!

Jim, Joel & Bruno

---

From: Huzhibo <[email-masked]>
Date: Wed, 15 Jul 2020 13:27:44 +0000

Hi WG,

I support the WG adoption. It is a useful enhancement to SR and can provides better network SLA assurance capabilities.

Thanks,
Zhibo

Dear WG:

Thanks!

Jim, Joel & Bruno

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 15 Jul 2020 21:34:23 +0800

AS a coauthor, I support this adoption.

I believe the new kind of SID introduced in this doc, the resource-aware SID, is a significant extension to SR to enable the VPN+ service defined in draft-ietf-teas-enhanced-vpn.

Best Regards,
Zhenqiang Li

[email-masked]
 
From: James Guichard
Date: 2020-07-15 19:16
To: [email-masked]
CC: [email-masked]
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn
Dear WG:

 
Thanks!
 
Jim, Joel & Bruno

---

From: "qinfengwei" <[email-masked]>
Date: Wed, 15 Jul 2020 21:43:48 +0800

Hi,

         Adding resource semantic to SR SIDs is an useful feature for
operator to meet different customers service requirement in SR based
network, and this document is in a good shape. Thus I support the adoption
as co-author.

 

Thanks,

Fengwei Qin

发件人: spring [mailto:[email-masked]] 代表 James Guichard
发送时间: 2020年7月15日 19:17
收件人: [email-masked]
抄送: [email-masked]
主题: [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: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Wed, 15 Jul 2020 15:03:01 +0000

Very useful use case for Segment routing technology, and very well written document.
I do support the WG adoption of this draft.

Thanks
Jingrong Xie

Dear WG:

Thanks!

Jim, Joel & Bruno

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 15 Jul 2020 09:31:44 -0700

Yes/support

Regards,
Jeff

> On Jul 15, 2020, at 04:17, James Guichard <[email-masked]> wrote:
> 
> 
> Dear WG:
>  
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 15 Jul 2020 13:11:44 -0400

I support WG adoption and agree it’s a very useful use case of SR
technology.

I really like the concept that it  utilizes the TEAS context of network
slicing construct of virtualization of physical PE / P core infrastructure,
containerization with this new enhancement VPN framework for critical 5G
RAN or other service chains of critical VPN services that require more then
just BAU QOS for guaranteed IP SLA delivery.

Thanks

Gya

On Wed, Jul 15, 2020 at 12:31 PM Jeff Tantsura <[email-masked]>
wrote:

> 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
>
>
>
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: stefano previdi <[email-masked]>
Date: Wed, 15 Jul 2020 20:14:15 +0200

I support the adoption of this document.

Thanks.
s.

> On Jul 15, 2020, at 1:16 PM, James Guichard <[email-masked]> wrote:
> 
> Dear WG:
>

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 15 Jul 2020 20:53:32 +0000

I support the WG adoption of this draft.

I think it is a really good idea for each Virtual Network to have its own SIDs.
A couple questions to the authors:

Page 9: Figure 1: The Red network has same SID on A & B for the path between them. But between B & E there are different SIDs. Is it intended?
What scenario requires same SID on both nodes?

Page 10: Section 4.3: the paragraph states that each node should advertise the identifiers of the Virtual networks it participates in: 1) does each Virtual Network has its own advertisement?  i.e. if a node supports 5 Virtual Networks, the node sends out 5 independent advertisements?  2) The network controller configures the SIDs for each node. Why not let the network controller manage the advertisement?

Cheers,
Linda

From: spring <[email-masked]> On Behalf Of James Guichard
Sent: Wednesday, July 15, 2020 6:17 AM
To: [email-masked]
Cc: [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/<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%7Clinda.dunbar%40futurewei.com%7Cf03a8de844774eb62c1508d828b09948%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637304086252107481&sdata=G75TrLzE%2FhSgHuwP4cClUusCr%2BofY0C1Kq%2Fq9CBDOwE%3D&reserved=0> ending Wednesday 29th July 2020.

Thanks!

Jim, Joel & Bruno

---

From: <[email-masked]>
Date: Thu, 16 Jul 2020 08:02:04 +0800

Dear WG, 

The mechanism introduced to SR by this document would be very useful for our
network, which will provide both 5G and various business services. I support
the adoption as coauthor. 

Best regards,

Zhu Yongqing

发件人: spring <[email-masked]> 代表 James Guichard
发送时间: 2020年7月15日 19:17
收件人: [email-masked]
抄送: [email-masked]
主题: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Dear WG:

Thanks!

Jim, Joel & Bruno

---

From: "Peng Liu" <[email-masked]>
Date: Thu, 16 Jul 2020 08:56:44 +0800

Hi All,

I support the adoption of the draft. 

Regards,
Peng Liu

[email-masked]
 
From: James Guichard
Date: 2020-07-15 19:16
To: [email-masked]

 
Thanks!
 
Jim, Joel & Bruno

---

From: Mach Chen <[email-masked]>
Date: Thu, 16 Jul 2020 01:45:50 +0000

Hi,

I have read several versions of this draft, I think this is a useful work, hence support the adoption!

One comment about the draft, it's better to decouple this draft a bit from network slicing, since it can be as a basic function that can not only be used for network slicing, but be used for other scenarios.

Best regards,
Mach

Dear WG:

Thanks!

Jim, Joel & Bruno

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 16 Jul 2020 10:09:46 +0800

Hi WG，

   I support this document，because it is a useful solution, especially for 5g scenarios and networks with strong SLA requirements.
Thanks,
Zhao Feng

Internet Center, Research Institute of Technology and Standard, China Academy of Information and Communication Technology

China TTL Labs
 
Add: Building Block B-608, No.52 HuaYuan North Road Beijing, P.R.China, 100191
Mail: [email-masked]
Tel: 86-10-62300055
Mobile: 8613601068212
Fax: 86-10-62300094

From: James Guichard
Date: 2020-07-15 19:16
To: [email-masked]

 
Thanks!
 
Jim, Joel & Bruno

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 16 Jul 2020 02:20:32 +0000

Hi Linda,

Thanks a lot for your support and comments. Please see some replies inline with [Jie]:

From: spring [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Thursday, July 16, 2020 4:54 AM
To: James Guichard <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

[Jie] The value of SIDs in the figure is just an example. As the value of adj-SID is local-significant, and represents a unidirectional link, it is possible to have the same SID value used at different directions of a link, and it also allows to use different SID value on different links or different directions of the same virtual network.

[Jie] The advertisement of SIDs can be done with either centralized control or distributed control plane. The details are specified in separate documents in relevant WGs. Your review and comments on them are appreciated.

Best regards,
Jie

Cheers,
Linda

From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of James Guichard
Sent: Wednesday, July 15, 2020 6:17 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Dear WG:

Thanks!

Jim, Joel & Bruno

---

From: Ran Pang(联通集团联通网络技术研究院本部) <[email-masked]>
Date: Thu, 16 Jul 2020 02:39:34 +0000

Hi WG,

I support the adoption of this draft. The mechanism introduced in this draft will be useful to meet diverse service requirement.

Thanks,
Ran

From: James Guichard<mailto:[email-masked]>
Date: 2020-07-15 19:16
To: [email-masked]<mailto:[email-masked]>
CC: [email-masked]<mailto:[email-masked]>
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn
Dear WG:

Thanks!

Jim, Joel & Bruno

如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 [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: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 16 Jul 2020 02:45:51 +0000

Hi Mach,

Thanks for your support and comment.

I totally agree that this document provides an generic mechanism, which could be used in many scenarios not limited to network slicing. We have reduced the text about network slicing in this document, and will continue to follow this direction in future.

Best regards,
Jie

From: spring [mailto:[email-masked]] On Behalf Of Mach Chen
Sent: Thursday, July 16, 2020 9:46 AM
To: James Guichard <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Hi,

Best regards,
Mach

Dear WG:

Thanks!

Jim, Joel & Bruno

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 16 Jul 2020 12:01:35 +0800

Yes/Support.

Resource-Aware SID can be used to accomplish the determined QoS requirements
of the specified services. 

Best Regards

Aijun Wang

China Telecom

From: [email-masked] [mailto:[email-masked]] On Behalf Of
James Guichard
Sent: Wednesday, July 15, 2020 7:17 PM
To: [email-masked]
Cc: [email-masked]
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Dear WG:

Thanks!

Jim, Joel & Bruno

---

From: "Tomonobu Niwa" <[email-masked]>
Date: Thu, 16 Jul 2020 14:55:17 +0900

Dear WG,

I support the WG adoption. From operator perspective, it could be helpful to deploy network services with different SLA/SLO in SR network.

Best regards,
Tomo

---
************************************************************
Tomonobu Niwa
KDDI Corporation
TEL: +81-80-5074-9346
E-Mail: [email-masked]
************************************************************

-----Original Message-----
From: spring <[email-masked]> On Behalf Of James Guichard
Sent: Wednesday, July 15, 2020 8:17 PM
To: [email-masked]
Cc: [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/ <https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/>  ending Wednesday 29th July 2020. 

Thanks!

Jim, Joel & Bruno

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Fri, 17 Jul 2020 10:15:09 +0000

Hi WG,

I support the WG adoption.
The method introduced in the document is a reasonable extension to the semantics of SR SID, which could be used to meet specific requirements of some network scenarios.

Best Regards
Xuesong

Dear WG:

Thanks!

Jim, Joel & Bruno

---

From: Takuya Miyasaka <[email-masked]>
Date: Mon, 20 Jul 2020 11:22:19 +0900

AS a coauthor, I support this adoption. From an operator perspective, 
the idea brought by this draft is useful for the efficient resource 
reservation.

Thanks,
Takuya

> ending Wednesday 29^th 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

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Wed, 22 Jul 2020 03:10:37 +0000

Yes, support. The idea of SR for enhanced VPN is really clear and straight forward, and it is needed for sure.

Since the text is stable and mature, I support the adoption.

Respect,
Cheng

Dear WG:

Thanks!

Jim, Joel & Bruno

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 23 Jul 2020 18:27:20 +0000

Hi All,

This document seems to talk of "resource group" SIDs that is something interesting - specifically for SR-MPLS (I don't see the same relevance for SRv6).

I support the adoption of (what is coming across to me as) this concept of a new "resource group" scope for SR SIDs as a work item for the Spring WG. Rest should be moved into a separate informational document since all of that seem unrelated, nothing new and not suitable for a standards track document.

Therefore, the draft needs more work before it is ready for adoption.

Following are my more specific comments on this draft:

  1.  SR SIDs that are scoped to a MT or Algo or MT+Algo combination can already be associated with some "resources" on routers today. There is nothing new here to be standardized. If there is interest in the WG for documenting how resources are carved out and assigned to say a Flex-Algo and/or MT scoped SIDs, it should be in an independent informational document. There seems to be a lot of overlap of this with work in the TEAS WG. Much of Section 2 seems to be of this nature.

  1.  IGP SR SIDs are today scoped to an MT and Algo. This draft seems to be introducing another "resource group" type of scoping within an MT+Algo context for Prefix and Adjacency SIDs. When packets using SID labels belonging to a "resource group" arrive at a router, it helps the router associate those service flows to the QoS profile provisioned for that "resource group" on that specific link/router. This is what it seems is the whole essence of the proposal - but this is not clear in the document.  The routing of these SIDs is going to follow whatever MT and/or FlexAlgo computation provides - therefore, I am not sure I understand how these "resource group" SIDs are creating some new "Virtual Network Topology". Isn't this just a "network slice" of resources?

  1.  I am not sure how the discussion in Section 3 is bringing in anything new and again it is purely informational in nature. Perhaps I am not able to follow the point.

  1.  Much of Section 4 is also similarly informational in nature and about how some vendor/operator may want to use "resource group" SIDs. However, it does not formally and normatively define this new concept of "resource group" SIDs.  Other implementations and operators may choose to do this differently - so why standardize this one way? Discussion like assigning/allocation of SIDs, distribution of their information and setting up paths through the network using these SIDs are basic concepts of SR - not sure if they need description and repetition in a standards track document.

  1.  Section 5, Scalability is not giving the right picture. The proposal ends replicating each SID label forwarding entry (e.g. for prefix SID) multiplied by each "resource group" on each router simply for the sake of identifying QoS resources for it. That is not really scalable and will end up consuming a large set of label forwarding entries on the routers depending on the network scale and now many of these "slices" are instantiated.

  1.  Finally, I have an objection to the use of terms like "enhanced VPN" and "VPN+" in the document that sound more like marketing terms than technical terminologies. There was a similar comment made by one of the Spring chairs for a previous version, but I don't see it being addressed. VPNs might be but one of the services that can leverage the resource aware SIDs in their underlay.

I look forward to responses from the authors and updates to the document to address these comments.

Thanks,

Ketan

Sent: 15 July 2020 16:47

Dear WG:

Thanks!

Jim, Joel & Bruno

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 24 Jul 2020 14:10:42 +0000

Hi Ketan,

Thanks for your comment and support. Please see some replies inline:

From: spring [mailto:[email-masked]] On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, July 24, 2020 2:27 AM
To: James Guichard <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Hi All,

[Jie] SR-MPLS is used in the example described in this document, while the concept of resource-aware SID is generic to SR, and can be applicable to both SR-MPLS and SRv6.

[Jie] Thanks for supporting the introduction of resource semantics to SR SIDs.

A group of SR SIDs with such semantics can be used to build resource guaranteed SR paths or virtual networks. The mechanism and procedure for resource guaranteed virtual network is highlighted because the advantage of SR (no per-path state) can be utilized in per-virtual network resource allocation, which is more scalable than the per-path resource reservation in RSVP-TE. Thus it is an important and integral part of this document, as is reflected in the document title.

1)      SR SIDs that are scoped to a MT or Algo or MT+Algo combination can already be associated with some "resources" on routers today. There is nothing new here to be standardized. If there is interest in the WG for documenting how resources are carved out and assigned to say a Flex-Algo and/or MT scoped SIDs, it should be in an independent informational document. There seems to be a lot of overlap of this with work in the TEAS WG. Much of Section 2 seems to be of this nature.

[Jie] In this document resource refers to the data plane resource for packet processing and forwarding, which is not covered in the existing MT/Algo mechanism. As stated in this document, MT/Algo or the combination can be used as the control plane for advertising the topology and the resource attributes of the virtual network, the details of the control plane mechanism and extensions are specified in separate documents.

2)      IGP SR SIDs are today scoped to an MT and Algo. This draft seems to be introducing another "resource group" type of scoping within an MT+Algo context for Prefix and Adjacency SIDs. When packets using SID labels belonging to a "resource group" arrive at a router, it helps the router associate those service flows to the QoS profile provisioned for that "resource group" on that specific link/router. This is what it seems is the whole essence of the proposal - but this is not clear in the document.  The routing of these SIDs is going to follow whatever MT and/or FlexAlgo computation provides - therefore, I am not sure I understand how these "resource group" SIDs are creating some new "Virtual Network Topology". Isn't this just a "network slice" of resources?

[Jie] As defined in section 1, the resource semantic is one additional dimension represented by SIDs, which means the SID can be used to represent topology or function, together with the set of resources used to process the packet according to the function. The forwarding behavior of SIDs with both topology and resource semantics are described in section 2. In summary, the topology and resource are two aspects of the virtual network described in this document.

3)      I am not sure how the discussion in Section 3 is bringing in anything new and again it is purely informational in nature.. Perhaps I am not able to follow the point.

[Jie] It provides an overview of the associated control plane mechanisms, which is useful information to correlate this document and the control plane mechanisms needed. The details are provided in the control plane drafts in corresponding WGs.

4)      Much of Section 4 is also similarly informational in nature and about how some vendor/operator may want to use "resource group" SIDs. However, it does not formally and normatively define this new concept of "resource group" SIDs.  Other implementations and operators may choose to do this differently - so why standardize this one way? Discussion like assigning/allocation of SIDs, distribution of their information and setting up paths through the network using these SIDs are basic concepts of SR - not sure if they need description and repetition in a standards track document.

[Jie] This section provides the procedures of using resource-aware SIDs to build resource guaranteed virtual networks. These are based on the existing SR mechanism with procedures related to the allocation of resource-aware SIDs and the generation of corresponding forwarding entries. The procedure and example in this section is helpful for understanding the relationship and difference from the existing SR mechanism.

5)      Section 5, Scalability is not giving the right picture. The proposal ends replicating each SID label forwarding entry (e..g. for prefix SID) multiplied by each "resource group" on each router simply for the sake of identifying QoS resources for it. That is not really scalable and will end up consuming a large set of label forwarding entries on the routers depending on the network scale and now many of these "slices" are instantiated.

[Jie] It is stated in section 2 that additional SR SIDs are needed to identify the topology and resource associated with different virtual networks. The scalability discussion in section 5 compares the SR based approach with the existing RSVP-TE approach, and shows the benefit of using SR for building resource guaranteed virtual networks. For further scalability considerations about the number of virtual networks and its impact, please refer to draft-dong-teas-enhanced-vpn-vtn-scalability.

6)      Finally, I have an objection to the use of terms like "enhanced VPN" and "VPN+" in the document that sound more like marketing terms than technical terminologies.. There was a similar comment made by one of the Spring chairs for a previous version, but I don't see it being addressed. VPNs might be but one of the services that can leverage the resource aware SIDs in their underlay.

[Jie] The enhanced VPN (VPN+) framework is developed and adopted in TEAS, which aims to provide enhanced VPN service based on VPN and TE technologies with possible enhancements. Thus enhanced VPN is IETF work in progress,  Providing enhanced VPN service is the motivation of this draft, while as commented by chairs and agreed by coauthors, we have been working to make this document focusing on the enhancement to SR.

The comments from SPRING chair has been resolved in recent updates of the draft. In current version enhanced VPN is just mentioned as one service of the SR virtual network.

[Jie] Hope my above replies help to solve your comments. And as this document is just in WG adoption, it could be polished further after the adoption.

Best regards,

Jie

Thanks,

Ketan

Dear WG:

Thanks!

Jim, Joel & Bruno

---

From: Huaimo Chen <[email-masked]>
Date: Sat, 25 Jul 2020 14:31:15 +0000

Support.

Best Regards,
Huaimo
________________________________
From: spring <[email-masked]> on behalf of James Guichard <[email-masked]>
Sent: Wednesday, July 15, 2020 7:16 AM
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:

Thanks!

Jim, Joel & Bruno

---

From: Dhruv Dhody <[email-masked]>
Date: Sat, 25 Jul 2020 22:57:56 +0530

Hi WG,

I support adoption on this work, it is in good shape to be adopted to
be in the working group control. Hope the authors/WG find these
comments useful -

(1) I would like to see this work provide more guidance for the
protocol extensions  -
- Virtual network identifiers and its scope
- Identifiers for resource partition
- Virtual network creation/deletion/modify (also recompute because of
network or resource changes)
- manageability consideration wrt to configuring resource-aware
SIDs/virtual networks

(2) Can I have a mix of resource-aware SIDs and normal SIDs in an SR
Path? Worth expanding on this.

(3) Worth expanding on the dynamic allocation of SIDs by network nodes
in section 3.

(4) SR Policy should also need to be Virtual-network-aware and how
steering happens to a VN-aware SR policy could be clarified.

Thanks!
Dhruv

---

From: Tarek Saad <[email-masked]>
Date: Sat, 25 Jul 2020 18:57:08 +0000

Hi WG,

This document is touching important topics regarding forwarding on specific set of resources in the network (such as those that define a network slice).
For this, it’s important to be able to identify transiting traffic as belonging to a specific slice so as to impose the specific behavior upon forwarding the traffic on the associated resources.

This draft is proposing to allocate/assign different labels/SIDs (per topological element – either node or link) to identify the specific resource per slice and the respective forwarding behavior.
This may work for smaller networks (and for limited number of slices), but there are concerns that it would run into scale problems (related to # of required labels to allocate and amount of IGP state required for the different SIDs) - as number of topological elements in the network grows and number of vertical/ horizontal slices grows.

It might be useful to define a mechanism by which specific allocated resources for a given link or node are to be identified and not describe how virtual network topologies are to be constructed. This is because the topologies are not necessarily virtual and because there are a multiplicity of uses for this mechanism beyond constructing subsets of the underlay network topology.

We believe encoding the slice identifier separate from the forwarding instruction can yield better scale and still allow for steering on the specific resource. We intend to publish something along those lines in the coming next couple of weeks to gather more feedback.

Regards,
Tarek

From: spring <[email-masked]> on behalf of James Guichard <[email-masked]>
Date: Wednesday, July 15, 2020 at 7: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

Dear WG:

Thanks!

Jim, Joel & Bruno

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Sun, 26 Jul 2020 02:05:28 +0000

Hi Dhruv, 

Thanks for your support and comments. Please see some replies inline:

> From: spring [mailto:[email-masked]] On Behalf Of Dhruv Dhody
> Sent: Sunday, July 26, 2020 1:28 AM
> To: James Guichard <[email-masked]>
> Cc: [email-masked]; [email-masked]
> I support adoption on this work, it is in good shape to be adopted to be in the
> working group control. Hope the authors/WG find these comments useful -
> 
> (1) I would like to see this work provide more guidance for the protocol
> extensions  -
> - manageability consideration wrt to configuring resource-aware SIDs/virtual
> networks

Agree that some more information about the above could be provided in the document, and some may be specified in the corresponding control plane drafts. 

> 
> (2) Can I have a mix of resource-aware SIDs and normal SIDs in an SR Path?
> Worth expanding on this.

Yes it is possible to have them mixed in SR path, the usage is up to the requirement and policy. 

> 
> (3) Worth expanding on the dynamic allocation of SIDs by network nodes in
> section 3.

OK.

> 
> (4) SR Policy should also need to be Virtual-network-aware and how steering
> happens to a VN-aware SR policy could be clarified.

Yes, SR policy with virtual network constraints is mentioned in 4.3, further clarification could be added. 

Best regards,
Jie

> WG. Please also provide comments/reasons for that support (or lack thereof).

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Sun, 26 Jul 2020 02:35:18 +0000

Hi Tarek,

Thanks for your comment, please see some replies inline:

From: spring [mailto:[email-masked]] On Behalf Of Tarek Saad
Sent: Sunday, July 26, 2020 2:57 AM
To: James Guichard <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Hi WG,

This document is touching important topics regarding forwarding on specific set of resources in the network (such as those that define a network slice).
For this, it's important to be able to identify transiting traffic as belonging to a specific slice so as to impose the specific behavior upon forwarding the traffic on the associated resources.

This draft is proposing to allocate/assign different labels/SIDs (per topological element - either node or link) to identify the specific resource per slice and the respective forwarding behavior.
This may work for smaller networks (and for limited number of slices), but there are concerns that it would run into scale problems (related to # of required labels to allocate and amount of IGP state required for the different SIDs) - as number of topological elements in the network grows and number of vertical/ horizontal slices grows.

[Jie] Glad to know that you also think this is an important topic and can be useful for cases such as network slicing (while its applicability is general). This document describes the SR based mechanism for this. As mentioned in section 2 of this document, it requires additional SIDs and SRv6 Locators to be allocated, thus its applicability is for scenarios with limited number of virtual networks. The amount of IGP state is discussed in the relevant control plane drafts in LSR WG.

[Jie] The scalability topic is further described in draft-dong-teas-enhanced-vpn-vtn-scalability in TEAS WG, which also provides some guidance for optimization, your review and comment to it are welcome. Thanks.

Best regards,
Jie

Regards,
Tarek

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

Dear WG:

Thanks!

Jim, Joel & Bruno

---

From: "Weiqiang Cheng" <[email-masked]>
Date: Mon, 27 Jul 2020 13:56:26 +0800

It provides a generic and useful enhancement to SR, and the document is in
good shape. 

B.R.

Weiqiang Cheng

Dear WG:

Thanks!

Jim, Joel & Bruno

---

From: "Luis M. Contreras" <[email-masked]>
Date: Mon, 27 Jul 2020 12:49:18 +0200

Hi all,

Yes, I support the adoption. The document is in a good shape. I would
suggest however to include some hints about the kind of resources
considered so far (by now there is an example considering bandwidth; I
guess other kind of resources could represent further complexity).

Thanks

Luis

-- 
___________________________________________
Luis M. Contreras
[email-masked]
[email-masked]
Global CTIO unit / Telefonica

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 27 Jul 2020 12:22:56 +0100

Hi Jim,

I've been working on the Enhanced VPN framework in TEAS and I consider it a
good foundation for providing a more sophisticated VPN service that also
addresses the needs of network slicing.

So I'm pleased to see this work being examined in SPRING. It's been a while
since I read this draft, but I considered it then to be a good starting
point. I support adoption and commit to reviewing and contributing to the
document within the working group.

Thanks,

Adrian

Sent: 15 July 2020 12:17

Dear WG:

Thanks!

Jim, Joel & Bruno

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 27 Jul 2020 12:28:02 +0100

As an author I think this is a useful text to publish in support of this work that continues in TEAS.

I hope that the WG is able to accept it as a SPRING WG draft.

Stewart

> On 15 Jul 2020, at 12:16, James Guichard <[email-masked]> wrote:
> 
> Dear WG:
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/spring <https://www.ietf.org/mailman/listinfo/spring>

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 28 Jul 2020 11:47:23 +0800

Dear WG:

I support the adoption. The mechanism in this document could be helpful to deploy services with guaranteed SLA in SR network.

Best regards,
Chenhao 
 
From: James Guichard
Date: 2020-07-15 19:16
To: [email-masked]

 
Thanks!
 
Jim, Joel & Bruno

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 28 Jul 2020 12:15:29 +0800

Hi WG,

I support the adoption. It is a useful enhancement to SR, which can help to provide network SLA assurance for various services.

Best regards,

Cong Li

From: James Guichard
Date: 2020-07-15 19:16
To: [email-masked]

 
Thanks!
 
Jim, Joel & Bruno

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 28 Jul 2020 08:47:46 -0700

Dear Authors,
thank you for that well-written document. It was a pleasure to read. I have
a number of questions and much appreciate it if you can clarify them for me:

   - how you envision mapping resources to a topological SID, e.g. adj-SID?
   Would it be 1:1, i.e., a new SID for each resource that characterizes a
   link in a virtual network?
   - how granular association of a resource with a SID could practically
   be? For example, BW may be de-composed into, per. RFC 6003, CIR, CBS, EIR,
   and EBS. Do you expect a transient SR node to do policing and/or shaping
   according to such resource information?
   - I agree, that FlexE is one of Layer 2 technologies to provide
   predictable, in regard to performance, transport. What benefits of using
   resource information you see for FlexE? Would an intermediate node manage
   the FlexE calendar?

Regards,
Greg

---

From: Shunsuke Homma <[email-masked]>
Date: Wed, 29 Jul 2020 01:06:05 +0900

Hi WG,

I reviewed the draft, and support the adoption. The proposal may be a
useful improvement of SR architecture, and it will be valuable to consider
it.

The follows are my comments:
- Regarding scalability, it will depend on how to design configurations,
and I think that there is little difference between existing technologies
and the proposal.  The number of virtual networks which can be built will
strongly depend on the spec/ability of the underlay network.  For example,
the number of available QoS classes is limited by the number of queues
which routers have. Or the size of a forwarding table depends on
performance of TCAM. I think a critical point on scalability is underlay
network spec/ability rather than the nature of techniques/protocols.
- Simplifying data plane structure and its management by unifying several
forwarding mechanisms to SID may be one of advantages of the proposal.
- This extension may be a fundamental improvement, and it may not be
necessary to be tied to usage for enhanced VPN solution.

Regards,

Shunsuke

On Wed, Jul 29, 2020 at 12:48 AM Greg Mirsky <[email-masked]> wrote:

> Dear Authors,
> thank you for that well-written document. It was a pleasure to read. I
> have a number of questions and much appreciate it if you can clarify them
> for me:
>
>    - how you envision mapping resources to a topological SID, e.g.
>    adj-SID? Would it be 1:1, i..e., a new SID for each resource that
>    characterizes a link in a virtual network?

---

From: Loa Andersson <[email-masked]>
Date: Wed, 29 Jul 2020 18:05:00 +0800

Working Grpup,

I reviewed the draft and find it a very good start for a working group
topic that is well inside the scope of what the working group needs to
be working on.

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 29 Jul 2020 05:57:57 -0700

Dear WG Chairs, Authors,
I think I need to clarify my view regarding the WG adoption of this draft.
I share concerns expressed by Tarek. Also, it is not clear the role of
resource-SID in the case of FlexE underlay. And it does appear that an SR
node will maintain state per resource-SID it is provisioned by the
controller. That, in my opinion, breaks the SR paradigm of no per-flow
state at intermediate SR nodes. I believe that any solution to the problem
of SR-TE should be weighted against the work on Transport Slicing at the
TEAS WG.

Regards,
Greg

On Tue, Jul 28, 2020 at 8:47 AM Greg Mirsky <[email-masked]> wrote:

>    adj-SID? Would it be 1:1, i.e., a new SID for each resource that