Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB?

<Ruediger.Geib@telekom.de> Wed, 02 August 2017 08:48 UTC

Return-Path: <Ruediger.Geib@telekom.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61FA131D2F for <tsvwg@ietfa.amsl.com>; Wed, 2 Aug 2017 01:48:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de
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 HcAMJ1N5YsPA for <tsvwg@ietfa.amsl.com>; Wed, 2 Aug 2017 01:48:31 -0700 (PDT)
Received: from mailout13.telekom.de (MAILOUT13.telekom.de [80.149.113.181]) (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 74940131C9D for <tsvwg@ietf.org>; Wed, 2 Aug 2017 01:48:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1501663710; x=1533199710; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/Y3Lcmd35pzlA1CNCGQ8SW9XMoggCpZYrk67l0RRsJE=; b=yqrbg4qZFfs24EE7brbPfyb6Xi7x/YNnQ7BIQATXPkd0ShOhCj6yfhS3 gOL+Ctd+M4+p+OzRCbCjK/6X09vw5+On5yvridOcykSLfADgjBmfAKxOd CqbeXWLblhT8i4aAxvObGF/p4P7Brn/G9hn8pqvjvk/a9MWci6tuZK7PB jsKIlaEUA1XTv8lgH3BsDECr5oFBscvFQImpl3BbbytYp+y3dfKAEYp4A yk2lEwGnimoRietXGP5WT9fnRFYVM73uSGbntlJTf5ruTlzKiknbVNRmo t5mpc3TdARalYUyD2bN+vaSL4fMDXUQnpAox+W23Sorm+wL83xV2j7tdi w==;
Received: from q4de8psa04t.blf.telekom.de ([10.151.13.130]) by MAILOUT11.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Aug 2017 10:48:28 +0200
X-IronPort-AV: E=Sophos;i="5.41,310,1498514400"; d="scan'208";a="710715539"
Received: from he105658.emea1.cds.t-internal.com ([10.169.118.88]) by Q4DE8PSA04V.blf.telekom.de with ESMTP/TLS/AES256-SHA; 02 Aug 2017 10:48:19 +0200
Received: from HE105654.EMEA1.cds.t-internal.com (10.169.118.86) by HE105658.emea1.cds.t-internal.com (10.169.118.88) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 2 Aug 2017 10:48:14 +0200
Received: from HE105654.EMEA1.cds.t-internal.com ([fe80::44ef:d9e7:d2ca:97f6]) by HE105654.emea1.cds.t-internal.com ([fe80::44ef:d9e7:d2ca:97f6%26]) with mapi id 15.00.1263.000; Wed, 2 Aug 2017 10:48:14 +0200
From: Ruediger.Geib@telekom.de
To: roland.bless@kit.edu
CC: tsvwg@ietf.org
Thread-Topic: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB?
Thread-Index: AQHS9w2o4prCs8a2Uk2hjK9vt7Sn6aJIEb4AgAAFrYCAAJ4pgIACg0cAgACbsYCAAAkhgIAADh6AgAAYQgCAAJFhAIAA00EAgAjBVYCAAK90gIAXOLgQgAAbQwCAADlBgIAAr3OAgAAl4JD///thAIAAwlOAgAC76ICAACgpAA==
Date: Wed, 02 Aug 2017 08:48:14 +0000
Message-ID: <b37683a8bca74999a81d359fb933e9b1@HE105654.emea1.cds.t-internal.com>
References: <595F4D19.9030502@erg.abdn.ac.uk> <011e5fb5-6c83-bb38-e2cb-7fced2cb774a@kit.edu> <595F6F4F.20005@erg.abdn.ac.uk> <a97e114c-ca99-f0a3-76e6-784377a5fbe3@gmail.com> <C02205CB-7324-4C06-82CE-C8DA7D686F48@jisc.ac.uk> <74717821-30ae-203b-197b-2455cbf9d4a3@gmail.com> <66425AFB-A929-4A91-90F8-432F4FAE0520@jisc.ac.uk> <daf2d2c4-8a64-7cb3-ac80-3a46903f58f0@kit.edu> <b242faea-a3ca-6d5f-2eb3-85a9a08a6ea9@gmail.com> <59633402.9020907@erg.abdn.ac.uk> <d193232f-f28f-02a2-1171-53d6f0d4bf7b@gmail.com> <CE03DB3D7B45C245BCA0D243277949362FB76819@MX307CL04.corp.emc.com> <50f4b157-425e-a2cc-a924-5dd02345adef@gmail.com> <505f03a57bd4481b832bc22340c37316@HE105654.emea1.cds.t-internal.com> <BCF1D707-549C-4F6A-B493-BB5CA24A3E1F@gmail.com> <7af582df-6c55-a835-8156-50c9f322e4e9@gmail.com> <5980256F.7060100@erg.abdn.ac.uk> <aae889c27e49429db619d71b8c41a76b@HE105654.emea1.cds.t-internal.com> <edc7735e-d230-b9d1-aa19-6c774d987a91@kit.edu> <c5fce6b5-53b3-0203-211f-a8cd1a484250@gmail.com> <ad35805e-d2e2-6c59-dbc8-435410dbc440@kit.edu>
In-Reply-To: <ad35805e-d2e2-6c59-dbc8-435410dbc440@kit.edu>
Accept-Language: en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.157.160.39]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/kwe8RIuKyQ-CfqsEfDURvt6p8F4>
Subject: Re: [tsvwg] COMMENT PLEASE: Which DSCP value should we use for LE PHB?
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Aug 2017 08:48:33 -0000

Hi Roland,

in an MPLS domain, one generally may assign a bunch of DSCP to a 
single Treatment Aggregate / PHB. That I think is quite useful. 
Unfortunately the top label is removed before the last MPLS 
domain router is reached. Then an unknown and not re-marked 
DSCP is not acceptable. Hence your guidance below isn't applicable in 
all networks.

There is a fairly simple and useful option allowing to combine Treatment 
Aggregates, Diffserv forwarding across an MPLS domain and 
maintenance of multiple DSCP. Per Treatment Aggregate:
- classify DSCPs by bit-mask at ingress.
- re-mark DSCPs by bit mask at ingress.
- Diffserv forwarding by Treatment Aggregate
- classify and forward by individual DSCP at the egress (if desired)
- same holds for next domain

The other simple option I see without bit mask based re-mark is, 
again per Treatment Aggregate:
- classify DSCPs by bit-mask at ingress.
- re-mark to _a single DSCP_ at ingress.
- Diffserv forwarding by Treatment Aggregate 
- classify and forward by this single DSCP at the egress
- same holds for next domain

I prefer a simple solution (and a standardized one, if possible). 

Of course it is technically possible to set up and maintain per DSCP to 
PHB and individual DSCP re-mark tables, customized for each 
interconnection. Interconnection DSCPs are not standardized.
Many carriers operate multiple interconnections. 

Regards, 

Ruediger

>> IMHO it shouldn't be difficult to have a mapping table from each DSCP 
>> to a PHB. The mapping table should initially only contain mappings to 
>> the default PHB (no need to remark anything then).
>> Configuring DSCP remarking by using bitmasks is IMHO not RFC2474 
>> compliant and a broken concept causing the trouble we just ran into.
> 
> And you shouldn't fix broken products by fiddling with a standard; 
> that rewards the makers of broken products.

+1

Regards,
 Roland