Agreed, DSCP was designed for DiffServ QoS marking to differentiate a limited number of service classes, it may not be suitable for non-Diffserv QoS scenarios.
Best regards, Jie From: Lsr [mailto:[email protected]] On Behalf Of Jeff Tantsura Sent: Friday, November 16, 2018 4:15 PM To: Robert Raszuk <[email protected]> Cc: [email protected]; Les Ginsberg (ginsberg) <[email protected]>; [email protected]; [email protected]; [email protected] Subject: Re: [Lsr] LSR: Using DSCP for path/topology selection Q Robert, match DSCP X set context Y or plane Z doesn’t make it any different. It has been used and abused in any possible way. If you want to write a BCP saying - use it for X/Y/Z but not for A/B/C because of.... - your business. As to using it someplace else - I’d expect respective documents to cover the use, flex-algo drafts as to your example. More fundamentally, (flex-algo is the best example) we have got context aware metadata in a form of: MPLS labels (SR SID), v6 EHs, plethora of overlay encaps, etc, with accompanying CP extensions that can be used to achieve exactly that. Now tell me - why again DSCP? P.S. in my previous life, working on 5G transport slicing (yes, i know :)) - i needed per slice identity over the common transport, we ended up looking at UDP port ranges, rather than DSCP - too few bits Cheers, Jeff On Thu, Nov 15, 2018 at 23:37 Robert Raszuk <[email protected]<mailto:[email protected]>> wrote: Jeff, > What architecture? > PBR is a form of: > match DSCP X > set next-hop Y > needs no interoperability... That's pretty narrow view. I could say the worst possible example :) You would have to either encapsulate or apply your sample config consistently on every hop. Brrrrr. To me DSCP can be used to map packets to different routing context, different plane or can be used as a parameter in flex-algorithm. Thx, R. On Fri, Nov 16, 2018 at 8:19 AM Jeff Tantsura <[email protected]<mailto:[email protected]>> wrote: Tony, What architecture? PBR is a form of: match DSCP X set next-hop Y needs no interoperability... If someone wants to describe how they use a particular vendor feature to solve a particular problem in a BCP, sure, the more BCPs - the better. Wrt using DSCP in routing decision process - it was a bad idea back then, hasn’t got any better now... besides - now we have got a toolbox that wasn’t available then. Cheers, Jeff On Thu, Nov 15, 2018 at 22:56 Tony Li <[email protected]<mailto:[email protected]>> wrote: On Nov 15, 2018, at 8:47 PM, Jeff Tantsura <[email protected]<mailto:[email protected]>> wrote: The question is really - what is here to standardize? There’s a fine architectural BCP here: this is how we are solving problem XYZ. Please don’t break this. Tony
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
