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

[Luis M. Contreras]

Hi all,

acknowledging the scalability concerns discussed on the list, I think there
could be some scenarios that could be yet benefited from this approach. So
I'm in favor of supporting the adoption of the document.

Best regards

Luis


El mié, 27 ene 2021 a las 12:47, James Guichard (<
james.n.guich...@futurewei.com>) escribió:

> 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
>
>
>
>
>
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>


-- 
___
Luis M. Contreras
contreras.i...@gmail.com
luismiguel.contrerasmuri...@telefonica.com
Global CTIO unit / Telefonica
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Chengli (Cheng Li)]

Hi SPRING,

I have read the document and think it is mature and ready to be adopted.

This document describes how to implement SR-based VTN using resource-aware 
SIDs, which is very helpful for people to understand.

I would like to work on it as well!  :)

Thanks to the authors!
Cheng




From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Wednesday, January 27, 2021 7:47 PM
To: spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

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



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

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

[Dongjie (Jimmy)]

Hi Shunsuke,

Thanks a lot for your review and comments. Please see some replies inline:

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Shunsuke Homma
Sent: Tuesday, February 9, 2021 12:05 AM
To: James Guichard 
Cc: spring@ietf.org; spring-cha...@ietf.org
Subject: Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Hi WG,

I think that this document is good enough as starting point for the WG, and I 
support the adoption. There are many drafts related to network slice with SR 
(e.g., SR + Flex-algo, draft-bestbar-spring-scalable-ns, etc.) and I hope it 
will be clarified which is the best in future work.

[Jie] Thanks for your support.

The following are my comments to the draft.
- The example describes three isolated VTNs. I assume (hard) isolation will 
cause split loss, and oversubscription will be sometimes needed. Hence, it may 
be better to allow a resource-aware SID to belong to multiple VTNs.

[Jie] In the context of SR based VTN, each resource-aware SID is associated 
with one VTN. Multiple services which are mapped to the same VTN can use the 
same group of SIDs to guide the packet forwarding, thus  a resource-aware SID 
and the associated resources can be shared by multiple services.

- From network slicing (i.e., NaaS model) perspective, I assume visibility will 
be especially important. As one more important requirement, network operators 
want to provide only information of the VTN whose customer uses to that 
customer. For example, if a customer gets VTN information with BGP-LS, some 
mechanisms to prevent to leak other VTNs information in BGP-LS would be needed.

[Jie] Yes, depends on the operator’s policy, the amount and the granularity of 
information exposed to a customer should be controlled. The considerations 
about this is described in section 3.5 VTN Visibility to Customer. The required 
control plane mechanism can be based on  BGP-LS mechanism in RFC7752 (and the 
in progress draft-7752bis), some extension may be introduced if needed.

- There is a typo in figure2. The adj-SID of the link from 203 to 204 in green 
VTN should be 2002.

[Jie] Thanks for catching the typo. We will fix it in next revision.

Best regards,
Jie

Regards,

Shunsuke

On Wed, Jan 27, 2021 at 8:47 PM James Guichard 
mailto:james.n.guich...@futurewei.com>> wrote:
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



___
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Yingzhen Qu]

Hi,

I support the WG adoption of this draft, and I believe it’s a good starting 
point for the WG to work on this topic, and see how existing technologies can 
be integrated to provide new capabilities.

Resource reservation has always been a controversial topic, whether it is 
needed, or efficient, or can it scale? Can we just deliver low latency service 
with high bandwidth? All these are valid questions, as a WG we can continue to 
improve the solutions and make the deployments easier. As Adrian said the 
market will decide whether this is the right technology or the right timing. 

So I support the adoption of this draft and I’m willing to work on it.

Thanks,
Yingzhen


>  
>  
> From: spring  On Behalf Of James Guichard
> Sent: Wednesday, January 27, 2021 5:47 AM
> To: spring@ietf.org
> Cc: spring-cha...@ietf.org
> Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn
>  
> Dear WG:
>  
> This message starts 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 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
>  
>  
>  
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring

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

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

[chen.ran]

Hi WG,



 


What are the advantages of this draft compared with other drafts? (such as 
draft-bestbar-spring-scalable-ns, draft-peng-lsr-network-slicing),and is it 
just explain the concept of virtual SR network beyond the concept of 
resource-aware SID? 


Many people are thinking about how to realize slicing in the network and made 
many contributions. Although I am originally a co-author of draft 
draft-peng-lsr-network-slicing, I think so far 
draft-bestbar-spring-scalable-ns, comparatively speaking, is to grasp the 
essence of the problem, and have a complete thoughts.






So, I do not think draft-dong-spring-sr-for-enhanced-vpn is now ready to become 
a working group draft.






Best Regards,


Ran







原始邮件



发件人：JamesGuichard
收件人：spring@ietf.org;
抄送人：spring-cha...@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___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Shunsuke Homma]

Hi WG,

I think that this document is good enough as starting point for the WG, and
I support the adoption. There are many drafts related to network slice with
SR (e.g., SR + Flex-algo, draft-bestbar-spring-scalable-ns, etc.) and I
hope it will be clarified which is the best in future work.

The following are my comments to the draft.
- The example describes three isolated VTNs. I assume (hard) isolation will
cause split loss, and oversubscription will be sometimes needed. Hence, it
may be better to allow a resource-aware SID to belong to multiple VTNs.

- From network slicing (i.e., NaaS model) perspective, I assume visibility
will be especially important. As one more important requirement, network
operators want to provide only information of the VTN whose customer uses
to that customer. For example, if a customer gets VTN information with
BGP-LS, some mechanisms to prevent to leak other VTNs information in BGP-LS
would be needed.

- There is a typo in figure2. The adj-SID of the link from 203 to 204 in
green VTN should be 2002.

Regards,

Shunsuke

On Wed, Jan 27, 2021 at 8:47 PM James Guichard <
james.n.guich...@futurewei.com> wrote:

> 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
>
>
>
>
>
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Tarek Saad]

I agree with Shaofu. A slice aggregate is independent of the forwarding plane 
(i.e. it is not a virtual network). A single flex-algo (that defines a 
forwarding plane) can be sliced into multiple slice-aggregates. If per slice 
SIDs are used, it allows IGP to share the forwarding next-hops for each of 
those slice SIDs (i.e., makes determining SID next-hop independent of # of 
slice-aggregates). This was described in detail in 
draft-bestbar-spring-scalable-ns. It’s good to see 
draft-dong-spring-sr-for-enhanced-vpn has incorporated this change from 
draft-bestbar-spring-scalable-ns in its latest rev.

Regards,
Tarek


On 2/6/21, 10:53 PM, "spring on behalf of 
peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>" 
mailto:spring-boun...@ietf.org> on behalf of 
peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>> wrote:




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.



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.



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



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-cha...@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







Juniper Business Use Only
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Tianran Zhou]

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


Could you please explain the technical point why this document can’t be adopted?

IMO, all your statements just show support and consensus on the technology.

Tianran




Sent from WeLink
发件人： peng.shaofumailto:peng.sha...@zte.com.cn>>
收件人： 
james.n.guichardmailto:james.n.guich...@futurewei.com>>
抄送： 
springmailto:spring@ietf.org>>;spring-chairsmailto:spring-cha...@ietf.org>>
主题： Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn
时间： 2021-02-07 11:53:59



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.


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.


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


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-cha...@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




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

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

[Adrian Farrel]

I think that, before jumping in to criticise 
draft-dong-spring-sr-for-enhanced-vpn too much for the *potential* for state 
explosion, everyone should read draft-ietf-teas-enhanced-vpn and 
draft-dong-teas-enhanced-vpn-vtn-scalability with some care (as Pavan appears 
to have done :-) to see the difference between a slice and a slice. The VTN 
construct is a virtual network topology with associated resources (a macro 
slice, if you like) that can support multiple network slices or enhanced VPNs 
that are subject to the same class of treatment (micro slices, perhaps). The 
number of VTNs need not be large although, my understanding is that the authors 
do not prevent operators from deciding to shoot themselves.

One could, if so minded, call the VTN a "slice aggregate".

Cheers,
Adrian

-Original Message-
From: spring  On Behalf Of Joel M. Halpern
Sent: 02 February 2021 19:54
To: Colby Barth ; spring@ietf.org
Subject: Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Colby, you are, as far as I can tell, correct that the potential for 
state explosion is extremely risky and requires careful management. 
That is why the bestbar draft emphasis that the state is abotu slice 
aggregates, not end-to-end slices, and probably not even individual IETF 
network slices.

Yours,
Joel

On 2/2/2021 2:19 PM, Colby Barth wrote:
> Tarek, indeed …
> 
> draft-bestbar-spring-scalable-ns-00 provides a relevant example of the rather 
> enormous amount of state the solution described in 
> draft-dong-spring-sr-for-enhanced-vpn results in:
> 
> "Notably, this approach requires maintaining per slice state for each
> topological element on every router in the network in both the
> control and data plane.  For example, a network composed of 'N'
> nodes, where each node has up to 'K' adjacencies to its neighbors, a
> node would have to assign and advertise 'M' Slice Prefix-SIDs and 'M'
> Slice Adjacency-SID(s) to each of it 'K' adjacencies.  Consequently,
> a router will have to maintain up to (N+K)*M SIDs in the control
> plane, and an equal number of label routes in its forwarding plane."
> 
> 
> Put in practical terms, this implicitly limits the number of VTNs or, in 
> draft-bestbar-teas-ns-packet-01 terminology, the number of Slice aggregates 
> that can be offered.  It also introduces a dependency between the network 
> size and the number of VTNs.  i.e. the larger the network, the smaller the 
> number of VTNs that can be supported.
> 
> —Colby
> 
>> On Feb 2, 2021, at 12:54 PM, Tarek Saad  
>> wrote:
>>
>> Hi Eduard,
>>   
>> Inline..
>>   
>> On 2/2/21, 10:50 AM, "spring on behalf of Vasilenko Eduard" 
>>  wrote:
>>   
>> Hi all,
>> There is the general trend to encode the action into the packet, not to 
>> distribute states in the control plane for all possible traffic types. 
>> Granularity, programmability are better.
>>   
>> [TS]: Indeed, we are in agreement on encoding the information in packet as 
>> opposed to distributing states in the control plane. In 
>> draft-bestbar-spring-scalable-ns, a separate ID inside the packet is 
>> proposed to carry the needed information. However, this draft 
>>  is proposing distributing per VTN 
>> state in the network which is completely against your argument ...
>>   
>> Regards,
>> Tarek
>>   
>>   
>>   
>> This type of virtualization is fully in-line with this trend.
>> Support.
>> Eduard
>> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
>> Sent: Wednesday, January 27, 2021 12:47 PM
>> To: spring@ietf.org
>> Cc: spring-cha...@ietf.org
>> Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn
>>   
>> 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
>>   
>>   
>>   
>>
>> Juniper Business Use Only
>>
>> ___
>> spring mailing list
>> spring@ietf.org
>> https://www.ietf.org/mailman/listinfo/spring
> 

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

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

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

[peng.shaofu]

Hi Jie,






Thanks for you reply. 


Please see in-line [PSF]






Regards,


PSF






 

 




From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
peng.sha...@zte.com.cn
 Sent: Sunday, February 7, 2021 11:53 AM
 To: james.n.guich...@futurewei.com
 Cc: spring@ietf.org; spring-cha...@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-s

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

[Dongjie (Jimmy)]

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
peng.sha...@zte.com.cn
Sent: Sunday, February 7, 2021 11:53 AM
To: james.n.guich...@futurewei.com
Cc: spring@ietf.org; spring-cha...@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.



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.



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.



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<mailto:spring@ietf.org>;
抄送人：spring-cha...@ietf.org<mailto:spring-cha...@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<mailto: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





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

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

[peng.shaofu]

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. 




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.




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




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-cha...@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___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Ahmed MostafaSaleh ElSawaf]

Hello
I am Supporting  the adoption of this document. The mechanism provided in this 
document can help us to build customized virtual networks for different types 
of services with diverse performance requirements.


From: spring  On Behalf Of James Guichard
Sent: Wednesday, January 27, 2021 2:47 PM
To: spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

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




The information in this email may contain confidential material and it is 
intended solely for the addresses. Access to this  email by anyone else is 
unauthorized. If you are not the intended recipient, please delete the email 
and destroy any copies of it, any disclosure, copying, distribution is 
prohibited and may be considered unlawful. Contents of this email and any 
attachments may be altered, Statement and opinions expressed in this email are 
those of the sender, and do not necessarily  reflect those of Saudi 
Telecommunications Company (STC).
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Vishnu Pavan Beeram]

WG, Hi!

 advocates a couple of options for
determining which slice-aggregate the packet belongs to:
(a) Segment Range as Slice Selector
(b) Global Identifier as Slice Selector
In option (a), which is what is relevant
for draft-dong-spring-sr-for-enhanced-vpn, the following is advocated:

   ".. multiple per slice aggregate 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 slice aggregates.."

