Re: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-dscp-registry-04

Mikael Abrahamsson <swmike@swm.pp.se> Tue, 08 May 2018 09:14 UTC

Return-Path: <swmike@swm.pp.se>
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 A7D1B126D0C for <tsvwg@ietfa.amsl.com>; Tue, 8 May 2018 02:14:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 fQ0N1KyW981x for <tsvwg@ietfa.amsl.com>; Tue, 8 May 2018 02:14:01 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 196071201F2 for <tsvwg@ietf.org>; Tue, 8 May 2018 02:14:01 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id AB777B1; Tue, 8 May 2018 11:13:58 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1525770838; bh=r+nJqn0vCeYnBbiWyUPEEbndSExARXjNe8OL3xVBnMA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=bLaxRyE1NHfmRrJ9UT/vzJ6YAXHj5mSJ1OIiIhdLkIWeajIYmn0rQljgAlI0MSkAy FJZDvDIxRFf7C4IOaLgMgt+g51Ci1sE4Tyc3rBL/CB05iK6eivLXVi6QsQrsq5bYkw nq0ZmxoeQ33up5loJa30uC/g/iVkKv+CTUgHwrGA=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A6DEFB0; Tue, 8 May 2018 11:13:58 +0200 (CEST)
Date: Tue, 08 May 2018 11:13:58 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
cc: "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, "tsvwg@ietf.org" <tsvwg@ietf.org>
In-Reply-To: <DB5PR0301MB1909E703CA7C90CBB6E0D5259D9A0@DB5PR0301MB1909.eurprd03.prod.outlook.com>
Message-ID: <alpine.DEB.2.20.1805081051440.17103@uplift.swm.pp.se>
References: <DB5PR0301MB1909E703CA7C90CBB6E0D5259D9A0@DB5PR0301MB1909.eurprd03.prod.outlook.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/TL64xHtro-S9NsGBCGnkOe6LyUI>
Subject: Re: [tsvwg] Doubts regarding motivation of draft-ietf-tsvwg-iana-dscp-registry-04
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: Tue, 08 May 2018 09:14:04 -0000

On Tue, 8 May 2018, Alexander Vainshtein wrote:

> Godred and all,
> I have looked up the draft<https://tools.ietf.org/html/draft-ietf-tsvwg-iana-dscp-registry-04>, and I have doubts regarding validity of its motivation.
> The draft says - correctly -that 22 out of 32 values in Pool 1 of the DSCP code points have been already assigned, therefore it considers this pool as nearly exhausted.
>
> What the draft does not say that, out of these 22 assignments, 2o have been done in 1998 and one - in 1999. Only one assignment has been requested in the past 19 years, and no assignments have been requested after 2010.
>
> At this rate my estimate is that Pool 1 would suffice for the next 50+ years without its exhaustion becoming an issue. So why should the IETF do anything now?

The primary reason for this is not because pool 1 is becoming exhausted, 
but the fact that we want to use 000001 for LE (for practical/legacy 
reasons, not because pool 1 is becoming exhausted), so the suggestion is 
therefore to make Pool 3 have a different allocation policy so we can put 
in a standards track PHB LE RFC for 000001.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se