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

From: Toerless Eckert <[email-masked]>
Date: Thu, 15 Nov 2018 03:29:19 +0100

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 15 Nov 2018 04:41:06 +0000

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-masked]> On Behalf Of Toerless Eckert
> Sent: Wednesday, November 14, 2018 6:29 PM
> To: [email-masked]
> Subject: [Lsr] LSR: Using DSCP for path/topology selection Q
> 
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: Peter Psenak <[email-masked]>
Date: Thu, 15 Nov 2018 08:21:53 +0100

Toerless,

> later work like flex-Algos ?

no, but if someone wanted to do so it can.
draft-ietf-lsr-flex-algo does not say anything about DHCP.

thanks,
Peter

> .

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 16 Nov 2018 00:22:23 +0100

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).

-- 
---
[email-masked]

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 16 Nov 2018 00:28:27 +0100

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-masked]> wrote:

> > What leads you to believe that any of the MT specifications you mention
> say anything normative about DSCP and topologies??
> >
> > 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.
> >

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 16 Nov 2018 01:07:08 +0100

> 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).

> 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

-- 
---
[email-masked]

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 16 Nov 2018 01:24:55 +0100

> 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 <[email-masked]> wrote:

> > > > RFC 7722 also mentions DSCP as an example, but there is a statement
> in
> > > Section 3:
> > > >
> > > > "It is assumed, but
> > > > IGP WGs have never attempted to recommend (let alone normatively
> define)
> > > any relationship between DSCP and MT.
> > > >
> > > > ???
> > > >
> > > >    Les
> > > >
> > > > > If there could be rough consensus that this is in general a bad
> idea,
> > > i wonder

---

From: Rob Shakir <[email-masked]>
Date: Thu, 15 Nov 2018 16:47:26 -0800

> Peter may have in mind) to superceed that recommendation.

A number of networks on which I have worked have used DSCP-based tunnel
selection to choose between RSVP-TE LSPs. This essentially is different
routing based on DSCP, which seems to be something that you're trying to
cover -- is that correct?

If so, given that these are running in real networks, I find it hard to
conclude that any IETF standard should declare them as failed.

r.

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 16 Nov 2018 11:47:55 +0700

+1 Rob
I have seen number of MBH networks using DSCP to change forwarding - AKA PBR.

The question is really - what is here to standardize?

RSVP-TE use cases mentioned by Rob (CBTS/PBTS in IOS realm) are classical examples of Policy Based Routing and as such are subject to implementation details, not standardization.

Am I missing something?

Regards,
Jeff

> On Nov 16, 2018, at 07:47, Rob Shakir <[email-masked]> wrote:
> 
> A number of networks on which I have worked have used DSCP-based tunnel selection to choose between RSVP-TE LSPs. This essentially is different routing based on DSCP, which seems to be something that you're trying to cover -- is that correct?
> 
> If so, given that these are running in real networks, I find it hard to conclude that any IETF standard should declare them as failed.
> 
> r.
> 
>

---

From: Tony Li <[email-masked]>
Date: Thu, 15 Nov 2018 22:55:56 -0800

> On Nov 15, 2018, at 8:47 PM, Jeff Tantsura <[email-masked]> wrote:
> 

There’s a fine architectural BCP here: this is how we are solving problem XYZ.  Please don’t break this.

Tony

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 15 Nov 2018 23:18:50 -0800

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

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 16 Nov 2018 08:37:34 +0100

Jeff,

> 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.

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 16 Nov 2018 00:14:45 -0800

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

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 16 Nov 2018 11:40:36 +0100

Rob,