I have reviewed the latest version (rev 13) of
draft-dong-spring-sr-for-enhanced-vpn and it is good to see the above point
incorporated in section 2.3. Thanks to the authors for embracing this
important aspect – it does significantly enhance the scaling story for the
proposed solution.

Regards,
-Pavan

On Wed, Jan 27, 2021 at 5:46 AM James Guichard <
james.n.guich...@futurewei.com> wrote:

> 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
>
>
>
>
>
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Francois Clad (fclad)]

Hi chairs, WG,

Support as a co-author.

Thanks,
Francois

From: spring  on behalf of James Guichard 

Date: Wednesday, 27 January 2021 at 12:47
To: spring@ietf.org 
Cc: spring-cha...@ietf.org 
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn
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



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

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

[Loa Andersson]

Working Group,

I have reviewed the draft and believe that it is a good starting point 
for the wg to create the Enhanced VPN standard.


/Loa

On 27/01/2021 19:46, James Guichard wrote:

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 10^th 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


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



--

Loa Anderssonemail: l...@pi.nu
Senior MPLS Expert  loa.pi...@gmail.com
Bronze Dragon Consulting phone: +46 739 81 21 64

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

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

[Huaimo Chen]

Hi Everyone,

I support for its WG adoption. It uses resource aware SIDs to provide 
different SR based Virtual Transport Networks for different service 
requirements from customers. In addition, One VTN may be separated from the 
others. This is useful.
I have a couple of comments. In Section 2.2, "VTN.s" in the first sentence 
should be "VTNs.".  In section 3.2, it seems better also to add stateful PCE as 
a reference.

Best Regards,
Huaimo

From: spring  on behalf of James Guichard 

Sent: Wednesday, January 27, 2021 6:46 AM
To: spring@ietf.org 
Cc: spring-cha...@ietf.org 
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn


Dear WG:



This message starts 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=04%7C01%7Chuaimo.chen%40futurewei.com%7C279f0709bae94787fa4f08d8c2b93a2c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637473448126500112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0=L2XVwYEN3hJfTxqqI1ZH%2BhKWdL8nxhHSc3JSLCWjWyU%3D=0>
 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






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

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

[Linda Dunbar]

Dear WG,

I support the WG adoption of the draft.
It is true that the enhanced-vpn mechanism requires additional processing.
For some special environment, such as the 5G  Edge Computing servers within  N6 
network, some operators may be willing to add the additional processing (in the 
confined network) to achieve the desired QoS for the premium services.
In addition, with zero rating (or zero rating +) applications increase, the 
future may call for  more premium VPN+ services.

Linda Dunbar


From: spring  On Behalf Of James Guichard
Sent: Wednesday, January 27, 2021 5:47 AM
To: spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

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



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

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

[联通北京市北京市分公司]

Hi, WG:

I support the adoption. Using of resource-aware SIDs to build SR based VTNs is 
very helpful in building our 5G SA transport network.

Regards,

ZhuangZhuang Qin


发件人: James Guichard 
日期: 2021年1月27日 星期三 下午7:46
收件人: "spring@ietf.org" 
抄送: "spring-cha...@ietf.org" 
主题: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

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



如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 
hqs-s...@chinaunicom.cn，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received 
this email in error please notify us immediately by e-mail. Please reply to 
hqs-s...@chinaunicom.cn ,you can unsubscribe from this mail. We will 
immediately remove your information from send catalogue of our.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[chenhu...@chinatelecom.cn]

I support the adoption of this document. 
The capability of providing different services with customized virtual networks 
and resources is important for a multi-service network operator.



HUANAN CHEN（陈华南）
Data Communication Research Department
Research Institute of China Telecom Co.,Ltd.

From: James Guichard
Date: 2021-01-27 19:46
To: spring@ietf.org
CC: spring-cha...@ietf.org
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn
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
 
 
 
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Joel M. Halpern]

Colby, you are, as far as I can tell, correct that the potential for 
state explosion is extremely risky and requires careful management. 
That is why the bestbar draft emphasis that the state is abotu slice 
aggregates, not end-to-end slices, and probably not even individual IETF 
network slices.


Yours,
Joel

On 2/2/2021 2:19 PM, Colby Barth wrote:

Tarek, indeed …

draft-bestbar-spring-scalable-ns-00 provides a relevant example of the rather 
enormous amount of state the solution described in 
draft-dong-spring-sr-for-enhanced-vpn results in:

"Notably, this approach requires maintaining per slice state for each
topological element on every router in the network in both the
control and data plane.  For example, a network composed of 'N'
nodes, where each node has up to 'K' adjacencies to its neighbors, a
node would have to assign and advertise 'M' Slice Prefix-SIDs and 'M'
Slice Adjacency-SID(s) to each of it 'K' adjacencies.  Consequently,
a router will have to maintain up to (N+K)*M SIDs in the control
plane, and an equal number of label routes in its forwarding plane."


Put in practical terms, this implicitly limits the number of VTNs or, in 
draft-bestbar-teas-ns-packet-01 terminology, the number of Slice aggregates 
that can be offered.  It also introduces a dependency between the network size 
and the number of VTNs.  i.e. the larger the network, the smaller the number of 
VTNs that can be supported.

—Colby


On Feb 2, 2021, at 12:54 PM, Tarek Saad  
wrote:

Hi Eduard,
  
Inline..
  
On 2/2/21, 10:50 AM, "spring on behalf of Vasilenko Eduard"  wrote:
  
Hi all,

There is the general trend to encode the action into the packet, not to 
distribute states in the control plane for all possible traffic types. 
Granularity, programmability are better.
  
[TS]: Indeed, we are in agreement on encoding the information in packet as opposed to distributing states in the control plane. In draft-bestbar-spring-scalable-ns, a separate ID inside the packet is proposed to carry the needed information. However, this draft  is proposing distributing per VTN state in the network which is completely against your argument ...
  
Regards,

Tarek
  
  
  
This type of virtualization is fully in-line with this trend.

Support.
Eduard
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Wednesday, January 27, 2021 12:47 PM
To: spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn
  
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
  
  
  


Juniper Business Use Only

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




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

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

[Colby Barth]

Tarek, indeed …

draft-bestbar-spring-scalable-ns-00 provides a relevant example of the rather 
enormous amount of state the solution described in 
draft-dong-spring-sr-for-enhanced-vpn results in:

   "Notably, this approach requires maintaining per slice state for each
   topological element on every router in the network in both the
   control and data plane.  For example, a network composed of 'N'
   nodes, where each node has up to 'K' adjacencies to its neighbors, a
   node would have to assign and advertise 'M' Slice Prefix-SIDs and 'M'
   Slice Adjacency-SID(s) to each of it 'K' adjacencies.  Consequently,
   a router will have to maintain up to (N+K)*M SIDs in the control
   plane, and an equal number of label routes in its forwarding plane."


Put in practical terms, this implicitly limits the number of VTNs or, in 
draft-bestbar-teas-ns-packet-01 terminology, the number of Slice aggregates 
that can be offered.  It also introduces a dependency between the network size 
and the number of VTNs.  i.e. the larger the network, the smaller the number of 
VTNs that can be supported.

—Colby

> On Feb 2, 2021, at 12:54 PM, Tarek Saad  
> wrote:
> 
> Hi Eduard,
>  
> Inline..
>  
> On 2/2/21, 10:50 AM, "spring on behalf of Vasilenko Eduard" 
>  wrote:
>  
> Hi all,
> There is the general trend to encode the action into the packet, not to 
> distribute states in the control plane for all possible traffic types. 
> Granularity, programmability are better.
>  
> [TS]: Indeed, we are in agreement on encoding the information in packet as 
> opposed to distributing states in the control plane. In 
> draft-bestbar-spring-scalable-ns, a separate ID inside the packet is proposed 
> to carry the needed information. However, this draft 
>  is proposing distributing per VTN 
> state in the network which is completely against your argument ...
>  
> Regards,
> Tarek
>  
>  
>  
> This type of virtualization is fully in-line with this trend.
> Support.
> Eduard
> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
> Sent: Wednesday, January 27, 2021 12:47 PM
> To: spring@ietf.org
> Cc: spring-cha...@ietf.org
> Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn
>  
> 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
>  
>  
>  
> 
> Juniper Business Use Only
> 
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring

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

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

[Tarek Saad]

Hi Eduard,

Inline..

On 2/2/21, 10:50 AM, "spring on behalf of Vasilenko Eduard" 
mailto:spring-boun...@ietf.org> on behalf of 
vasilenko.edu...@huawei.com<mailto:vasilenko.edu...@huawei.com>> wrote:

Hi all,
There is the general trend to encode the action into the packet, not to 
distribute states in the control plane for all possible traffic types. 
Granularity, programmability are better.

[TS]: Indeed, we are in agreement on encoding the information in packet as 
opposed to distributing states in the control plane. In 
draft-bestbar-spring-scalable-ns, a separate ID inside the packet is proposed 
to carry the needed information. However, this draft 
 is proposing distributing per VTN state 
in the network which is completely against your argument ...

Regards,
Tarek



This type of virtualization is fully in-line with this trend.
Support.
Eduard
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Wednesday, January 27, 2021 12:47 PM
To: spring@ietf.org<mailto:spring@ietf.org>
Cc: spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

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





Juniper Business Use Only
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[stefano previdi]

Hi,

I support the WG adoption of this draft.

Thanks.

s.


> On Jan 27, 2021, at 12:46 PM, James Guichard  
> wrote:
> 
> 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 10th2021.
>  
> 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
>  
>  
>  
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring

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

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

[Vasilenko Eduard]

Hi all,
There is the general trend to encode the action into the packet, not to 
distribute states in the control plane for all possible traffic types. 
Granularity, programmability are better.
This type of virtualization is fully in-line with this trend.
Support.
Eduard
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Wednesday, January 27, 2021 12:47 PM
To: spring@ietf.org<mailto:spring@ietf.org>
Cc: spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

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



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

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

[Tarek Saad]

,
R.


> On Sun, Jan 31, 2021 at 1:06 PM Adrian Farrel 
> mailto:adr...@olddog.co.uk>> wrote:
Yeah, thanks Robert.

Actually, removing the comparison with other protocols is probably wise. This 
is a document describing how to do stuff with SR. In that context we don’t need 
to talk about the benefits or limitations of other protocols.

To your 3209 comments: I believe that *some* implementations have pushed the 
“reservation” into the data plane so that in-network policing is performed to 
conform data flows with reservations or, at least, ensure that the parts of any 
flow that exceed reservation are treated as best effort. But this is an aside 
to the discussion of the draft at hand.

I think that the document should note that the SR control plane does not 
currently have the capability to make reservations (in the control plane) at 
the network nodes. This can be achieved using a central controller to keep tabs 
on all resource accounting, and it could use a southbound interface to install 
that information in the (management/control parts of the) network nodes.

Cheers,
Adrian

From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: 31 January 2021 00:46
To: Adrian Farrel mailto:adr...@olddog.co.uk>>
Cc: James Guichard 
mailto:james.n.guich...@futurewei.com>>; SPRING 
WG mailto:spring@ietf.org>>; 
spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>
Subject: Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Hi Adrian,

Just to make sure my point was correctly understood ... I am not questioning if 
either data plane or control plane resource reservations should or should not 
be done for SR.

What I am questioning is that the draft says:

   When
   compared with RSVP-TE [RFC3209], SR currently does not have the
   capability to reserve network resources or identify different sets of
   network resources reserved for different customers and/or services.

The crux of the matter is that RFC3209 DOES NOT reserve anything in the data 
plane of any network element while this spec clearly intends to. RSVP-TE keeps 
all reservations in control plane counters only. Constrained based path 
computation/selection happens based on those control plane information. (Yes 
nearly 20 years after this feature shipped I am still meeting people who 
believe otherwise :).

So to start I recommend we remove any reference to RSVP-TE as this is purely 
not applicable to what this document is trying to accomplish.

I admit I did not follow all the recent advancements in TEAS nor in DETNET as 
far as actually reserving data plane resources in data plane for some traffic 
types. If authors want to build a solution with that - by all means green light 
and full speed ahead - market will decided - especially when it will really 
understand the cost :) But let's make sure the document is crystal clear on 
what building blocks it is talking about.

Best,
R.


On Sat, Jan 30, 2021 at 11:20 PM Adrian Farrel 
mailto:adr...@olddog.co.uk>> wrote:
Thanks, Jim,

I’ve been following the enhanced VPN work in TEAS and I see it as a key piece 
of the network slicing work.

It’s time that we had some protocol solutions that serve the VPN framework, and 
this is a suitable starting point. I like that it is not specifying additional 
protocol widgets but has looked at what we already have and is pointing up ways 
to use those tools to deliver new function.

