Hey Toerless, Please observe that DSCP based steering may be very useful vehicle for end hosts/applications influencing how their packets are transported.
So instead of closing that option I recommend we at least take a good look at what alternative mechanism exists. And btw I read Peter's note as possibility (or invitation) to define algorithm which takes into account DSCP rather then a announcement that this is not there and it should never be. Cheers, R. On Fri, Nov 16, 2018 at 12:22 AM Toerless Eckert <[email protected]> wrote: > > Thanks, Les, Peter > > So... is there any opinion about creating a normative or BCP > recommendation to > not use DSCP to distinguish topologies/flex-algos ? Mabybe this would > not be appropriate for LSR, but TSVWG, but i think it would be > participants in LSR that would know if there is actually still any > customer demand for this option. > > Cheers > Toerless > > P.S.: Context of the email is DetNet trying to define what a DetNet flow > is and currently this includes the thinking that DetNet flows could be > 6-tuple flows including DSCP because different DSCP could be routed > differently in the network via MTR, and that concept IMHO would just > result in making a foal (DetNet) a lot more complex because of a dead > horse (DSCP MTR). > > On Thu, Nov 15, 2018 at 04:41:06AM +0000, Les Ginsberg (ginsberg) wrote: > > Toerless - > > > > It's pretty hard to understand the context for your email. > > > > What leads you to believe that any of the MT specifications you mention > say anything normative about DSCP and topologies?? > > > > RFC4915 does not mention DSCP at all - but does make the statement: > > > > https://tools.ietf.org/html/rfc4915#section-3.8 > > "It is outside of the scope of this document to specify how the > > information in various topology specific forwarding structures are > > used during packet forwarding or how incoming packets are associated > > with the corresponding topology." > > > > RFC 5120 does mention DSCP, but only as an example of something that > "could" be used to determine on what topology a packet should be forwarded. > > > > RFC 7722 also mentions DSCP as an example, but there is a statement in > Section 3: > > > > "It is assumed, but > > outside the scope of this specification, that the network layer is > > able to choose which topology to use for each packet" > > > > IGP WGs have never attempted to recommend (let alone normatively define) > any relationship between DSCP and MT. > > > > ??? > > > > Les > > > > > -----Original Message----- > > > From: Lsr <[email protected]> On Behalf Of Toerless Eckert > > > Sent: Wednesday, November 14, 2018 6:29 PM > > > To: [email protected] > > > Subject: [Lsr] LSR: Using DSCP for path/topology selection Q > > > > > > Whats the current best guidance on using DSCP for selection of path, > > > specifically for selection of topology with MTR (RFCs 4915, 5120, > 7722) ? > > > > > > My understanding from history is that this looked like a good idea > > > to customers first, but when implementations became available, > > > customers really did not want to implement it because of the > overloading > > > of DSCP between QoS and routing and the resulting management > > > complexity. > > > > > > Has the idea of using DSCP for path selection been re-introduced in any > > > later work like flex-Algos ? > > > > > > If there could be rough consensus that this is in general a bad idea, > i wonder > > > if it would be appropriate to have a short normative document from LSR > > > defining that the use of DSCP for topology selection is historic and > > > not recommended anymore and make this an update to above three RFCs, > > > maybe also pointing out that there are other methods to select a > > > topology and those remain viable: > > > > > > I specifically would not like to see the actual MTR RFCs to be changed > > > in status, because MTR actually does work quite well and is supported > > > in products and deployed with IP multicast, even with multiple > > > topologies for IP multicast in live-live scenarios. > > > > > > Thanks! > > > Toerless > > > > > > _______________________________________________ > > > Lsr mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/lsr > > > > _______________________________________________ > > Lsr mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/lsr > > -- > --- > [email protected] > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
