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

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 <adrian@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 <robert@raszuk.net>
> *Sent:* 31 January 2021 00:46
> *To:* Adrian Farrel <adrian@olddog.co.uk>
> *Cc:* James Guichard <james.n.guichard@futurewei.com>; SPRING WG <
> spring@ietf.org>; spring-chairs@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 <adrian@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 <spring-bounces@ietf.org> *On Behalf Of *James Guichard
> *Sent:* 27 January 2021 11:47
> *To:* spring@ietf.org
> *Cc:* spring-chairs@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
>
>