I see Robert’s point about the resource reservation aspects of traffic 
engineering applied to an SR network, but this is not an insurmountable 
problem. The question might be asked, “Why would you want to do that?” but that 
is a question that (as Yakov would have said) the market can decide. It seems 
that there are a couple of vendors and a couple of operators who have an 
interest.

So I think we should adopt this draft and see whether we can turn it into 
something that has great utility.

Cheers,
Adrian

From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of James Guichard
Sent: 27 January 2021 11:47
To: spring@ietf.org<mailto:spring@ietf.org>
Cc: spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

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



___
spring

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

[Giuseppe Fioccola]

Hi All,
I have read it and support WG adoption for this draft that provides a mechanism 
based on resource-aware SIDs in order to build SR based VTNs for Enhanced VPN.

Regards,

Giuseppe

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Wednesday, January 27, 2021 12:47 PM
To: spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

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



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

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

[Robert Raszuk]

data plane resources which explicitly Jie explained as the
> intention here.
>
>
>
> Best,
> R.
>
>
>
>
>
> > On Sun, Jan 31, 2021 at 1:06 PM Adrian Farrel 
> wrote:
>
> Yeah, thanks Robert.
>
>
>
> Actually, removing the comparison with other protocols is probably wise.
> This is a document describing how to do stuff with SR. In that context we
> don’t need to talk about the benefits or limitations of other protocols.
>
>
>
> To your 3209 comments: I believe that **some** implementations have
> pushed the “reservation” into the data plane so that in-network policing is
> performed to conform data flows with reservations or, at least, ensure that
> the parts of any flow that exceed reservation are treated as best effort.
> But this is an aside to the discussion of the draft at hand.
>
>
>
> I think that the document should note that the SR control plane does not
> currently have the capability to make reservations (in the control plane)
> at the network nodes. This can be achieved using a central controller to
> keep tabs on all resource accounting, and it could use a southbound
> interface to install that information in the (management/control parts of
> the) network nodes.
>
>
>
> Cheers,
>
> Adrian
>
>
>
> *From:* Robert Raszuk 
> *Sent:* 31 January 2021 00:46
> *To:* Adrian Farrel 
> *Cc:* James Guichard ; SPRING WG <
> spring@ietf.org>; spring-cha...@ietf.org
> *Subject:* Re: [spring] WG Adoption Call for
> draft-dong-spring-sr-for-enhanced-vpn
>
>
>
> Hi Adrian,
>
>
>
> Just to make sure my point was correctly understood ... I am not
> questioning if either data plane or control plane resource reservations
> should or should not be done for SR.
>
>
>
> What I am questioning is that the draft says:
>
>
>
>When
>compared with RSVP-TE [RFC3209], SR currently does not have the
>capability to reserve network resources or identify different sets of
>network resources reserved for different customers and/or services.
>
>
>
> The crux of the matter is that RFC3209 DOES NOT reserve anything in the
> data plane of any network element while this spec clearly intends to.
> RSVP-TE keeps all reservations in control plane counters only.
> Constrained based path computation/selection happens based on those
> control plane information. (Yes nearly 20 years after this feature shipped
> I am still meeting people who believe otherwise :).
>
>
>
> So to start I recommend we remove any reference to RSVP-TE as this is
> purely not applicable to what this document is trying to accomplish.
>
>
>
> I admit I did not follow all the recent advancements in TEAS nor in DETNET
> as far as actually reserving data plane resources in data plane for some
> traffic types. If authors want to build a solution with that - by all means
> green light and full speed ahead - market will decided - especially when it
> will really understand the cost :) But let's make sure the document is
> crystal clear on what building blocks it is talking about.
>
>
>
> Best,
> R.
>
>
>
>
>
> On Sat, Jan 30, 2021 at 11:20 PM Adrian Farrel 
> wrote:
>
> Thanks, Jim,
>
>
>
> I’ve been following the enhanced VPN work in TEAS and I see it as a key
> piece of the network slicing work.
>
>
>
> It’s time that we had some protocol solutions that serve the VPN
> framework, and this is a suitable starting point. I like that it is not
> specifying additional protocol widgets but has looked at what we already
> have and is pointing up ways to use those tools to deliver new function.
>
>
>
> I see Robert’s point about the resource reservation aspects of traffic
> engineering applied to an SR network, but this is not an insurmountable
> problem. The question might be asked, “Why would you want to do that?” but
> that is a question that (as Yakov would have said) the market can decide.
> It seems that there are a couple of vendors and a couple of operators who
> have an interest.
>
>
>
> So I think we should adopt this draft and see whether we can turn it into
> something that has great utility.
>
>
>
> Cheers,
>
> Adrian
>
>
>
> *From:* spring  *On Behalf Of *James Guichard
> *Sent:* 27 January 2021 11:47
> *To:* spring@ietf.org
> *Cc:* spring-cha...@ietf.org
> *Subject:* [spring] WG Adoption Call for
> draft-dong-spring-sr-for-enhanced-vpn
>
>
>
> 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
>
>
>
>
>
>
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
>
> Juniper Business Use Only
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Dongjie (Jimmy)]

Hi Xuesong,

Thanks for your support and comment.

As this document mainly describes the SR data plane mechanisms and the 
procedures of building SR based VTNs, the descriptions about the control plane 
are brief, and the details are left to the control plane drafts. That said, we 
could add some more descriptions about the related control plane functions in 
next version.

Best regards,
Jie

From: Gengxuesong (Geng Xuesong)
Sent: Monday, February 1, 2021 6:04 PM
To: James Guichard ; spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: RE: WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Hi WG,

I support WG adoption of this document, which gives good instructions about how 
to use resoucer-aware SIDs to build SR based VTN.
While in the next version, maybe it is better to add more specifications about 
VTN control plane functions and protocol extensions.  (There is some text in 
section 3 of the existing version, which I think is not sufficient)

Best
Xuesong

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Wednesday, January 27, 2021 7:47 PM
To: spring@ietf.org<mailto:spring@ietf.org>
Cc: spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

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



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

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

[Lizhenbin]

Hi WG,
I support the adoption as the contributor. It has been three years since the 
first version of the draft was proposed. After long-term work, the solution is 
mature and well-accepted. The draft is well written and ready for adoption.


Best Regards,
Zhenbin (Robin)



From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Wednesday, January 27, 2021 7:47 PM
To: spring@ietf.org<mailto:spring@ietf.org>
Cc: spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

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



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

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

[Tarek Saad]

Hi Robert,

RFC3270 talks about two models for reserving resources for LSPs in a MPLS 
Diffserv network (namely E-LSP and L-LSP). While former is the more popular 
implementation amongst vendors, implementations of the latter exist for some 
vendors – i.e. L-LSP which will do per LSP resource allocation.
I agree in non DS-TE deployments, most RSVP-TE implementations I worked with 
will just do control plane reservations/validation for LSP path placement. 
However, for RSVP DS-TE deployments, there is still resources provisioned per 
class in the dataplane – this is to ensure the differentiated treatment for 
class traffic on shared links.

Along those lines, draft-bestbar-teas-ns-packet extends this and proposes 
ability to apply QoS treatment on slice aggregate traffic that traverses a 
shared resource/link. The packet will need to be identified as belonging to the 
slice aggregate. For this, draft-bestbar-teas-ns-packet proposes that a 
separate field can be carried in the packet so it can be used to identify the 
slice aggregate the packet belongs to.

Regards,
Tarek



On 1/31/21, 12:24 PM, "spring on behalf of Robert Raszuk" 
mailto:spring-boun...@ietf.org> on behalf of 
rob...@raszuk.net<mailto:rob...@raszuk.net>> wrote:

Lou,

If you mean ingress policing that this is not what I was referring to - however 
for most if not all shipping RSVP-TE aka MPLS-TE implementation I am not aware 
of any per TE-LSP data plane resource allocation in the date plane. Keen on 
being corrected, but with facts and proof not with claims and statements.

If there are any please kindly enumerate what resources are being reserved and 
how (ie. what RE/RP tells LC to "reserve"). No need to reveal the 
implementation name(s), but if you provide a detailed pointer it would be 
helpful.

Cheers,
R.


On Sun, Jan 31, 2021 at 6:10 PM Lou Berger 
mailto:lber...@labn.net>> wrote:

Robert,

I'm amazed that after all these decades of RSVP and rsvp-te implementations 
there are those who still state that there is no resource allocation or 
management in the data plane. The RFCs are quiet on the topic of how 
reservations are managed/enforced and it is up to the vendor to choose what to 
implement and the user to decide what features are important to them, i.e., 
that they are willing to pay for.

While it is certainly true that there is a well-known vendor that doesn't do 
much in the data plane and there are some who wish that this was the only 
choice, there are certainly TE implementations that do manage/allocate 
resources in the data plane to match reservations established via RSVP or more 
modern sdn-te techniques.

Lou



On January 31, 2021 8:08:31 AM Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
Hi Adrian,

> To your 3209 comments: I believe that *some* implementations have pushed the 
> “reservation”
> into the data plane so that in-network policing is performed to conform data 
> flows with reservations or,

Sure thing that any decent TE implementation and deployment must provide 
ingress policing into TE-LSPs. But this is ingress policing not reservation of 
actual data plane resources which explicitly Jie explained as the intention 
here.

Best,
R.


> On Sun, Jan 31, 2021 at 1:06 PM Adrian Farrel 
> mailto:adr...@olddog.co.uk>> wrote:
Yeah, thanks Robert.

Actually, removing the comparison with other protocols is probably wise. This 
is a document describing how to do stuff with SR. In that context we don’t need 
to talk about the benefits or limitations of other protocols.

To your 3209 comments: I believe that *some* implementations have pushed the 
“reservation” into the data plane so that in-network policing is performed to 
conform data flows with reservations or, at least, ensure that the parts of any 
flow that exceed reservation are treated as best effort. But this is an aside 
to the discussion of the draft at hand.

I think that the document should note that the SR control plane does not 
currently have the capability to make reservations (in the control plane) at 
the network nodes. This can be achieved using a central controller to keep tabs 
on all resource accounting, and it could use a southbound interface to install 
that information in the (management/control parts of the) network nodes.

Cheers,
Adrian

From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: 31 January 2021 00:46
To: Adrian Farrel mailto:adr...@olddog.co.uk>>
Cc: James Guichard 
mailto:james.n.guich...@futurewei.com>>; SPRING 
WG mailto:spring@ietf.org>>; 
spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>
Subject: Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Hi Adrian,

Just to make sure my point was correctly understood ... I am not questioning if 
either data plane or control plane resource reservations should or should not 
be done for SR.

What I am questioni

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

[Tarek Saad]

Hi WG/authors,

My understanding is this draft proposes allocation of per VTN resource-aware 
SID for each topological element in a network.

This means a specific node may carry per VTN state (in control plane and 
dataplane) for each topological element (node or link).
In general, to avoid state explosion, SR endorses carrying additional 
information/context inside the packet.

In draft-bestbar-spring-scalable-ns, we propose to carry a separate ID inside 
the packet that allows a node to identify the packet belonging to 
slice-aggregate (or VTN). This decouples SR SIDs used to steer on topological 
elements from the dataplane ID needed to infer a slice-aggregate (or VTN) so to 
enforce a specific forwarding treatment. This avoids the per VTN SID state 
explosion in control and data plane.

Also, when resource allocation/reservation is strictly done in the control 
plane, it appears per VTN resource SIDs would not serve any further benefit. In 
fact, a PCE or ingress can readily use the regular SIDs to steer any packet 
along a specific path that satisfies the requested resources guarantees as 
verified in the control plane.

Lastly, I draw your attention to draft-bestbar-teas-ns-packet which proposes a 
network wide slice policy as a vehicle that allows allocation of control and/or 
dataplane resources for each slice-aggregate (or VTN) on specific network 
elements.

Regards,
Tarek

On 1/27/21, 6:46 AM, "spring on behalf of James Guichard" 
mailto:spring-boun...@ietf.org> on behalf of 
james.n.guich...@futurewei.com> wrote:

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





Juniper Business Use Only
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Gengxuesong (Geng Xuesong)]

Hi WG,

I support WG adoption of this document, which gives good instructions about how 
to use resoucer-aware SIDs to build SR based VTN.
While in the next version, maybe it is better to add more specifications about 
VTN control plane functions and protocol extensions.  (There is some text in 
section 3 of the existing version, which I think is not sufficient)

Best
Xuesong

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Wednesday, January 27, 2021 7:47 PM
To: spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

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



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

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

[Gyan Mishra]

Hi Adrian

I agree that we need an Enhanced VPN Framework architecture draft that ties
in all related drafts as well as TEAS network slicing framework and
definition.

