Re: [Lsr] LSR: Using DSCP for path/topology selection Q

[Robert Raszuk <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> On Behalf Of Toerless Eckert
> > > Sent: Wednesday, November 14, 2018 6:29 PM
> > > To: [e-mail]
> > > 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/lsr
> >
> > _______________________________________________
> > Lsr mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/lsr
>
> --
> ---
> [e-mail]
>
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>