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 <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 <rob...@raszuk.net> > *Sent:* 31 January 2021 00:46 > *To:* Adrian Farrel <adr...@olddog.co.uk> > *Cc:* James Guichard <james.n.guich...@futurewei.com>; 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 <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 <spring-boun...@ietf.org> *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