Thats actually a good example, i had forgotten about that one.
This is also a lot more scalable than MTR given how (if i
remember correctly, you would only have  O(#DSCP,#egres-PE)
entries.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 16 Nov 2018 11:49:59 +0100

> looking at UDP port ranges, rather than DSCP - too few bits

Right. The main issue is when you start requiring new/more DSCP for
a purpose that is not QoS. Which by itself is not a good hard
definition, but at least a starting point.

Cheers
    Toerless

> >> hasn???t got any better now... besides - now we have got a toolbox that
> >> wasn???t available then.
> >>
> >> Cheers,
> >> Jeff
> >>> There???s a fine architectural BCP here: this is how we are solving
> >>> problem XYZ.  Please don???t break this.
> >>>
> >>> Tony
> >>>
> >>>

-- 
---
[email-masked]

---

From: Uma Chunduri <[email-masked]>
Date: Sat, 17 Nov 2018 01:35:30 +0000

A quick comment below –

Cheers & have a great weekend!

--
Uma C.

From: Lsr [mailto:[email-masked]] On Behalf Of Jeff Tantsura
Sent: Friday, November 16, 2018 12:15 AM
To: Robert Raszuk <[email-masked]>
Cc: [email-masked]; Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
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.

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

[Uma]: +1 and was part of that previous life. May be it should be called as “4G slicing” and it’s deployed in few places.  Any ways it’s all about how to map the incoming traffic at PE (in the above case at CSR/P-GW) to a particular LSP. I didn’t see any requirement which needs an MTR/flex-algo aka light-weight-sub-topology which needs to be built based on DSCP.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 19 Nov 2018 09:41:40 +0000

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

Sent: Friday, November 16, 2018 4:15 PM

Robert,

match DSCP X

Cheers,
Jeff
On Thu, Nov 15, 2018 at 23:37 Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
Jeff,

> 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-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>> wrote:

On Nov 15, 2018, at 8:47 PM, Jeff Tantsura <[email-masked]<mailto:[email-masked]>> wrote:

Tony

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 19 Nov 2018 09:55:17 +0000

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

> From: Lsr [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
> Sent: Thursday, November 15, 2018 12:41 PM
> To: Toerless Eckert <[email-masked]>; [email-masked]
> What leads you to believe that any of the MT specifications you mention say
> anything normative about DSCP and topologies??
> 
> 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.
> 
> > 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:
> >

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 19 Nov 2018 12:49:14 +0000

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-masked] on behalf of [email-masked]> wrote:

    Hi Les,

    
    Best regards,
    Jie

---

From: <[email-masked]>
Date: Mon, 19 Nov 2018 13:08:52 -0000

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-masked]> On Behalf Of Acee Lindem (acee)
Sent: 19 November 2018 12:49
To: Dongjie (Jimmy) <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; Toerless Eckert <[email-masked]>; [email-masked]
Subject: Re: [Lsr] LSR: Using DSCP for path/topology selection Q

Hi Jie,

Thanks,
Acee

    Hi Les,

    
    Best regards,
    Jie

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 19 Nov 2018 14:15:04 +0000

Acee -

To clarify/correct both my post and yours...

RFC 4915 does mention DSCP - but it does so in the context of a reference to OSPF base specification (RFC 1583 at the time). The full relevant quote from Section 1.1:

" 1.  With TOS routing [TOS-OSPF], the TOS or Diffserv Code Point
       (DSCP) in the IP header is mapped directly to the corresponding
       OSPF SPF calculation and routing table.  This limits the number
       and definition of the topologies to the 16 TOS values specified
       in Section 12.3 of [TOS-OSPF].  With Multi-Topology routing, the
       classification of what type of traffic maps to which topology is
       not within the scope of this document."

The last sentence of the paragraph clearly states that no normative statement is being made as regards the use of DSCP (or any other classification mechanism) and the topologies defined by MT.

   Les

> From: Acee Lindem (acee)
> Sent: Monday, November 19, 2018 4:49 AM
> To: Dongjie (Jimmy) <[email-masked]>; Les Ginsberg (ginsberg)
> <[email-masked]>; Toerless Eckert <[email-masked]>; [email-masked]
> 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)" <lsr-
> [email-masked] on behalf of [email-masked]> wrote:
> 
>     Hi Les,
> 
>     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
> 
> say
> "could"
>     > RFC 7722 also mentions DSCP as an example, but there is a statement in
> Section
>     > 3:
>     >
>     > "It is assumed, but

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 19 Nov 2018 15:11:51 +0000

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-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Monday, November 19, 2018 3:08:52 PM
To: 'Acee Lindem (acee)'; 'Dongjie (Jimmy)'; 'Les Ginsberg (ginsberg)'; 'Toerless Eckert'; [email-masked]
Subject: Re: [Lsr] LSR: Using DSCP for path/topology selection Q

Adrian

-----Original Message-----
From: Lsr <[email-masked]> On Behalf Of Acee Lindem (acee)
Sent: 19 November 2018 12:49
To: Dongjie (Jimmy) <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; Toerless Eckert <[email-masked]>; [email-masked]
Subject: Re: [Lsr] LSR: Using DSCP for path/topology selection Q

Hi Jie,

Thanks,
Acee

    Hi Les,

    Best regards,
    Jie

___________________________________________________________________________

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.
___________________________________________________________________________