As Jie mentioned that Enhanced VPN involved data plane provisioning of
resources and that is what the resource SIDs provides in the context of the
main use case of 5G RAN xHaul network slicing.  This is completely
orthogonal to RSVP which is stateful control plane model.

The resource SID draft I believe may need to add some more verbiage
describing in details what resources are being allocated and how this new
resource sid different from a standard prefix or adjacent sid as they both
provide SR-TE steering mechanics.

Kind Regards

Gyan

On Sat, Jan 30, 2021 at 5:20 PM Adrian Farrel  wrote:

> Thanks, Jim,
>
>
>
> I’ve been following the enhanced VPN work in TEAS and I see it as a key
> piece of the network slicing work.
>
>
>
> It’s time that we had some protocol solutions that serve the VPN
> framework, and this is a suitable starting point. I like that it is not
> specifying additional protocol widgets but has looked at what we already
> have and is pointing up ways to use those tools to deliver new function.
>
>
>
> I see Robert’s point about the resource reservation aspects of traffic
> engineering applied to an SR network, but this is not an insurmountable
> problem. The question might be asked, “Why would you want to do that?” but
> that is a question that (as Yakov would have said) the market can decide.
> It seems that there are a couple of vendors and a couple of operators who
> have an interest.
>
>
>
> So I think we should adopt this draft and see whether we can turn it into
> something that has great utility.
>
>
>
> Cheers,
>
> Adrian
>
>
>
> *From:* spring  *On Behalf Of *James Guichard
> *Sent:* 27 January 2021 11:47
> *To:* spring@ietf.org
> *Cc:* spring-cha...@ietf.org
> *Subject:* [spring] WG Adoption Call for
> draft-dong-spring-sr-for-enhanced-vpn
>
>
>
> 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
>
>
>
>
>
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Takuya Miyasaka]

Hi WG,

I support the adoption of this draft as a coauthor.

Some of our customers have already asked us to provide resource isolated 
networks for their mission-critical applications such as real-time video 
transfer, remote surgery, remote control vehicle. To realize such a 
request, I think this draft and resource-aware SID is useful.


Thanks,
Takuya

On 2021/01/27 20:46, James Guichard wrote:


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 10^th 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


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

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

[Robert Raszuk]

Lou,

If you mean ingress policing that this is not what I was referring to -
however for most if not all shipping RSVP-TE aka MPLS-TE implementation I
am not aware of any per TE-LSP data plane resource allocation in the date
plane. Keen on being corrected, but with facts and proof not with claims
and statements.

If there are any please kindly enumerate what resources are being reserved
and how (ie. what RE/RP tells LC to "reserve"). No need to reveal the
implementation name(s), but if you provide a detailed pointer it would
be helpful.

Cheers,
R.


On Sun, Jan 31, 2021 at 6:10 PM Lou Berger  wrote:

> Robert,
>
> I'm amazed that after all these decades of RSVP and rsvp-te
> implementations there are those who still state that there is no resource
> allocation or management in the data plane. The RFCs are quiet on the topic
> of how reservations are managed/enforced and it is up to the vendor to
> choose what to implement and the user to decide what features are important
> to them, i.e., that they are willing to pay for.
>
> While it is certainly true that there is a well-known vendor that doesn't
> do much in the data plane and there are some who wish that this was the
> only choice, there are certainly TE implementations that do manage/allocate
> resources in the data plane to match reservations established via RSVP or
> more modern sdn-te techniques.
>
> Lou
> --
>
> On January 31, 2021 8:08:31 AM Robert Raszuk  wrote:
>
>> Hi Adrian,
>>
>> > To your 3209 comments: I believe that **some** implementations have
>> pushed the “reservation”
>> > into the data plane so that in-network policing is performed to conform
>> data flows with reservations or,
>>
>> Sure thing that any decent TE implementation and deployment must provide
>> ingress policing into TE-LSPs. But this is ingress policing not reservation
>> of actual data plane resources which explicitly Jie explained as the
>> intention here.
>>
>> Best,
>> R.
>>
>>
>> > On Sun, Jan 31, 2021 at 1:06 PM Adrian Farrel 
>> wrote:
>>
>>> Yeah, thanks Robert.
>>>
>>>
>>>
>>> Actually, removing the comparison with other protocols is probably wise.
>>> This is a document describing how to do stuff with SR. In that context we
>>> don’t need to talk about the benefits or limitations of other protocols.
>>>
>>>
>>>
>>> To your 3209 comments: I believe that **some** implementations have
>>> pushed the “reservation” into the data plane so that in-network policing is
>>> performed to conform data flows with reservations or, at least, ensure that
>>> the parts of any flow that exceed reservation are treated as best effort.
>>> But this is an aside to the discussion of the draft at hand.
>>>
>>>
>>>
>>> I think that the document should note that the SR control plane does not
>>> currently have the capability to make reservations (in the control plane)
>>> at the network nodes. This can be achieved using a central controller to
>>> keep tabs on all resource accounting, and it could use a southbound
>>> interface to install that information in the (management/control parts of
>>> the) network nodes.
>>>
>>>
>>>
>>> Cheers,
>>>
>>> Adrian
>>>
>>>
>>>
>>> *From:* Robert Raszuk 
>>> *Sent:* 31 January 2021 00:46
>>> *To:* Adrian Farrel 
>>> *Cc:* James Guichard ; SPRING WG <
>>> spring@ietf.org>; spring-cha...@ietf.org
>>> *Subject:* Re: [spring] WG Adoption Call for
>>> draft-dong-spring-sr-for-enhanced-vpn
>>>
>>>
>>>
>>> Hi Adrian,
>>>
>>>
>>>
>>> Just to make sure my point was correctly understood ... I am not
>>> questioning if either data plane or control plane resource reservations
>>> should or should not be done for SR.
>>>
>>>
>>>
>>> What I am questioning is that the draft says:
>>>
>>>
>>>
>>>When
>>>compared with RSVP-TE [RFC3209], SR currently does not have the
>>>capability to reserve network resources or identify different sets of
>>>network resources reserved for different customers and/or services.
>>>
>>>
>>>
>>> The crux of the matter is that RFC3209 DOES NOT reserve anything in the
>>> data plane of any network element while this spec clearly intends to.
>>> RSVP-TE keeps all reservations in control plane counter

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

[Lou Berger]

Robert,

I'm amazed that after all these decades of RSVP and rsvp-te implementations 
there are those who still state that there is no resource allocation or 
management in the data plane. The RFCs are quiet on the topic of how 
reservations are managed/enforced and it is up to the vendor to choose what to 
implement and the user to decide what features are important to them, i.e., 
that they are willing to pay for.

While it is certainly true that there is a well-known vendor that doesn't do 
much in the data plane and there are some who wish that this was the only 
choice, there are certainly TE implementations that do manage/allocate 
resources in the data plane to match reservations established via RSVP or more 
modern sdn-te techniques.

Lou



On January 31, 2021 8:08:31 AM Robert Raszuk  wrote:

Hi Adrian,

> To your 3209 comments: I believe that *some* implementations have pushed the 
> “reservation”
> into the data plane so that in-network policing is performed to conform data 
> flows with reservations or,

Sure thing that any decent TE implementation and deployment must provide 
ingress policing into TE-LSPs. But this is ingress policing not reservation of 
actual data plane resources which explicitly Jie explained as the intention 
here.

Best,
R.


> On Sun, Jan 31, 2021 at 1:06 PM Adrian Farrel 
> mailto:adr...@olddog.co.uk>> wrote:
Yeah, thanks Robert.

Actually, removing the comparison with other protocols is probably wise. This 
is a document describing how to do stuff with SR. In that context we don’t need 
to talk about the benefits or limitations of other protocols.

To your 3209 comments: I believe that *some* implementations have pushed the 
“reservation” into the data plane so that in-network policing is performed to 
conform data flows with reservations or, at least, ensure that the parts of any 
flow that exceed reservation are treated as best effort. But this is an aside 
to the discussion of the draft at hand.

I think that the document should note that the SR control plane does not 
currently have the capability to make reservations (in the control plane) at 
the network nodes. This can be achieved using a central controller to keep tabs 
on all resource accounting, and it could use a southbound interface to install 
that information in the (management/control parts of the) network nodes.

Cheers,
Adrian

From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: 31 January 2021 00:46
To: Adrian Farrel mailto:adr...@olddog.co.uk>>
Cc: James Guichard 
mailto:james.n.guich...@futurewei.com>>; SPRING 
WG mailto:spring@ietf.org>>; 
spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>
Subject: Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Hi Adrian,

Just to make sure my point was correctly understood ... I am not questioning if 
either data plane or control plane resource reservations should or should not 
be done for SR.

What I am questioning is that the draft says:

   When
   compared with RSVP-TE [RFC3209], SR currently does not have the
   capability to reserve network resources or identify different sets of
   network resources reserved for different customers and/or services.

The crux of the matter is that RFC3209 DOES NOT reserve anything in the data 
plane of any network element while this spec clearly intends to. RSVP-TE keeps 
all reservations in control plane counters only. Constrained based path 
computation/selection happens based on those control plane information. (Yes 
nearly 20 years after this feature shipped I am still meeting people who 
believe otherwise :).

So to start I recommend we remove any reference to RSVP-TE as this is purely 
not applicable to what this document is trying to accomplish.

I admit I did not follow all the recent advancements in TEAS nor in DETNET as 
far as actually reserving data plane resources in data plane for some traffic 
types. If authors want to build a solution with that - by all means green light 
and full speed ahead - market will decided - especially when it will really 
understand the cost :) But let's make sure the document is crystal clear on 
what building blocks it is talking about.

Best,
R.


On Sat, Jan 30, 2021 at 11:20 PM Adrian Farrel 
mailto:adr...@olddog.co.uk>> wrote:
Thanks, Jim,

I’ve been following the enhanced VPN work in TEAS and I see it as a key piece 
of the network slicing work.

It’s time that we had some protocol solutions that serve the VPN framework, and 
this is a suitable starting point. I like that it is not specifying additional 
protocol widgets but has looked at what we already have and is pointing up ways 
to use those tools to deliver new function.

I see Robert’s point about the resource reservation aspects of traffic 
engineering applied to an SR network, but this is not an insurmountable 
problem. The question might be asked, “Why would you want to do that?” but that 

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

[Robert Raszuk]

Hi Adrian,

> To your 3209 comments: I believe that **some** implementations have
pushed the “reservation”
> into the data plane so that in-network policing is performed to conform
data flows with reservations or,

Sure thing that any decent TE implementation and deployment must provide
ingress policing into TE-LSPs. But this is ingress policing not reservation
of actual data plane resources which explicitly Jie explained as the
intention here.

Best,
R.


> On Sun, Jan 31, 2021 at 1:06 PM Adrian Farrel  wrote:

> Yeah, thanks Robert.
>
>
>
> Actually, removing the comparison with other protocols is probably wise.
> This is a document describing how to do stuff with SR. In that context we
> don’t need to talk about the benefits or limitations of other protocols.
>
>
>
> To your 3209 comments: I believe that **some** implementations have
> pushed the “reservation” into the data plane so that in-network policing is
> performed to conform data flows with reservations or, at least, ensure that
> the parts of any flow that exceed reservation are treated as best effort.
> But this is an aside to the discussion of the draft at hand.
>
>
>
> I think that the document should note that the SR control plane does not
> currently have the capability to make reservations (in the control plane)
> at the network nodes. This can be achieved using a central controller to
> keep tabs on all resource accounting, and it could use a southbound
> interface to install that information in the (management/control parts of
> the) network nodes.
>
>
>
> Cheers,
>
> Adrian
>
>
>
> *From:* Robert Raszuk 
> *Sent:* 31 January 2021 00:46
> *To:* Adrian Farrel 
> *Cc:* James Guichard ; SPRING WG <
> spring@ietf.org>; spring-cha...@ietf.org
> *Subject:* Re: [spring] WG Adoption Call for
> draft-dong-spring-sr-for-enhanced-vpn
>
>
>
> Hi Adrian,
>
>
>
> Just to make sure my point was correctly understood ... I am not
> questioning if either data plane or control plane resource reservations
> should or should not be done for SR.
>
>
>
> What I am questioning is that the draft says:
>
>
>
>When
>compared with RSVP-TE [RFC3209], SR currently does not have the
>capability to reserve network resources or identify different sets of
>network resources reserved for different customers and/or services.
>
>
>
> The crux of the matter is that RFC3209 DOES NOT reserve anything in the
> data plane of any network element while this spec clearly intends to.
> RSVP-TE keeps all reservations in control plane counters only.
> Constrained based path computation/selection happens based on those
> control plane information. (Yes nearly 20 years after this feature shipped
> I am still meeting people who believe otherwise :).
>
>
>
> So to start I recommend we remove any reference to RSVP-TE as this is
> purely not applicable to what this document is trying to accomplish.
>
>
>
> I admit I did not follow all the recent advancements in TEAS nor in DETNET
> as far as actually reserving data plane resources in data plane for some
> traffic types. If authors want to build a solution with that - by all means
> green light and full speed ahead - market will decided - especially when it
> will really understand the cost :) But let's make sure the document is
> crystal clear on what building blocks it is talking about.
>
>
>
> Best,
> R.
>
>
>
>
>
> On Sat, Jan 30, 2021 at 11:20 PM Adrian Farrel 
> wrote:
>
> Thanks, Jim,
>
>
>
> I’ve been following the enhanced VPN work in TEAS and I see it as a key
> piece of the network slicing work.
>
>
>
> It’s time that we had some protocol solutions that serve the VPN
> framework, and this is a suitable starting point. I like that it is not
> specifying additional protocol widgets but has looked at what we already
> have and is pointing up ways to use those tools to deliver new function.
>
>
>
> I see Robert’s point about the resource reservation aspects of traffic
> engineering applied to an SR network, but this is not an insurmountable
> problem. The question might be asked, “Why would you want to do that?” but
> that is a question that (as Yakov would have said) the market can decide.
> It seems that there are a couple of vendors and a couple of operators who
> have an interest.
>
>
>
> So I think we should adopt this draft and see whether we can turn it into
> something that has great utility.
>
>
>
> Cheers,
>
> Adrian
>
>
>
> *From:* spring  *On Behalf Of *James Guichard
> *Sent:* 27 January 2021 11:47
> *To:* spring@ietf.org
> *Cc:* spring-cha...@ietf.org
> *Subject:* [spring] WG Adopt

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

