Re: [tsvwg] CC/bleaching thoughts for draft-ietf-tsvwg-le-phb-04

Mikael Abrahamsson <swmike@swm.pp.se> Thu, 19 April 2018 06:38 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 3811B129C6D for <tsvwg@ietfa.amsl.com>; Wed, 18 Apr 2018 23:38:15 -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 s-qKGTomOHsV for <tsvwg@ietfa.amsl.com>; Wed, 18 Apr 2018 23:38:13 -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 03AD6124205 for <tsvwg@ietf.org>; Wed, 18 Apr 2018 23:38:12 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 133B3B0; Thu, 19 Apr 2018 08:38:08 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1524119888; bh=p4OeKUpCV17JUfJuixSOFc7FhtKQlkijAJdJYJjSJPw=; h=Date:From:To:Subject:In-Reply-To:References:From; b=pmpsQOfW7F999uC3I81PcsvVi0OUU+NDvrCe1wWIYyPOjgzHXmFmu632b79uzEjJv bmmsuxl0c2enlfdYA9spozUldViXgAUnemAUquNdiDW8DiBrijEVDeq7y5iqsFBNXz 6/bHnO1wyRkkFy41+T5fK7n7b+fQEAjOGHu/Mw9U=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0FCBEAF for <tsvwg@ietf.org>; Thu, 19 Apr 2018 08:38:08 +0200 (CEST)
Date: Thu, 19 Apr 2018 08:38:08 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: tsvwg@ietf.org
In-Reply-To: <LEJPR01MB10334C794BDA7E125917576E9CBC0@LEJPR01MB1033.DEUPRD01.PROD.OUTLOOK.DE>
Message-ID: <alpine.DEB.2.20.1804190826550.18650@uplift.swm.pp.se>
References: <20180406160344.xwfqgzhzfto56jhq@faui48f.informatik.uni-erlangen.de> <LEJPR01MB1033F43509F08701B2B5EA1D9CBF0@LEJPR01MB1033.DEUPRD01.PROD.OUTLOOK.DE> <82d646b7-d475-64d6-9f0b-f75e3daeeaca@gmail.com> <20180410090033.xkwsyfbfardg4pwx@faui48f.informatik.uni-erlangen.de> <ddac784e-3a88-c82d-0ed5-3816bffa2d72@gmail.com> <20180412023305.6nwyoway2m2exy2c@faui48f.informatik.uni-erlangen.de> <LEJPR01MB10334C794BDA7E125917576E9CBC0@LEJPR01MB1033.DEUPRD01.PROD.OUTLOOK.DE>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/qVVbS0sTn2S5uGxzVAaPTFbpa7Y>
Subject: Re: [tsvwg] CC/bleaching thoughts for draft-ietf-tsvwg-le-phb-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: Thu, 19 Apr 2018 06:38:15 -0000

On Thu, 12 Apr 2018, Ruediger.Geib@telekom.de wrote:

> advantage ("prove", not "believe").. Someone has to configure and 
> operate all this scheduling, and sometimes debugging is required. If 
> something is new, a basic standard set which is expandable to me is more 
> favorable, than a flexible (aka complex) toolset.

I've had some discussions with other people in the operational community, 
and multiple questions have come up.

1. If I do not bleach at all, should I do something based on this new 
draft? (there are people with MPLS networks that do their "bleaching" by 
assigning all traffic to BE on their transport (802.1p=0 / MPLS EXP=0), so 
they actually do not bleach customer diffserv in the IP header.

2. If I do bleach, should I remap CS1 to the new LE CP?

So basically, what should the setup be for ISPs for different scenarios? 
Towards the customer? Towards other ISPs?

There are two major camps out there that I see, those who just bleach 
everything, and those who do not bleach at all and are just transparent to 
customer traffic. We need guidance to both of these camps (I'm sure there 
are people doing different things as well, but if we give guidance to both 
of these cases then I think the people with hybrid setups can figure out 
what they need to do).

There are also two dimensions, what should they do with 
remapping/bleaching, and what should the PHB be (if any)? So let me write 
some suggestions and let's discuss.

So let's start with the operator that does no bleaching:

1. PHB should be that CS1 and LE is treated the same, ie lower priority 
than BE.
2. Do not bleach from customer.
3. Re-map CS1 to LE at edge towards other ISPs by default, but ISPs can 
agree on different behaviour.

For the ones that do bleaching:

>From customer/other ISP.
1. Remap CS1 to LE.
2. Do not bleach LE.
3. Bleach rest to BE.
4. PHB behaviour should be LE gets lower priority than BE.

Thoughts?

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