Hi all, I concur with Adrian: polucy-based routing is quite different from MTR that uses DSCP to map a packet to a specifuc totology and/or from using DSCP for selecting a dedicated queue for a packet.
My 2c. Thumb typed by Sasha Vainshtein ________________________________ From: Lsr <[email protected]> on behalf of [email protected] <[email protected]> Sent: Monday, November 19, 2018 3:08:52 PM To: 'Acee Lindem (acee)'; 'Dongjie (Jimmy)'; 'Les Ginsberg (ginsberg)'; 'Toerless Eckert'; [email protected] Subject: Re: [Lsr] LSR: Using DSCP for path/topology selection Q I think that this thread keeps mixing concepts. As Acee says, using DSCP to select a topology is feasible. Similarly, using DSCP to govern access to / usage of resources is a thing (as Jeff said for slicing, and as other have said for queues, etc.) But that is a far thing from policy-based routing which is, erm, something else altogether. Adrian -----Original Message----- From: Lsr <[email protected]> On Behalf Of Acee Lindem (acee) Sent: 19 November 2018 12:49 To: Dongjie (Jimmy) <[email protected]>; Les Ginsberg (ginsberg) <[email protected]>; Toerless Eckert <[email protected]>; [email protected] Subject: Re: [Lsr] LSR: Using DSCP for path/topology selection Q Hi Jie, Actually, the usage of DSCP to steer traffic onto a topology was specified in RFC 4915. However, this required an ecosystem to provision and mark traffic as it ingressed the OSPF MT routing domain (which was not specified). We (Cisco) had an implementation in the mid-2000s but it really didn't get a lot of deployment or implementation by other vendors. Thanks, Acee On 11/19/18, 4:55 AM, "Lsr on behalf of Dongjie (Jimmy)" <[email protected] on behalf of [email protected]> wrote: Hi Les, Thanks for the summary and citations. To my understanding, although DSCP based steering could be used in multi-topology scenarios, such usage is not defined in IETF specifications. Actually there can be many ways of choosing which topology is used for the forwarding of a particular packet. Thus the relationship between DSCP and MT is not that tightly coupled. Best regards, Jie > -----Original Message----- > From: Lsr [mailto:[email protected]] On Behalf Of Les Ginsberg (ginsberg) > Sent: Thursday, November 15, 2018 12:41 PM > To: Toerless Eckert <[email protected]>; [email protected] > Subject: Re: [Lsr] LSR: Using DSCP for path/topology selection Q > > 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 _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr ___________________________________________________________________________ This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___________________________________________________________________________
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