[Adrian Farrel]

Yeah, thanks Robert.

 

Actually, removing the comparison with other protocols is probably wise. This 
is a document describing how to do stuff with SR. In that context we don’t need 
to talk about the benefits or limitations of other protocols.

 

To your 3209 comments: I believe that *some* implementations have pushed the 
“reservation” into the data plane so that in-network policing is performed to 
conform data flows with reservations or, at least, ensure that the parts of any 
flow that exceed reservation are treated as best effort. But this is an aside 
to the discussion of the draft at hand.

 

I think that the document should note that the SR control plane does not 
currently have the capability to make reservations (in the control plane) at 
the network nodes. This can be achieved using a central controller to keep tabs 
on all resource accounting, and it could use a southbound interface to install 
that information in the (management/control parts of the) network nodes.

 

Cheers,

Adrian

 

From: Robert Raszuk  
Sent: 31 January 2021 00:46
To: Adrian Farrel 
Cc: James Guichard ; SPRING WG 
; spring-cha...@ietf.org
Subject: Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

 

Hi Adrian,

 

Just to make sure my point was correctly understood ... I am not questioning if 
either data plane or control plane resource reservations should or should not 
be done for SR. 

 

What I am questioning is that the draft says: 

 

   When
   compared with RSVP-TE [RFC3209], SR currently does not have the
   capability to reserve network resources or identify different sets of
   network resources reserved for different customers and/or services.

 

The crux of the matter is that RFC3209 DOES NOT reserve anything in the data 
plane of any network element while this spec clearly intends to. RSVP-TE keeps 
all reservations in control plane counters only. Constrained based path 
computation/selection happens based on those control plane information. (Yes 
nearly 20 years after this feature shipped I am still meeting people who 
believe otherwise :). 

 

So to start I recommend we remove any reference to RSVP-TE as this is purely 
not applicable to what this document is trying to accomplish. 

 

I admit I did not follow all the recent advancements in TEAS nor in DETNET as 
far as actually reserving data plane resources in data plane for some traffic 
types. If authors want to build a solution with that - by all means green light 
and full speed ahead - market will decided - especially when it will really 
understand the cost :) But let's make sure the document is crystal clear on 
what building blocks it is talking about. 

 

Best,
R.

 

 

On Sat, Jan 30, 2021 at 11:20 PM Adrian Farrel mailto:adr...@olddog.co.uk> > wrote:

Thanks, Jim,

 

I’ve been following the enhanced VPN work in TEAS and I see it as a key piece 
of the network slicing work.

 

It’s time that we had some protocol solutions that serve the VPN framework, and 
this is a suitable starting point. I like that it is not specifying additional 
protocol widgets but has looked at what we already have and is pointing up ways 
to use those tools to deliver new function.

 

I see Robert’s point about the resource reservation aspects of traffic 
engineering applied to an SR network, but this is not an insurmountable 
problem. The question might be asked, “Why would you want to do that?” but that 
is a question that (as Yakov would have said) the market can decide. It seems 
that there are a couple of vendors and a couple of operators who have an 
interest.

 

So I think we should adopt this draft and see whether we can turn it into 
something that has great utility.

 

Cheers,

Adrian

 

From: spring mailto:spring-boun...@ietf.org> > On 
Behalf Of James Guichard
Sent: 27 January 2021 11:47
To: spring@ietf.org <mailto:spring@ietf.org> 
Cc: spring-cha...@ietf.org <mailto:spring-cha...@ietf.org> 
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

 

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

 

 

 

___
spring mailing list
spring@ietf.org <mailto:spring@ietf.org> 
https://www.ietf.org/mailman/listinfo/spring

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

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

[Dongjie (Jimmy)]

Hi Robert,

Thanks for explaining your comments further.

We will revise the descriptions about RSVP-TE [RFC3209] to make this clear.

Best regards,
Jie

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Sunday, January 31, 2021 8:46 AM
To: Adrian Farrel 
Cc: James Guichard ; SPRING WG 
; spring-cha...@ietf.org
Subject: Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Hi Adrian,

Just to make sure my point was correctly understood ... I am not questioning if 
either data plane or control plane resource reservations should or should not 
be done for SR.

What I am questioning is that the draft says:

   When
   compared with RSVP-TE [RFC3209], SR currently does not have the
   capability to reserve network resources or identify different sets of
   network resources reserved for different customers and/or services.

The crux of the matter is that RFC3209 DOES NOT reserve anything in the data 
plane of any network element while this spec clearly intends to. RSVP-TE keeps 
all reservations in control plane counters only. Constrained based path 
computation/selection happens based on those control plane information. (Yes 
nearly 20 years after this feature shipped I am still meeting people who 
believe otherwise :).

So to start I recommend we remove any reference to RSVP-TE as this is purely 
not applicable to what this document is trying to accomplish.

I admit I did not follow all the recent advancements in TEAS nor in DETNET as 
far as actually reserving data plane resources in data plane for some traffic 
types. If authors want to build a solution with that - by all means green light 
and full speed ahead - market will decided - especially when it will really 
understand the cost :) But let's make sure the document is crystal clear on 
what building blocks it is talking about.

Best,
R.


On Sat, Jan 30, 2021 at 11:20 PM Adrian Farrel 
mailto:adr...@olddog.co.uk>> wrote:
Thanks, Jim,

I’ve been following the enhanced VPN work in TEAS and I see it as a key piece 
of the network slicing work.

It’s time that we had some protocol solutions that serve the VPN framework, and 
this is a suitable starting point. I like that it is not specifying additional 
protocol widgets but has looked at what we already have and is pointing up ways 
to use those tools to deliver new function.

I see Robert’s point about the resource reservation aspects of traffic 
engineering applied to an SR network, but this is not an insurmountable 
problem. The question might be asked, “Why would you want to do that?” but that 
is a question that (as Yakov would have said) the market can decide. It seems 
that there are a couple of vendors and a couple of operators who have an 
interest.

So I think we should adopt this draft and see whether we can turn it into 
something that has great utility.

Cheers,
Adrian

From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of James Guichard
Sent: 27 January 2021 11:47
To: spring@ietf.org<mailto:spring@ietf.org>
Cc: spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

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



___
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Robert Raszuk]

Hi Adrian,

Just to make sure my point was correctly understood ... I am not
questioning if either data plane or control plane resource reservations
should or should not be done for SR.

What I am questioning is that the draft says:

   When
   compared with RSVP-TE [RFC3209], SR currently does not have the
   capability to reserve network resources or identify different sets of
   network resources reserved for different customers and/or services.

The crux of the matter is that RFC3209 DOES NOT reserve anything in the
data plane of any network element while this spec clearly intends to.
RSVP-TE keeps all reservations in control plane counters only.
Constrained based path computation/selection happens based on those
control plane information. (Yes nearly 20 years after this feature shipped
I am still meeting people who believe otherwise :).

So to start I recommend we remove any reference to RSVP-TE as this is
purely not applicable to what this document is trying to accomplish.

I admit I did not follow all the recent advancements in TEAS nor in DETNET
as far as actually reserving data plane resources in data plane for some
traffic types. If authors want to build a solution with that - by all means
green light and full speed ahead - market will decided - especially when it
will really understand the cost :) But let's make sure the document is
crystal clear on what building blocks it is talking about.

Best,
R.


On Sat, Jan 30, 2021 at 11:20 PM Adrian Farrel  wrote:

> Thanks, Jim,
>
>
>
> I’ve been following the enhanced VPN work in TEAS and I see it as a key
> piece of the network slicing work.
>
>
>
> It’s time that we had some protocol solutions that serve the VPN
> framework, and this is a suitable starting point. I like that it is not
> specifying additional protocol widgets but has looked at what we already
> have and is pointing up ways to use those tools to deliver new function.
>
>
>
> I see Robert’s point about the resource reservation aspects of traffic
> engineering applied to an SR network, but this is not an insurmountable
> problem. The question might be asked, “Why would you want to do that?” but
> that is a question that (as Yakov would have said) the market can decide.
> It seems that there are a couple of vendors and a couple of operators who
> have an interest.
>
>
>
> So I think we should adopt this draft and see whether we can turn it into
> something that has great utility.
>
>
>
> Cheers,
>
> Adrian
>
>
>
> *From:* spring  *On Behalf Of *James Guichard
> *Sent:* 27 January 2021 11:47
> *To:* spring@ietf.org
> *Cc:* spring-cha...@ietf.org
> *Subject:* [spring] WG Adoption Call for
> draft-dong-spring-sr-for-enhanced-vpn
>
>
>
> 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
>
>
>
>
>
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Adrian Farrel]

Thanks, Jim,

 

I've been following the enhanced VPN work in TEAS and I see it as a key
piece of the network slicing work.

 

It's time that we had some protocol solutions that serve the VPN framework,
and this is a suitable starting point. I like that it is not specifying
additional protocol widgets but has looked at what we already have and is
pointing up ways to use those tools to deliver new function.

 

I see Robert's point about the resource reservation aspects of traffic
engineering applied to an SR network, but this is not an insurmountable
problem. The question might be asked, "Why would you want to do that?" but
that is a question that (as Yakov would have said) the market can decide. It
seems that there are a couple of vendors and a couple of operators who have
an interest.

 

So I think we should adopt this draft and see whether we can turn it into
something that has great utility.

 

Cheers,

Adrian

 

From: spring  On Behalf Of James Guichard
Sent: 27 January 2021 11:47
To: spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

 

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

 

 

 

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

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

[Gyan Mishra]

I support WG adoption for this draft that builds on the Enhanced VPN
Framework VPN+ using Segment Routing and with this draft uses  prefix and
adjacency “resource aware” SIDs for VTN underlay resources  SR path
instantiation for 5G RAN xHaul network slicing use case paradigm shift
provisioning of multiple 3GPP GTP-U user planes per network slice.  This
could also be used with DETNET provisioned networks as well as work in
conjunction with APN WG fine grain IP  SLA.

Thanks

Gyan

On Fri, Jan 29, 2021 at 5:25 AM Zhuangshunwan 
wrote:

>
>
> Hi all,
>
>
>
> I support the adoption of this document, it provides a useful mechanism to 
> build
> SR-MPLS/SRv6 based VTNs.
>
>
>
> Best Regards,
>
> Shunwan
>
>
>
>
>
> *From:* spring [mailto:spring-boun...@ietf.org] *On Behalf Of *James
> Guichard
> *Sent:* Wednesday, January 27, 2021 7:47 PM
> *To:* spring@ietf.org
> *Cc:* spring-cha...@ietf.org
> *Subject:* [spring] WG Adoption Call for
> draft-dong-spring-sr-for-enhanced-vpn
>
>
>
> 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
>
>
>
>
>
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Zhuangshunwan]

Hi all,

I support the adoption of this document, it provides a useful mechanism to 
build SR-MPLS/SRv6 based VTNs.

Best Regards,
Shunwan


From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Wednesday, January 27, 2021 7:47 PM
To: spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

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



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

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

[联通集团中国联通研究院-本部]

Hi WG,

I support the adoption of this document. It is an useful feature to build 
customized virtual networks for different types of services in a network.

Best regards,
Pang Ran

From: James Guichard<mailto:james.n.guich...@futurewei.com>
Date: 2021-01-27 19:46
To: spring@ietf.org<mailto:spring@ietf.org>
CC: spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn
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



