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

"Bless, Roland (TM)" <roland.bless@kit.edu> Thu, 19 April 2018 08:54 UTC

Return-Path: <roland.bless@kit.edu>
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 2F60212D7ED for <tsvwg@ietfa.amsl.com>; Thu, 19 Apr 2018 01:54:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 n5ikM2s6ygsu for <tsvwg@ietfa.amsl.com>; Thu, 19 Apr 2018 01:54:41 -0700 (PDT)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 7B25B126CC4 for <tsvwg@ietf.org>; Thu, 19 Apr 2018 01:54:41 -0700 (PDT)
Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1f95Kx-0001ta-5Q; Thu, 19 Apr 2018 10:54:39 +0200
Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 212184200E0; Thu, 19 Apr 2018 10:54:39 +0200 (CEST)
To: Mikael Abrahamsson <swmike@swm.pp.se>, tsvwg@ietf.org
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> <alpine.DEB.2.20.1804190826550.18650@uplift.swm.pp.se>
From: "Bless, Roland (TM)" <roland.bless@kit.edu>
Organization: Institute of Telematics, Karlsruhe Institute of Technology
Message-ID: <d8c2ca1b-aa78-9f96-2fd8-e089cf4fb5b3@kit.edu>
Date: Thu, 19 Apr 2018 10:54:39 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.20.1804190826550.18650@uplift.swm.pp.se>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1524128079.281814069
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/CGFzGZLsXAfNg2it6XZMvunILfo>
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 08:54:44 -0000

Hi Mikael,

see inline.

Am 19.04.2018 um 08:38 schrieb Mikael Abrahamsson:
> 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.

Thanks, this is really valuable...

> 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.

Ok, so _bleaching_ for me would be to set the DSCP to 0. The subsequent
domains have no clue then that it was actually a different PHB before
(yes, cross DS domain semantics of PHBs have to be negotiated according
to the Diffserv architecture, but let's assume that we use a standard
DSCP). So, yes domains could put the LE traffic into their BE aggregate,
but then the whole advantage of LE for the provider is gone. The current
draft recommends to keep the LE DSCP in case one maps the LE PHB into
the BE PHB, so that subsequent domains can at least treat it as intended
again.

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

This is a bit confusing. What do you mean by "bleach" here, treat
LE as BE? Remarking of DSCPs is a somewhat orthogonal problem since
Diffserv requires a flexible mapping from DSCP -> PHB. So my
recommendation is to remark CS1 to LE for domains that formerly used
CS1 as LE codepoint. Otherwise, you cannot be sure whether CS1 actually
is CS1 in its original meaning or whether it should be treated as LE.
Removing that ambiguity is the main motivation for my LE PHB draft.

> 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.

Yep, however, bilateral agreement on different behavior is covered by
the Diffserv architecture in general.

> For the ones that do bleaching:

I don't like this fuzzy use of bleaching, see above.
So you basically mean here map DSCP XYZ to the default PHB (BE)?
For me, bleaching includes remarking to DSCP 0, too.

>> From customer/other ISP.
> 1. Remap CS1 to LE.

Nope, only in cases where CS1 was used before in the LE meaning.

> 2. Do not bleach LE.

Yes, keep LE DSCP, no matter how you treat it internally.

> 3. Bleach rest to BE.

What is the rest?

> 4. PHB behaviour should be LE gets lower priority than BE.

Yes, otherwise an ISP looses the advantage of protecting BE
traffic from LE traffic.

> Thoughts?

Regards
 Roland