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

Toerless Eckert <tte@cs.fau.de> Thu, 15 November 2018 02:29 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECCDE130E26 for <lsr@ietfa.amsl.com>; Wed, 14 Nov 2018 18:29:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.952
X-Spam-Level:
X-Spam-Status: No, score=-3.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Dt6YgOYKJwq for <lsr@ietfa.amsl.com>; Wed, 14 Nov 2018 18:29:23 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D711130E1C for <lsr@ietf.org>; Wed, 14 Nov 2018 18:29:23 -0800 (PST)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 47B32548040 for <lsr@ietf.org>; Thu, 15 Nov 2018 03:29:19 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 36078440210; Thu, 15 Nov 2018 03:29:19 +0100 (CET)
Date: Thu, 15 Nov 2018 03:29:19 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: lsr@ietf.org
Message-ID: <20181115022918.pfgcztognsjeb37v@faui48f.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/N5omUnZ-VA0sP7JXCJD2qgLGi10>
Subject: [Lsr] LSR: Using DSCP for path/topology selection Q
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Nov 2018 02:29:25 -0000

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