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

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Mon, 19 November 2018 14:15 UTC

Return-Path: <ginsberg@cisco.com>
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 36808130DC8 for <lsr@ietfa.amsl.com>; Mon, 19 Nov 2018 06:15:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.971
X-Spam-Level:
X-Spam-Status: No, score=-14.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 jkHXHcFkrnvV for <lsr@ietfa.amsl.com>; Mon, 19 Nov 2018 06:15:13 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1034C124D68 for <lsr@ietf.org>; Mon, 19 Nov 2018 06:15:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8396; q=dns/txt; s=iport; t=1542636913; x=1543846513; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=K6DxPP/4IAeJXGugDFR4wr/tD/ro60CGXqb0ES2k3m0=; b=KDeHkV5zq9ZJA6z2hVNhd3hAuhcm9wBrCTZ1H3Bz7qlKaC70fOuFlemi Uya/qDN9cgdSubiNoT84uIfzbiuhNq+/lTrIAPV4gkY6QcfJTF0NDLrjq TtWLBqAzdFWOoeYCWQvDdKRVcalBbGAiY269r7WbaGJC2Z/vzOiwQYm05 c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ADAACexPJb/5ldJa1iGQEBAQEBAQEBAQEBAQcBAQEBAQGBUQQBAQEBAQsBggNmgQInCoNuiBiLfIINlzYUgWYLAQEYC4RJAheDVSI0CQ0BAwEBAgEBAm0cDIU8AQEBAQMBASEROgQTBAIBCBEEAQEBAgIjAwICAiULFAEICAIEARIIgxqCAQ+nB4EvihcFgQuKeheBQD+EI4MbAQECAYErARIBNoJtglcCiTqWNQkChniKJSCBWI8liWSDVYo2AhEUgScfOGRxcBU7gmyCJxeIXoU+QTEBjEiBH4EfAQE
X-IronPort-AV: E=Sophos;i="5.56,252,1539648000"; d="scan'208";a="488091997"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Nov 2018 14:15:08 +0000
Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id wAJEF5Sk008388 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 19 Nov 2018 14:15:07 GMT
Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 19 Nov 2018 08:15:04 -0600
Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1395.000; Mon, 19 Nov 2018 08:15:04 -0600
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: "Acee Lindem (acee)" <acee@cisco.com>, "Dongjie (Jimmy)" <jie.dong@huawei.com>, Toerless Eckert <tte@cs.fau.de>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] LSR: Using DSCP for path/topology selection Q
Thread-Index: AQHUfIsQfFyL7MO/SkqsJ4uRxzsGkaVQP6HwgAcH0YCAADCZAP//sSzw
Date: Mon, 19 Nov 2018 14:15:04 +0000
Message-ID: <b814e591db874328a6a90c69fd129de5@XCH-ALN-001.cisco.com>
References: <20181115022918.pfgcztognsjeb37v@faui48f.informatik.uni-erlangen.de> <4085ff6f77b5443ca4de319f9a909a01@XCH-ALN-001.cisco.com> <76CD132C3ADEF848BD84D028D243C927C2D2C4E3@NKGEML515-MBX.china.huawei.com> <38DB77CA-43CA-4DC6-9C16-3AD25ECB8426@cisco.com>
In-Reply-To: <38DB77CA-43CA-4DC6-9C16-3AD25ECB8426@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.42.169]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.24, xch-aln-014.cisco.com
X-Outbound-Node: rcdn-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/McgTfcMuxs20M05ZP3KyYPmjqpo>
Subject: Re: [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: Mon, 19 Nov 2018 14:15:15 -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


> -----Original Message-----
> From: Acee Lindem (acee)
> Sent: Monday, November 19, 2018 4:49 AM
> To: Dongjie (Jimmy) <jie.dong@huawei.com>; Les Ginsberg (ginsberg)
> <ginsberg@cisco.com>; Toerless Eckert <tte@cs.fau.de>; lsr@ietf.org
> 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)" <lsr-
> bounces@ietf.org on behalf of jie.dong@huawei.com> 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:lsr-bounces@ietf.org] On Behalf Of Les Ginsberg
> (ginsberg)
>     > Sent: Thursday, November 15, 2018 12:41 PM
>     > To: Toerless Eckert <tte@cs.fau.de>; lsr@ietf.org
>     > 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 <lsr-bounces@ietf.org> On Behalf Of Toerless Eckert
>     > > Sent: Wednesday, November 14, 2018 6:29 PM
>     > > To: lsr@ietf.org
>     > > 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
>     > > Lsr@ietf.org
>     > > https://www.ietf.org/mailman/listinfo/lsr
>     >
>     > _______________________________________________
>     > Lsr mailing list
>     > Lsr@ietf.org
>     > https://www.ietf.org/mailman/listinfo/lsr
> 
>     _______________________________________________
>     Lsr mailing list
>     Lsr@ietf.org
>     https://www.ietf.org/mailman/listinfo/lsr
>