如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 
hqs-s...@chinaunicom.cn，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received 
this email in error please notify us immediately by e-mail. Please reply to 
hqs-s...@chinaunicom.cn ,you can unsubscribe from this mail. We will 
immediately remove your information from send catalogue of our.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[刘鹏]

Hi all




I support the adoption of this draft.




Regards,

Peng Liu








Peng Liu | 刘鹏

China Mobile | 移动研究院

mobile phone：13810146105

email:  liupeng...@chinamobile.com

 



发件人: James Guichard

时间: 2021/01/27(星期三)19:46

收件人: spring;

抄送人: spring-chairs;

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

 

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 

  

  

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

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

[Robert Raszuk]

Jie,

First observation is that for this to even attempt to work you need hop by
hop strict forwarding. That also means that how ugly to some it may sound
you need signalling to make sure resources are available. So you need per
path state now at each node.

That is what RSVP-TE is doing so why to reinvent the wheel and try to redo
it in SR-MPLS ?

As far as ignoring pure IPv6 in SRv6 setup that pretty much eliminates SRv6
from the picture.

Reserving resources at the interface level needs to be congruent with
routing. None of the documents discuss that part. Further it also needs to
be congruent with even ECMP hashing selection of outgoing links.

In any case my point has been clearly communicated. Good luck with
production deployments and even wide vendor support for this type of
service.

Regards,
R.


On Thu, Jan 28, 2021 at 5:05 PM Dongjie (Jimmy)  wrote:

> Hi Robert,
>
>
>
> *From:* Robert Raszuk [mailto:rob...@raszuk.net]
> *Sent:* Thursday, January 28, 2021 6:52 PM
> *To:* Dongjie (Jimmy) 
> *Cc:* James Guichard ; spring@ietf.org;
> spring-cha...@ietf.org
> *Subject:* Re: [spring] WG Adoption Call for
> draft-dong-spring-sr-for-enhanced-vpn
>
>
>
> Jie,
>
>
>
> Can you perhaps say exactly what "resources" are you planning to reserve ?
> It would be awesome if you in the same time provide yang model and cli on
> this too.
>
>
>
> [Jie] In section 2.1 of draft-ietf-spring-resource-aware-segments-01, some
> candidate approaches of partitioning the link resources are briefly
> mentioned, e.g. FlexE, dedicated queues, etc. For more information please
> refer to section 5 of draft-ietf-teas-enhanced-vpn.
>
>
>
> Take any segment endpoint  - Are you going to reserve PQ space at each
> egress line card ? If not this then what ?
>
>
>
> [Jie] On an SR node, if an interface participates in a VTN, then a set of
> data plane resources needs to be reserved for that VTN. It can be realized
> using one of the candidate appraoches, as long as the set of resource can
> be reserved in data plane.
>
>
>
> Now take any transit none SR aware node - just forwarding pure SRv6
> packets (so here IPv6) - Are you going to reserve PQ space at each egress
> line card ?
>
>
>
> [Jie] As this document describes the SR based mechanism to identify the
> reserved resources in data plane, the behavior of non-SR node is out of the
> scope.
>
>
>
> Note that if this is so - you are essentially doing strict QoS nothing
> more. If not this then what are you really planning to reserve looking at
> each routrer, line card, fabric, interface queues etc ... ?
>
>
>
> In all of the above please keep in mind that routing does change every now
> and then so would the actual path between any two segment endpoints. Unless
> you want to severely waste your network resources and reserve say queueing
> space everywhere - which btw does differ implementation wise vendor to
> vendor too - it will still allow very little services to run over this. And
> IMO you are just going to accomplish exactly the same behaviour as
> with vanilla QoS.
>
>
>
> [Jie] Reserving resources potentially means some waste of resource, as in
> general the reserved resources cannot be used for other things. But this is
> the whole point of reserving resources: they are guaranteed to be
> available. The wasted resources are traded for guaranteed performance.
> Also note the resources are reserved for a group of flows rather than for
> each individual flow, thus the balance between resource utilization and the
> required performance can be achieved for different services.
>
>
>
> Last any form of reservations only make sense when you do strict admission
> control and ingress policing of traffic. I have not seen any discussion on
> this.
>
>
>
> [Jie] Admission control is needed for services which have a specific
> performance requirement. There can also be services without admission
> control in the network, as long as they don’t have expectation on high
> performance, and use a different set of resources.
>
>
>
> Best regards,
>
> Jie
>
>
>
>
>
> Best,
>
> R.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Jan 28, 2021 at 9:52 AM Dongjie (Jimmy) 
> wrote:
>
> Hi Robert,
>
>
>
> *From:* Robert Raszuk [mailto:rob...@raszuk.net]
> *Sent:* Thursday, January 28, 2021 1:01 AM
> *To:* Dongjie (Jimmy) 
> *Cc:* James Guichard ; spring@ietf.org;
> spring-cha...@ietf.org
> *Subject:* Re: [spring] WG Adoption Call for
> draft-dong-spring-sr-for-enhanced-vpn
>
>
>
> Jie,
>
>
>
> > [Jie] Agree that with MPLS-TE the reservation could just happen in the
> control

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

[Dongjie (Jimmy)]

Hi Robert,

From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Thursday, January 28, 2021 6:52 PM
To: Dongjie (Jimmy) 
Cc: James Guichard ; spring@ietf.org; 
spring-cha...@ietf.org
Subject: Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Jie,

Can you perhaps say exactly what "resources" are you planning to reserve ? It 
would be awesome if you in the same time provide yang model and cli on this too.

[Jie] In section 2.1 of draft-ietf-spring-resource-aware-segments-01, some 
candidate approaches of partitioning the link resources are briefly mentioned, 
e.g. FlexE, dedicated queues, etc. For more information please refer to section 
5 of draft-ietf-teas-enhanced-vpn.

Take any segment endpoint  - Are you going to reserve PQ space at each egress 
line card ? If not this then what ?

[Jie] On an SR node, if an interface participates in a VTN, then a set of data 
plane resources needs to be reserved for that VTN. It can be realized using one 
of the candidate appraoches, as long as the set of resource can be reserved in 
data plane.

Now take any transit none SR aware node - just forwarding pure SRv6 packets (so 
here IPv6) - Are you going to reserve PQ space at each egress line card ?

[Jie] As this document describes the SR based mechanism to identify the 
reserved resources in data plane, the behavior of non-SR node is out of the 
scope.

Note that if this is so - you are essentially doing strict QoS nothing more. If 
not this then what are you really planning to reserve looking at each routrer, 
line card, fabric, interface queues etc ... ?

In all of the above please keep in mind that routing does change every now and 
then so would the actual path between any two segment endpoints. Unless you 
want to severely waste your network resources and reserve say queueing space 
everywhere - which btw does differ implementation wise vendor to vendor too - 
it will still allow very little services to run over this. And IMO you are just 
going to accomplish exactly the same behaviour as with vanilla QoS.

[Jie] Reserving resources potentially means some waste of resource, as in 
general the reserved resources cannot be used for other things. But this is the 
whole point of reserving resources: they are guaranteed to be available. The 
wasted resources are traded for guaranteed performance.  Also note the 
resources are reserved for a group of flows rather than for each individual 
flow, thus the balance between resource utilization and the required 
performance can be achieved for different services.

Last any form of reservations only make sense when you do strict admission 
control and ingress policing of traffic. I have not seen any discussion on this.

[Jie] Admission control is needed for services which have a specific 
performance requirement. There can also be services without admission control 
in the network, as long as they don’t have expectation on high performance, and 
use a different set of resources.

Best regards,
Jie


Best,
R.







On Thu, Jan 28, 2021 at 9:52 AM Dongjie (Jimmy) 
mailto:jie.d...@huawei.com>> wrote:
Hi Robert,

From: Robert Raszuk [mailto:rob...@raszuk.net<mailto:rob...@raszuk.net>]
Sent: Thursday, January 28, 2021 1:01 AM
To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>
Cc: James Guichard 
mailto:james.n.guich...@futurewei.com>>; 
spring@ietf.org<mailto:spring@ietf.org>; 
spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>
Subject: Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Jie,

> [Jie] Agree that with MPLS-TE the reservation could just happen in the 
> control plane

This is not "could" ... this is real - they *are* happening all in control 
plane only.

The only data plane reservations were done with RSVP Int-Serv (for those who 
still even remember this) and you see how far it went.

For IP networks based on statistical multiplexing hard allocation of any data 
plane resources == waisted resources.

[Jie #2] RSVP Int-Serv defines the mechanism for per-flow data plane resource 
reservation, which has the scalability issue, and as you mentioned, no 
statistical multiplexing gains. Its value is that it can provide guaranteed 
performance for the service.

In contrast, the mechanism in the resource-aware segments draft and this 
document is based on per-segment resource reservation rather than per-flow 
reservation. Based on the resource-aware SIDs, multiple flows of the same 
customer or of a particular service group can share the same set of data plane 
resources. Thus comparing with RSVP Int-Serv, this mechanism has better 
scalability and allows statistical multiplexing among the customers or services 
in the same group, it can also avoid the competition or impact between 
customers or services which are assigned to different groups of resources. More 
about this is described in section 4 of this document.

Hope this helps.

Best regards,
Jie

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

[xie...@chinatelecom.cn]

Hi, Spring WG,
I support the adoption of this document. It describes a mechanism to build SR 
based virtual networks with customized attributes.

Best regards
Chongfeng

 
From: James Guichard
Date: 2021-01-27 19:46
To: spring@ietf.org
CC: spring-cha...@ietf.org
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn
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
 
 
 
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Robert Raszuk]

Jie,

Can you perhaps say exactly what "resources" are you planning to reserve ?
It would be awesome if you in the same time provide yang model and cli on
this too.

Take any segment endpoint  - Are you going to reserve PQ space at each
egress line card ? If not this then what ?

Now take any transit none SR aware node - just forwarding pure SRv6 packets
(so here IPv6) - Are you going to reserve PQ space at each egress line card
?

Note that if this is so - you are essentially doing strict QoS nothing
more. If not this then what are you really planning to reserve looking at
each routrer, line card, fabric, interface queues etc ... ?

In all of the above please keep in mind that routing does change every now
and then so would the actual path between any two segment endpoints. Unless
you want to severely waste your network resources and reserve say queueing
space everywhere - which btw does differ implementation wise vendor to
vendor too - it will still allow very little services to run over this. And
IMO you are just going to accomplish exactly the same behaviour as
with vanilla QoS.

Last any form of reservations only make sense when you do strict admission
control and ingress policing of traffic. I have not seen any discussion on
this.

Best,
R.







On Thu, Jan 28, 2021 at 9:52 AM Dongjie (Jimmy)  wrote:

