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

"Dongjie (Jimmy)" <jie.dong@huawei.com> Mon, 19 November 2018 09:41 UTC

Return-Path: <jie.dong@huawei.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 4E81B128CE4 for <lsr@ietfa.amsl.com>; Mon, 19 Nov 2018 01:41:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 sgoY7xsspW4s for <lsr@ietfa.amsl.com>; Mon, 19 Nov 2018 01:41:47 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DEE11286D9 for <lsr@ietf.org>; Mon, 19 Nov 2018 01:41:47 -0800 (PST)
Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 109848ADE6A89; Mon, 19 Nov 2018 09:41:43 +0000 (GMT)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 19 Nov 2018 09:41:44 +0000
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0415.000; Mon, 19 Nov 2018 17:41:41 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: Jeff Tantsura <jefftant.ietf@gmail.com>, Robert Raszuk <robert@raszuk.net>
CC: "tte@cs.fau.de" <tte@cs.fau.de>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "rjs@rob.sh" <rjs@rob.sh>, "tony1athome@gmail.com" <tony1athome@gmail.com>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] LSR: Using DSCP for path/topology selection Q
Thread-Index: AQHUfIsVtb1RI/dr5kG5905Pe7jBEaVPu6UAgAE5SICAAAGygIAACs8AgAALQgCAAEMxgIAAI8QAgAAGZgCAAAU8AIAACmSAgAVVLXA=
Date: Mon, 19 Nov 2018 09:41:40 +0000
Message-ID: <76CD132C3ADEF848BD84D028D243C927C2D2C4B5@NKGEML515-MBX.china.huawei.com>
References: <20181115022918.pfgcztognsjeb37v@faui48f.informatik.uni-erlangen.de> <4085ff6f77b5443ca4de319f9a909a01@XCH-ALN-001.cisco.com> <20181115232222.psroxxfwhxrdscns@faui48f.informatik.uni-erlangen.de> <CAOj+MMHLO+QjjSh-g4QWBqht3RZKrmxMDjtyhTZQhy0SJ3uojQ@mail.gmail.com> <20181116000708.sl6htsevtalu44wx@faui48f.informatik.uni-erlangen.de> <CAHxMRebnhYbwBED8Us2ZR7ikJHHs6VBR6ZLy7cCqfyDJ6XVUAw@mail.gmail.com> <5785DD05-7B7E-4AD5-9B9D-D4DB80B14B16@gmail.com> <AB0CF38C-2372-42A2-BCD0-B3D0E5692E1E@gmail.com> <CAFAzdPUS-+8JKEqfA82Xp9PwgqJ8C2TkZWErf-BH4Kw3Tvkb6g@mail.gmail.com> <CAOj+MMFatF=_E_EqfX4fg8Hgop1G5AcA2Z5SfbU7GU5=jxdjSA@mail.gmail.com> <CAFAzdPWz5DurwxtuAW1vqXft9VovqqmVw1mKif7kM8Z7XzNT5A@mail.gmail.com>
In-Reply-To: <CAFAzdPWz5DurwxtuAW1vqXft9VovqqmVw1mKif7kM8Z7XzNT5A@mail.gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.130.151.75]
Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C927C2D2C4B5NKGEML515MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/Z2P2vasJr1dlelhxEp6rtFY213Y>
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 09:41:49 -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

From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Jeff Tantsura
Sent: Friday, November 16, 2018 4:15 PM
To: Robert Raszuk <robert@raszuk.net>
Cc: tte@cs.fau.de; Les Ginsberg (ginsberg) <ginsberg@cisco.com>; rjs@rob.sh; tony1athome@gmail.com; lsr@ietf.org
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.

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
On Thu, Nov 15, 2018 at 23:37 Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>> wrote:
Jeff,

> What architecture?
> PBR is a form of:
> match DSCP X
> set next-hop Y
> 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 <jefftant.ietf@gmail.com<mailto:jefftant.ietf@gmail.com>> 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 <tony1athome@gmail.com<mailto:tony1athome@gmail.com>> wrote:



On Nov 15, 2018, at 8:47 PM, Jeff Tantsura <jefftant.ietf@gmail.com<mailto:jefftant.ietf@gmail.com>> wrote:

The question is really - what is here to standardize?


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

Tony