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

[Robert Raszuk <[e-mail]>]

> If we hopefully do not need to find solutions for IPv4

Well how much unpopular that may be I would not dismiss IPv4 that quickly
yet.

I am not sure who do you include under "operators" umbrella, but let's keep
in mind that there are enterprise networks where some form of end point
based  influencing packet paths is desired - yet no mpls, no sr and no even
IPv6 running on those end points any time soon.

Example: I need to provide dual streaming of identical unicast flows over
dis-joined paths between the application servers. Naturally it is internal
network so if I enable DSCP based mapping into disjointed topologies (of
any form) that solves my issue without any additional state imposed to the
apps or to the network.

Thx,
R.





On Fri, Nov 16, 2018 at 1:07 AM Toerless Eckert <[e-mail]> wrote:

> On Fri, Nov 16, 2018 at 12:28:27AM +0100, Robert Raszuk wrote:
> > 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.
>
> I think back when DSCP was selected for MTR in implementations, it was
> done so due to the absence of better options. But as i mentioned, the
> overloading of DSCP between QoS and routing made it (in my memory)
> undesirable to operators. And when designing new solutions with new QoS
> like in DetNet its yet a similar possible problem.
>
> If we hopefully do not need to find solutions for IPv4, i would rather
> like to see something like what SR did, e.g.: IPv6 header extension. These
> are AFAIK now also easily settable from linux programs (ok., maybe not
> yet from javascript). Or much easier of course the existing IPv6
> multi-addressing solutions where hosts can also lern semntics of these
> addresses. And map to diffeent flex-topologies instead of just
> multi-homing exit points (which i think was the main use-case so far).
>
> > 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.
>
> Sure, i am only talking about the solutions that tried to use DSCP for
> routing so far. I think those failed. And when other agree and we codify
> that, then that would not exclude the option for new work (like what
> Peter may have in mind) to superceed that recommendation.
>
> Cheers
>     Toerless
>
> > 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
> > >
>
> --
> ---
> [e-mail]
>