> Hi Robert,
>
>
>
> *From:* Robert Raszuk [mailto:rob...@raszuk.net]
> *Sent:* Thursday, January 28, 2021 1:01 AM
> *To:* Dongjie (Jimmy) 
> *Cc:* James Guichard ; spring@ietf.org;
> spring-cha...@ietf.org
> *Subject:* Re: [spring] WG Adoption Call for
> draft-dong-spring-sr-for-enhanced-vpn
>
>
>
> Jie,
>
>
>
> > [Jie] Agree that with MPLS-TE the reservation could just happen in the
> control plane
>
>
>
> This is not "could" ... this is real - they *are* happening all in control
> plane only.
>
>
>
> The only data plane reservations were done with RSVP Int-Serv (for those
> who still even remember this) and you see how far it went.
>
>
>
> For IP networks based on statistical multiplexing hard allocation of any
> data plane resources == waisted resources.
>
>
>
> [Jie #2] RSVP Int-Serv defines the mechanism for per-flow data plane
> resource reservation, which has the scalability issue, and as you
> mentioned, no statistical multiplexing gains. Its value is that it can
> provide guaranteed performance for the service.
>
>
>
> In contrast, the mechanism in the resource-aware segments draft and this
> document is based on per-segment resource reservation rather than per-flow
> reservation. Based on the resource-aware SIDs, multiple flows of the same
> customer or of a particular service group can share the same set of data
> plane resources. Thus comparing with RSVP Int-Serv, this mechanism has
> better scalability and allows statistical multiplexing among the customers
> or services in the same group, it can also avoid the competition or impact
> between customers or services which are assigned to different groups of
> resources. More about this is described in section 4 of this document.
>
>
>
> Hope this helps.
>
>
>
> Best regards,
>
> Jie
>
>
>
>
>
> Many thx,
>
> R.
>
>
>
> On Wed, Jan 27, 2021 at 4:39 PM Dongjie (Jimmy) 
> wrote:
>
> Hi Robert,
>
>
>
> Thanks for your email. Please see some replies inline with [Jie]:
>
>
>
> *From:* spring [mailto:spring-boun...@ietf.org] *On Behalf Of *Robert
> Raszuk
> *Sent:* Wednesday, January 27, 2021 8:03 PM
> *To:* James Guichard 
> *Cc:* spring@ietf.org; spring-cha...@ietf.org
> *Subject:* Re: [spring] WG Adoption Call for
> draft-dong-spring-sr-for-enhanced-vpn
>
>
>
> All,
>
>
>
> Before I make a decision on expressing my support or indicate no support I
> would like to better understand what resource reservation is being
> discussed here.
>
>
>
> [Jie] The resource reservation here refers to the data plane resources
> reserved for different virtual transport networks.
>
>
>
> draft-ietf-spring-resource-aware-segments-01 also talks about
> "reservations" yet lacks clarity what those reservations will actually be.
> It provides analogy to MPLS-TE, but at least those who build MPLS-TE
> products are aware MPLS-TE or even MPLS GB-TE does not provide any data
> plane reservations. All both do is to provide control plane resource
> bookings.
>
>
>
> [Jie] Agree that with MPLS-TE the reservation could just happen in the
> control plane and does not have to be in the data plane.
> draft-ietf-spring-resource-aware-segments-01 also mentions the inefficiency
> of the controller based resource management with existing SR in some
> scenarios, thus both the 

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

[Mach Chen]

Hi,

I have read the document, it provides a practical approach to build resource 
guaranteed virtual transport networks based on resource-aware SIDs. I think 
it's useful and hence support the adoption of the document.

Best regards,
Mach

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Wednesday, January 27, 2021 7:47 PM
To: spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

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



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

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

[Dongjie (Jimmy)]

Hi Robert,

From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Thursday, January 28, 2021 1:01 AM
To: Dongjie (Jimmy) 
Cc: James Guichard ; spring@ietf.org; 
spring-cha...@ietf.org
Subject: Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Jie,

> [Jie] Agree that with MPLS-TE the reservation could just happen in the 
> control plane

This is not "could" ... this is real - they *are* happening all in control 
plane only.

The only data plane reservations were done with RSVP Int-Serv (for those who 
still even remember this) and you see how far it went.

For IP networks based on statistical multiplexing hard allocation of any data 
plane resources == waisted resources.

[Jie #2] RSVP Int-Serv defines the mechanism for per-flow data plane resource 
reservation, which has the scalability issue, and as you mentioned, no 
statistical multiplexing gains. Its value is that it can provide guaranteed 
performance for the service.

In contrast, the mechanism in the resource-aware segments draft and this 
document is based on per-segment resource reservation rather than per-flow 
reservation. Based on the resource-aware SIDs, multiple flows of the same 
customer or of a particular service group can share the same set of data plane 
resources. Thus comparing with RSVP Int-Serv, this mechanism has better 
scalability and allows statistical multiplexing among the customers or services 
in the same group, it can also avoid the competition or impact between 
customers or services which are assigned to different groups of resources. More 
about this is described in section 4 of this document.

Hope this helps.

Best regards,
Jie


Many thx,
R.

On Wed, Jan 27, 2021 at 4:39 PM Dongjie (Jimmy) 
mailto:jie.d...@huawei.com>> wrote:
Hi Robert,

Thanks for your email. Please see some replies inline with [Jie]:

From: spring [mailto:spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>] 
On Behalf Of Robert Raszuk
Sent: Wednesday, January 27, 2021 8:03 PM
To: James Guichard 
mailto:james.n.guich...@futurewei.com>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; 
spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>
Subject: Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

All,

Before I make a decision on expressing my support or indicate no support I 
would like to better understand what resource reservation is being discussed 
here.

[Jie] The resource reservation here refers to the data plane resources reserved 
for different virtual transport networks.

draft-ietf-spring-resource-aware-segments-01 also talks about "reservations" 
yet lacks clarity what those reservations will actually be. It provides analogy 
to MPLS-TE, but at least those who build MPLS-TE products are aware MPLS-TE or 
even MPLS GB-TE does not provide any data plane reservations. All both do is to 
provide control plane resource bookings.

[Jie] Agree that with MPLS-TE the reservation could just happen in the control 
plane and does not have to be in the data plane. 
draft-ietf-spring-resource-aware-segments-01 also mentions the inefficiency of 
the controller based resource management with existing SR in some scenarios, 
thus both the resource-aware-segments draft and this draft are talking about 
data plane resource reservation.

So fundamentally does draft-ietf-spring-resource-aware-segments-01 and this 
draft in question also are trying to now map SIDs to control plane resource 
bookings ? Note fundamentally in all above cases it only works when all traffic 
in yr network is actually using such reservations as otherwise unaccounted 
traffic will destroy the game completely for those who think we see green light 
we are good to go. That is also why for real TE it is/was critical in MPLS-TE 
to provide such engineering for all of your ingress-egress macro flows.

[Jie] As explained above, the idea is to associate different SIDs with 
different sets of data plane resources reserved in the network, so that traffic 
encapsulated with different SIDs will be steered into different set of data 
plane resources. This way the unaccounted traffic in your example will only be 
allowed to occupy the set of resources which are associated with the SIDs 
carried in the packet. Thus the mechanism could work without per-flow 
engineering.

Even then if you start to run other traffic on the same links ... say multicast 
or control plane storms of any sort - again all of your assumed reservations 
are immediately becoming unnecessary complexity with zero benefits.

[Jie] Similarly, based on the above mechanism, the impact of multicast or 
control plane storms can also be limited to a subset of data plane resources. 
This is the benefit of the data plane resource reservation.

So with that let's make sure we understand what is being proposed here.

Btw if someone has a pointer to discussion about  
spring-resource-aware-segments it would be great too. My few years of 

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

[Huzhibo]

Support,. It is a specific application scenario of resource-aware-segments.

Best Regards,
Zhibo Hu
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Wednesday, January 27, 2021 7:47 PM
To: spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

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



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

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

[duzongp...@foxmail.com]

Hi, all

I support the adoption of this document, it provides a useful mechanism to 
meet different service requirements in operators' network.

Best Regards
Zongpeng Du



duzongp...@foxmail.com & duzongp...@chinamobile.com
 
From: James Guichard
Date: 2021-01-27 19:46
To: spring@ietf.org
CC: spring-cha...@ietf.org
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn
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
 
 
 
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Robert Raszuk]

Jie,

> [Jie] Agree that with MPLS-TE the reservation could just happen in the
control plane

This is not "could" ... this is real - they *are* happening all in control
plane only.

The only data plane reservations were done with RSVP Int-Serv (for those
who still even remember this) and you see how far it went.

For IP networks based on statistical multiplexing hard allocation of any
data plane resources == waisted resources.

Many thx,
R.

On Wed, Jan 27, 2021 at 4:39 PM Dongjie (Jimmy)  wrote:

> Hi Robert,
>
>
>
> Thanks for your email. Please see some replies inline with [Jie]:
>
>
>
> *From:* spring [mailto:spring-boun...@ietf.org] *On Behalf Of *Robert
> Raszuk
> *Sent:* Wednesday, January 27, 2021 8:03 PM
> *To:* James Guichard 
> *Cc:* spring@ietf.org; spring-cha...@ietf.org
> *Subject:* Re: [spring] WG Adoption Call for
> draft-dong-spring-sr-for-enhanced-vpn
>
>
>
> All,
>
>
>
> Before I make a decision on expressing my support or indicate no support I
> would like to better understand what resource reservation is being
> discussed here.
>
>
>
> [Jie] The resource reservation here refers to the data plane resources
> reserved for different virtual transport networks.
>
>
>
> draft-ietf-spring-resource-aware-segments-01 also talks about
> "reservations" yet lacks clarity what those reservations will actually be.
> It provides analogy to MPLS-TE, but at least those who build MPLS-TE
> products are aware MPLS-TE or even MPLS GB-TE does not provide any data
> plane reservations. All both do is to provide control plane resource
> bookings.
>
>
>
> [Jie] Agree that with MPLS-TE the reservation could just happen in the
> control plane and does not have to be in the data plane.
> draft-ietf-spring-resource-aware-segments-01 also mentions the inefficiency
> of the controller based resource management with existing SR in some
> scenarios, thus both the resource-aware-segments draft and this draft are
> talking about data plane resource reservation.
>
>
>
> So fundamentally does draft-ietf-spring-resource-aware-segments-01 and
> this draft in question also are trying to now map SIDs to control plane
> resource bookings ? Note fundamentally in all above cases it only works
> when all traffic in yr network is actually using such reservations as
> otherwise unaccounted traffic will destroy the game completely for those
> who think we see green light we are good to go. That is also why for real
> TE it is/was critical in MPLS-TE to provide such engineering for all of
> your ingress-egress macro flows.
>
>
>
> [Jie] As explained above, the idea is to associate different SIDs with
> different sets of data plane resources reserved in the network, so that
> traffic encapsulated with different SIDs will be steered into different set
> of data plane resources. This way the unaccounted traffic in your example
> will only be allowed to occupy the set of resources which are associated
> with the SIDs carried in the packet. Thus the mechanism could work without
> per-flow engineering.
>
>
>
> Even then if you start to run other traffic on the same links ... say
> multicast or control plane storms of any sort - again all of your assumed
> reservations are immediately becoming unnecessary complexity with zero
> benefits.
>
>
>
> [Jie] Similarly, based on the above mechanism, the impact of multicast or
> control plane storms can also be limited to a subset of data plane
> resources. This is the benefit of the data plane resource reservation.
>
>
>
> So with that let's make sure we understand what is being proposed here.
>
>
>
> Btw if someone has a pointer to discussion about
> spring-resource-aware-segments it would be great too. My few years of email
> history does not return much. Maybe the draft got renamed during publishing
> as SPRING WG item.
>
>
>
> [Jie] The history is, draft-ietf-spring-resource-aware-segments was part
> of draft-dong-spring-sr-for-enhanced-vpn. After the first the adoption poll
> on this document last year, based on the received comments and the chairs’
> suggestion, it was split out as a general enhancement to SR, and the rest
> part of draft-dong-spring-sr-for-enhanced-vpn continues as an application
> of the resource-aware segments.
>
>
>
> Hope the above helps to provide some background information.
>
>
>
> Best regards,
>
> Jie
>
>
>
> Thx,
> R.
>
>
>
>
>
> On Wed, Jan 27, 2021 at 12:46 PM James Guichard <
> james.n.guich...@futurewei.com> wrote:
>
> Dear WG:
>
>
>
> This message starts a 2 week WG adoption call for
> https://datatracker.ietf.org/doc/draft-dong-spring-sr-

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

[Dongjie (Jimmy)]

Hi Robert,

Thanks for your email. Please see some replies inline with [Jie]:

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Wednesday, January 27, 2021 8:03 PM
To: James Guichard 
Cc: spring@ietf.org; spring-cha...@ietf.org
Subject: Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

All,

Before I make a decision on expressing my support or indicate no support I 
would like to better understand what resource reservation is being discussed 
here.

[Jie] The resource reservation here refers to the data plane resources reserved 
for different virtual transport networks.

draft-ietf-spring-resource-aware-segments-01 also talks about "reservations" 
yet lacks clarity what those reservations will actually be. It provides analogy 
to MPLS-TE, but at least those who build MPLS-TE products are aware MPLS-TE or 
even MPLS GB-TE does not provide any data plane reservations. All both do is to 
provide control plane resource bookings.

[Jie] Agree that with MPLS-TE the reservation could just happen in the control 
plane and does not have to be in the data plane. 
draft-ietf-spring-resource-aware-segments-01 also mentions the inefficiency of 
the controller based resource management with existing SR in some scenarios, 
thus both the resource-aware-segments draft and this draft are talking about 
data plane resource reservation.

So fundamentally does draft-ietf-spring-resource-aware-segments-01 and this 
draft in question also are trying to now map SIDs to control plane resource 
bookings ? Note fundamentally in all above cases it only works when all traffic 
in yr network is actually using such reservations as otherwise unaccounted 
traffic will destroy the game completely for those who think we see green light 
we are good to go. That is also why for real TE it is/was critical in MPLS-TE 
to provide such engineering for all of your ingress-egress macro flows.

[Jie] As explained above, the idea is to associate different SIDs with 
different sets of data plane resources reserved in the network, so that traffic 
encapsulated with different SIDs will be steered into different set of data 
plane resources. This way the unaccounted traffic in your example will only be 
allowed to occupy the set of resources which are associated with the SIDs 
carried in the packet. Thus the mechanism could work without per-flow 
engineering.

Even then if you start to run other traffic on the same links ... say multicast 
or control plane storms of any sort - again all of your assumed reservations 
are immediately becoming unnecessary complexity with zero benefits.

[Jie] Similarly, based on the above mechanism, the impact of multicast or 
control plane storms can also be limited to a subset of data plane resources. 
This is the benefit of the data plane resource reservation.

So with that let's make sure we understand what is being proposed here.

Btw if someone has a pointer to discussion about  
spring-resource-aware-segments it would be great too. My few years of email 
history does not return much. Maybe the draft got renamed during publishing as 
SPRING WG item.

[Jie] The history is, draft-ietf-spring-resource-aware-segments was part of 
draft-dong-spring-sr-for-enhanced-vpn. After the first the adoption poll on 
this document last year, based on the received comments and the chairs’ 
suggestion, it was split out as a general enhancement to SR, and the rest part 
of draft-dong-spring-sr-for-enhanced-vpn continues as an application of the 
resource-aware segments.

Hope the above helps to provide some background information.

Best regards,
Jie

Thx,
R.


On Wed, Jan 27, 2021 at 12:46 PM James Guichard 
mailto:james.n.guich...@futurewei.com>> wrote:
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



___
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Robert Raszuk]

