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

From: James Guichard <[email-masked]>
Date: Wed, 27 Jan 2021 11:46:35 +0000

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

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 27 Jan 2021 13:03:17 +0100

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 <
[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 27 Jan 2021 15:39:12 +0000

Hi Robert,

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

From: spring [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Wednesday, January 27, 2021 8:03 PM
To: James Guichard <[email-masked]>
Cc: [email-masked]; [email-masked]
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.

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 <[email-masked]<mailto:[email-masked]>> wrote:
Dear WG:

Thanks!

Jim, Bruno & Joel

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 27 Jan 2021 18:00:59 +0100

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) <[email-masked]> wrote:

> *From:* spring [mailto:[email-masked]] *On Behalf Of *Robert
> Raszuk
> *Sent:* Wednesday, January 27, 2021 8:03 PM
> *To:* James Guichard <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [spring] WG Adoption Call for
> draft-dong-spring-sr-for-enhanced-vpn
>
>
>
> All,
>
>
>
> [Jie] The resource reservation here refers to the data plane resources
> reserved for different virtual transport networks.
>
>
>
> [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
> [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.
>
>
>
> [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.
>
>
>
> [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.
>
>
>

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 28 Jan 2021 09:35:40 +0800

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

[email-masked] & [email-masked]
 
From: James Guichard
Date: 2021-01-27 19:46
To: [email-masked]
CC: [email-masked]
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn
Dear WG:

 
Thanks!
 
Jim, Bruno & Joel

---

From: <[email-masked]>
Date: Thu, 28 Jan 2021 14:09:11 +0800

Support as coauthor, the mechanism described in this document is important
for providing both 5G and business services in our network. 

Thanks.

B.R.

Zhu Yongqing

Chinatelecom

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

Dear WG:

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

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 28 Jan 2021 14:39:01 +0800

Support as a coauthor, and will work on it. Versatile SR is a good tool to meet enhanced VPN service requirements, and this doc has been improved after several updates, I think it is ready to be adopted.

Best Regards,
Zhenqiang Li

[email-masked]
 
From: James Guichard
Date: 2021-01-27 19:46
To: [email-masked]

 
Thanks!
 
Jim, Bruno & Joel

---

From: Huzhibo <[email-masked]>
Date: Thu, 28 Jan 2021 07:05:55 +0000

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

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

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 28 Jan 2021 08:52:41 +0000

Hi Robert,

From: Robert Raszuk [mailto:[email-masked]]
Sent: Thursday, January 28, 2021 1:01 AM
To: Dongjie (Jimmy) <[email-masked]>
Cc: James Guichard <[email-masked]>; [email-masked]; [email-masked]
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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

From: spring [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robert Raszuk
Sent: Wednesday, January 27, 2021 8:03 PM
To: James Guichard <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

All,

Best regards,
Jie

Thx,
R.

Thanks!

Jim, Bruno & Joel

---

From: Mach Chen <[email-masked]>
Date: Thu, 28 Jan 2021 09:43:34 +0000

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

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: "qinfengwei" <[email-masked]>
Date: Thu, 28 Jan 2021 17:44:26 +0800

Hi all,

         I support the adoption as coauthor. 

This document makes use of the resource-aware SIDs to build SR virtual
networks to meet different service requirements, which is a useful feature
to operators. 

 

Thanks,

Fengwei Qin

发件人: spring [mailto:[email-masked]] 代表 James Guichard
发送时间: 2021年1月27日 19:47
收件人: [email-masked]
抄送: [email-masked]
主题: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 28 Jan 2021 11:52:22 +0100

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) <[email-masked]> wrote:

> Hi Robert,
>
>
>
> *From:* Robert Raszuk [mailto:[email-masked]]
> *Sent:* Thursday, January 28, 2021 1:01 AM
> *To:* Dongjie (Jimmy) <[email-masked]>
> *Cc:* James Guichard <[email-masked]>; [email-masked];
> [email-masked]
> [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.
>
>
>

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 28 Jan 2021 20:13:49 +0800

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: [email-masked]

 
Thanks!
 
Jim, Bruno & Joel

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 28 Jan 2021 16:05:27 +0000

Hi Robert,

Sent: Thursday, January 28, 2021 6:52 PM

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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

From: Robert Raszuk [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, January 28, 2021 1:01 AM
To: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>
Cc: James Guichard <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Jie,

Hope this helps.

Best regards,
Jie

Many thx,
R.

All,

Best regards,
Jie

Thx,
R.

Thanks!

Jim, Bruno & Joel

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 28 Jan 2021 17:54:12 +0100

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) <[email-masked]> wrote:

> *Sent:* Thursday, January 28, 2021 6:52 PM
> [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.
>
>
>
> [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.
>
>
>
> [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.
>
>
>
> [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.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

---

From: Ran Pang(联通集团中国联通研究院-本部) <[email-masked]>
Date: Fri, 29 Jan 2021 03:37:06 +0000

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:[email-masked]>
Date: 2021-01-27 19:46
To: [email-masked]<mailto:[email-masked]>
CC: [email-masked]<mailto:[email-masked]>
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn
Dear WG:

Thanks!

Jim, Bruno & Joel

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

---

From: Zhuangshunwan <[email-masked]>
Date: Fri, 29 Jan 2021 10:05:27 +0000

Hi all,

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

Best Regards,
Shunwan

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 29 Jan 2021 16:34:30 -0500

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 <[email-masked]>
wrote:

> *From:* spring [mailto:[email-masked]] *On Behalf Of *James
> Guichard
> *Sent:* Wednesday, January 27, 2021 7:47 PM
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* [spring] WG Adoption Call for
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 30 Jan 2021 22:20:11 -0000

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 <[email-masked]> On Behalf Of James Guichard
Sent: 27 January 2021 11:47
To: [email-masked]
Cc: [email-masked]
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 31 Jan 2021 01:46:17 +0100

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 <[email-masked]> wrote:

> Thanks, Jim,
>
>
>
> I’ve been following the enhanced VPN work in TEAS and I see it as a key
> 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
> 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.
>
>
>
> *From:* spring <[email-masked]> *On Behalf Of *James Guichard
> *Sent:* 27 January 2021 11:47
> *To:* [email-masked]

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Sun, 31 Jan 2021 01:23:49 +0000

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:[email-masked]] On Behalf Of Robert Raszuk
Sent: Sunday, January 31, 2021 8:46 AM
To: Adrian Farrel <[email-masked]>
Cc: James Guichard <[email-masked]>; SPRING WG <[email-masked]>; [email-masked]
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.

   When

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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> On Behalf Of James Guichard
Sent: 27 January 2021 11:47
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 31 Jan 2021 12:06:23 -0000

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 <[email-masked]> 
Sent: 31 January 2021 00:46
To: Adrian Farrel <[email-masked]>
Cc: James Guichard <[email-masked]>; SPRING WG <[email-masked]>; [email-masked]
Subject: Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Hi Adrian,

   When

Best,
R.

On Sat, Jan 30, 2021 at 11:20 PM Adrian Farrel <[email-masked] <mailto:[email-masked]> > wrote:

Thanks, Jim,

Cheers,

Adrian

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

Dear WG:

Thanks!

Jim, Bruno & Joel

_______________________________________________
spring mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/spring

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 31 Jan 2021 14:08:08 +0100

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 <[email-masked]> 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 <[email-masked]>
> *Sent:* 31 January 2021 00:46
> *To:* Adrian Farrel <[email-masked]>
> *Cc:* James Guichard <[email-masked]>; SPRING WG <
> [email-masked]>; [email-masked]

---

From: Lou Berger <[email-masked]>
Date: Sun, 31 Jan 2021 17:10:50 +0000

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 <[email-masked]> 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 <[email-masked]<mailto:[email-masked]>> wrote:
Yeah, thanks Robert.

Cheers,
Adrian

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: 31 January 2021 00:46
To: Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Cc: James Guichard <[email-masked]<mailto:[email-masked]>>; SPRING WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Hi Adrian,

   When

Best,
R.

Cheers,
Adrian

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 31 Jan 2021 18:24:15 +0100

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 <[email-masked]> 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
> ------------------------------
>
>>> 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.
>>>
>>>
>>>
>>>
>>>

---

From: Takuya Miyasaka <[email-masked]>
Date: Mon, 1 Feb 2021 12:04:44 +0900

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:
> <https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/> 
> ending February 10^th 2021.
>
> 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
>
>

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 1 Feb 2021 01:46:33 -0500

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

-- 

*Gyan Mishra*