Thanks. We are mostly in agreement.

Regards,
Tarek

On 2/2/21, 4:36 AM, "spring on behalf of Robert Raszuk" 
<spring-boun...@ietf.org<mailto:spring-boun...@ietf.org> on behalf of 
rob...@raszuk.net<mailto:rob...@raszuk.net>> wrote:

Hi Terek,

Sure that MPLS supports diff-serve from day one. No one ever stated that it 
does not. In fact if you go back to one of the messages I explicitly stated 
this already and even encourage its use to the problem at hand.

But the label inferred class of service or such carried in EXP bits is really 
nothing close to per individual LSP resource reservations some imagine is 
taking place.

So by all means using QoS in MPLS networks - both MPLS TE or LDP is a good 
thing. It is just from practical point (limited number of classes) not per 
customer or per LSP-TE reservation of any sort. Another problem arises that to 
do it well you must use central controller which would be controlling all 
ingress points to your network for this class of service. It is important to 
also note that this class of service must have priority over *any* other 
traffic type - including control plane itself. Needless to say you also need to 
inspect and rewrite if needed any other non compliant traffic attempting to 
also be placed in this type of PQ.

I have a feeling that some people in the industry think that they can bring 
back TDM paradigm into connectionless IP transport. This is easy to do in 
SDH/SONET layers ... not above it when all traffic is squeezed into shared 
space containers. Sure at most we could say F/C class goes in/out first at each 
hop, but that's about it.

Best,
R.


On Tue, Feb 2, 2021 at 5:48 AM Tarek Saad 
<ts...@juniper.net<mailto:ts...@juniper.net>> wrote:
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" 
<spring-boun...@ietf.org<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 
<lber...@labn.net<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 
<rob...@raszuk.net<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 
> <adr...@olddog.co.uk<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 <rob...@raszuk.net<mailto:rob...@raszuk.net>>
Sent: 31 January 2021 00:46
To: Adrian Farrel <adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>>
Cc: James Guichard 
<james.n.guich...@futurewei.com<mailto:james.n.guich...@futurewei.com>>; SPRING 
WG <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

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<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 <spring-boun...@ietf.org<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


Juniper Business Use Only


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

Reply via email to