All,

Before I make a decision on expressing my support or indicate no support I
would like to better understand what resource reservation is being
discussed here.

draft-ietf-spring-resource-aware-segments-01 also talks about
"reservations" yet lacks clarity what those reservations will actually be.
It provides analogy to MPLS-TE, but at least those who build MPLS-TE
products are aware MPLS-TE or even MPLS GB-TE does not provide any data
plane reservations. All both do is to provide control plane resource
bookings.

So fundamentally does draft-ietf-spring-resource-aware-segments-01 and this
draft in question also are trying to now map SIDs to control plane
resource bookings ? Note fundamentally in all above cases it only works
when all traffic in yr network is actually using such reservations as
otherwise unaccounted traffic will destroy the game completely for those
who think we see green light we are good to go. That is also why for real
TE it is/was critical in MPLS-TE to provide such engineering for all of
your ingress-egress macro flows.

Even then if you start to run other traffic on the same links ... say
multicast or control plane storms of any sort - again all of your assumed
reservations are immediately becoming unnecessary complexity with zero
benefits.

So with that let's make sure we understand what is being proposed here.

Btw if someone has a pointer to discussion about
spring-resource-aware-segments it would be great too. My few years of email
history does not return much. Maybe the draft got renamed during publishing
as SPRING WG item.

Thx,
R.


On Wed, Jan 27, 2021 at 12:46 PM James Guichard <
james.n.guich...@futurewei.com> wrote:

> 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
>
>
>
>
>
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[James Guichard]

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



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

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

[Greg Mirsky]

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  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?
>- 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
>
> On Wed, Jul 15, 2020 at 4:17 AM James Guichard <
> james.n.guich...@futurewei.com> wrote:
>
>> 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
>>
>>
>>
>>
>>
>>
>> ___
>> spring mailing list
>> spring@ietf.org
>> https://www.ietf.org/mailman/listinfo/spring
>>
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Loa Andersson]

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

On 15/07/2020 19:16, James Guichard wrote:

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 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 
thereof). Silence will not be considered consent.


Thanks!

Jim, Joel & Bruno


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



--

Loa Anderssonemail: l...@pi.nu
Senior MPLS Expert  loa.pi...@gmail.com
Bronze Dragon Consulting phone: +46 739 81 21 64

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

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

[xiong.quan]

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 

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

[Shunsuke Homma]

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  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?
>- 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
>
> On Wed, Jul 15, 2020 at 4:17 AM James Guichard <
> james.n.guich...@futurewei.com> wrote:
>
>> 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
>>
>>
>>
>>
>>
>>
>> ___
>> spring mailing list
>> spring@ietf.org
>> https://www.ietf.org/mailman/listinfo/spring
>>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Greg Mirsky]

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

On Wed, Jul 15, 2020 at 4:17 AM James Guichard <
james.n.guich...@futurewei.com> wrote:

> 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
>
>
>
>
>
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[lic...@chinatelecom.cn]

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: spring@ietf.org
CC: spring-cha...@ietf.org
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
 
 
 
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[ma...@chinatelecom.cn]

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: spring@ietf.org
CC: spring-cha...@ietf.org
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
 
 
 
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Stewart Bryant]

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  
> wrote:
> 
> 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
>  
>  
>  
> ___
> spring mailing list
> spring@ietf.org 
> https://www.ietf.org/mailman/listinfo/spring 
> 
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Adrian Farrel]

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

 

From: spring  On Behalf Of James Guichard
Sent: 15 July 2020 12:17
To: spring@ietf.org
Cc: spring-cha...@ietf.org
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

 

 

 

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

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

[Luis M. Contreras]

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

El mié., 15 jul. 2020 a las 13:17, James Guichard (<
james.n.guich...@futurewei.com>) escribió:

> 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
>
>
>
>
>
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>


-- 
___
Luis M. Contreras
contreras.i...@gmail.com
luismiguel.contrerasmuri...@telefonica.com
Global CTIO unit / Telefonica
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Weiqiang Cheng]

I support the adoption of this document.

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

 

B.R.

Weiqiang Cheng

 

发件人: spring [mailto:spring-boun...@ietf.org] 代表 James Guichard
发送时间: 2020年7月15日 19:17
收件人: spring@ietf.org
抄送: spring-cha...@ietf.org
主题: [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

 

 

 

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

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

[Yingzhen Qu]

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  on behalf of James Guichard 

Date: Wednesday, July 15, 2020 at 4:17 AM
To: "spring@ietf.org" 
Cc: "spring-cha...@ietf.org" 
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn
Resent-From: 

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=02%7C01%7Cyingzhen.qu%40futurewei.com%7C62940ff55d094466bef508d828b0b08d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637304086634789052=Q3G9%2F7b4cyRLRpre%2B%2F%2BVLMJYY88ut0GbceKauulQXG0%3D=0>
 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



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

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

[Dongjie (Jimmy)]

Hi Tarek,

Thanks for your comment, please see some replies inline:

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Tarek Saad
Sent: Sunday, July 26, 2020 2:57 AM
To: James Guichard ; spring@ietf.org
Cc: spring-cha...@ietf.org
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.

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.

[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 mailto:spring-boun...@ietf.org>> on 
behalf of James Guichard 
mailto:james.n.guich...@futurewei.com>>
Date: Wednesday, July 15, 2020 at 7:17 AM
To: "spring@ietf.org<mailto:spring@ietf.org>" 
mailto:spring@ietf.org>>
Cc: "spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>" 
mailto:spring-cha...@ietf.org>>
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



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

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

[Dongjie (Jimmy)]

Hi Dhruv, 

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

> -Original Message-
> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Dhruv Dhody
> Sent: Sunday, July 26, 2020 1:28 AM
> To: James Guichard 
> Cc: spring@ietf.org; spring-cha...@ietf.org
> Subject: Re: [spring] WG Adoption Call for
> draft-dong-spring-sr-for-enhanced-vpn
> 
> 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

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

> 
> Thanks!
> Dhruv
> 
> 
> 
> 
> 
> On Wed, Jul 15, 2020 at 4:47 PM James Guichard
>  wrote:
> >
> > 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
> >
> >
> >
> >
> >
> >
> >
> > ___
> > spring mailing list
> > spring@ietf.org
> > https://www.ietf.org/mailman/listinfo/spring
> 
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring

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

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

[Tarek Saad]

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  on behalf of James Guichard 

Date: Wednesday, July 15, 2020 at 7:17 AM
To: "spring@ietf.org" 
Cc: "spring-cha...@ietf.org" 
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



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

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

[Dhruv Dhody]

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





On Wed, Jul 15, 2020 at 4:47 PM James Guichard
 wrote:
>
> 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
>
>
>
>
>
>
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring

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

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

[Huaimo Chen]

Support.

Best Regards,
Huaimo

From: spring  on behalf of James Guichard 

Sent: Wednesday, July 15, 2020 7:16 AM
To: spring@ietf.org 
Cc: spring-cha...@ietf.org 
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






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

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

[Dongjie (Jimmy)]

Hi Ketan,

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

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Ketan Talaulikar 
(ketant)
Sent: Friday, July 24, 2020 2:27 AM
To: James Guichard 
mailto:james.n.guich...@futurewei.com>>; 
spring@ietf.org<mailto:spring@ietf.org>
Cc: spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>
Subject: Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn


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



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



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.



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



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.



[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

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

[Ketan Talaulikar (ketant)]

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


From: spring  On Behalf Of James Guichard
Sent: 15 July 2020 16:47
To: spring@ietf.org
Cc: spring-cha...@ietf.org
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



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

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

[Francois Clad (fclad)]

Hi,

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

Thanks,
Francois

From: spring  on behalf of James Guichard 

Date: Wednesday 15 July 2020 at 13:17
To: "spring@ietf.org" 
Cc: "spring-cha...@ietf.org" 
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



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

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

[Takuya Miyasaka]

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


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 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 
thereof). Silence will not be considered consent.


Thanks!

Jim, Joel & Bruno


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

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

[Gengxuesong (Geng Xuesong)]

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


From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Wednesday, July 15, 2020 7:17 PM
To: spring@ietf.org
Cc: spring-cha...@ietf.org
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



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

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

[联通北京市北京市分公司]

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 (bjunicom_qzz_mo...@126.com)

ChinaUnicom

如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 
hqs-s...@chinaunicom.cn，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received 
this email in error please notify us immediately by e-mail. Please reply to 
hqs-s...@chinaunicom.cn ,you can unsubscribe from this mail. We will 
immediately remove your information from send catalogue of our.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Tomonobu Niwa]

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: to-n...@kddi.com



-Original Message-
From: spring  On Behalf Of James Guichard
Sent: Wednesday, July 15, 2020 8:17 PM
To: spring@ietf.org
Cc: spring-cha...@ietf.org
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. 

 

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

 

 

 


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

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

[Aijun Wang]

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: spring-boun...@ietf.org [mailto:spring-boun...@ietf.org] On Behalf Of
James Guichard
Sent: Wednesday, July 15, 2020 7:17 PM
To: spring@ietf.org
Cc: spring-cha...@ietf.org
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

 

 

 

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

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

[联通集团联通网络技术研究院本部]

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:james.n.guich...@futurewei.com>
Date: 2020-07-15 19:16
To: spring@ietf.org<mailto:spring@ietf.org>
CC: spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>
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



如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 
hqs-s...@chinaunicom.cn，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received 
this email in error please notify us immediately by e-mail. Please reply to 
hqs-s...@chinaunicom.cn ,you can unsubscribe from this mail. We will 
immediately remove your information from send catalogue of our.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Dongjie (Jimmy)]

Hi Linda,

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

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Linda Dunbar
Sent: Thursday, July 16, 2020 4:54 AM
To: James Guichard ; spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

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?

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

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?

[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 mailto:spring-boun...@ietf.org>> On 
Behalf Of James Guichard
Sent: Wednesday, July 15, 2020 6:17 AM
To: spring@ietf.org<mailto:spring@ietf.org>
Cc: spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>
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=02%7C01%7Clinda.dunbar%40futurewei.com%7Cf03a8de844774eb62c1508d828b09948%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637304086252107481=G75TrLzE%2FhSgHuwP4cClUusCr%2BofY0C1Kq%2Fq9CBDOwE%3D=0>
 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



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

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

[zhaof...@caict.ac.cn]

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: zhaof...@caict.ac.cn
Tel: 86-10-62300055
Mobile: 8613601068212
Fax: 86-10-62300094

 
From: James Guichard
Date: 2020-07-15 19:16
To: spring@ietf.org
CC: spring-cha...@ietf.org
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
 
 
 
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Mach Chen]

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

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Wednesday, July 15, 2020 7:17 PM
To: spring@ietf.org
Cc: spring-cha...@ietf.org
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



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

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

[Peng Liu]

Hi All,

I support the adoption of the draft. 

Regards,
Peng Liu



liupeng...@outlook.com
 
From: James Guichard
Date: 2020-07-15 19:16
To: spring@ietf.org
CC: spring-cha...@ietf.org
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
 
 
 
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Gyan Mishra]

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

> Yes/support
>
> Regards,
> Jeff
>
> On Jul 15, 2020, at 04:17, James Guichard 
> wrote:
>
> 
>
> 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
>
>
>
>
>
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Jeff Tantsura]

Yes/support

Regards,
Jeff

> On Jul 15, 2020, at 04:17, James Guichard  
> wrote:
> 
> 
> 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
>  
>  
>  
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Xiejingrong (Jingrong)]

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

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Wednesday, July 15, 2020 7:17 PM
To: spring@ietf.org
Cc: spring-cha...@ietf.org
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



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

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

[Huzhibo]

Hi WG,

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


Thanks,
Zhibo


From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Wednesday, July 15, 2020 7:17 PM
To: spring@ietf.org
Cc: spring-cha...@ietf.org
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



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

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

[Zhuangshunwan]

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:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Wednesday, July 15, 2020 7:17 PM
To: spring@ietf.org
Cc: spring-cha...@ietf.org
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



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

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

[James Guichard]

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



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