Re: [tsvwg] residential broadband BCP PHB and CP treatment Re: CC/bleaching thoughts for draft-ietf-tsvwg-le-phb-04

"Black, David" <David.Black@dell.com> Tue, 24 April 2018 23:56 UTC

Return-Path: <David.Black@dell.com>
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 F33F0126C2F for <tsvwg@ietfa.amsl.com>; Tue, 24 Apr 2018 16:56:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level:
X-Spam-Status: No, score=-2.71 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=fvWZcEjj; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=HU/n1sqW
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 25zJKFpPkx4d for <tsvwg@ietfa.amsl.com>; Tue, 24 Apr 2018 16:56:26 -0700 (PDT)
Received: from esa1.dell-outbound.iphmx.com (esa1.dell-outbound.iphmx.com [68.232.153.90]) (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 9161C124319 for <tsvwg@ietf.org>; Tue, 24 Apr 2018 16:56:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1524613683; x=1556149683; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=VT+WIS4ff7cncqWdD6UbS3IrCjdaN2PHeZ+ERnLn4us=; b=fvWZcEjjyAmD2xTPc3x1A+iXNXFduWdFfcp3Nv9518qSXjPG6yXVPHlA Woa5I9pWbnWaow6OBV6dPkCJ9Dm+F7ZeX9dINp2y8pSHtt3+580v6nmcr 6Uz/HSe2l5JBf1IldszSeoZmrnvUrWOYEVza7ZqZgOpgCsEn6V6+TTXkh Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GHAACvw99ah8mZ6ERbGwEBAQEDAQEBC?= =?us-ascii?q?QEBAYJvJYIKKAqLYox+gXSBD5MDFIEpOwsugz2BAQKCeSE0GAECAQEBAQEBAgE?= =?us-ascii?q?BAhABAQEKCwkIKCMMgjUiEUshCDMBAQEBAQEBAQEBAQEBAQEBAQEXAj0TAQEYA?= =?us-ascii?q?QEBAQIBJxMGHxoBBAcEAgEIDgMEAQEBChQFBAcyFAkIAgQBDQUIE4RsCAGoUzO?= =?us-ascii?q?CdoVOgjEIhxB8gVU+gQ+DC4Q/AQELBwEhBTGCeIIkl38DBQKILJJkkAsCBAIEB?= =?us-ascii?q?QIUgSUcgRpxcIMTgi4agzSKUm+OQA8XgQiBGAEB?=
X-IPAS-Result: =?us-ascii?q?A2GHAACvw99ah8mZ6ERbGwEBAQEDAQEBCQEBAYJvJYIKKAq?= =?us-ascii?q?LYox+gXSBD5MDFIEpOwsugz2BAQKCeSE0GAECAQEBAQEBAgEBAhABAQEKCwkIK?= =?us-ascii?q?CMMgjUiEUshCDMBAQEBAQEBAQEBAQEBAQEBAQEXAj0TAQEYAQEBAQIBJxMGHxo?= =?us-ascii?q?BBAcEAgEIDgMEAQEBChQFBAcyFAkIAgQBDQUIE4RsCAGoUzOCdoVOgjEIhxB8g?= =?us-ascii?q?VU+gQ+DC4Q/AQELBwEhBTGCeIIkl38DBQKILJJkkAsCBAIEBQIUgSUcgRpxcIM?= =?us-ascii?q?Tgi4agzSKUm+OQA8XgQiBGAEB?=
Received: from esa1.dell-outbound2.iphmx.com ([68.232.153.201]) by esa1.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Apr 2018 18:48:02 -0500
From: "Black, David" <David.Black@dell.com>
Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa1.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Apr 2018 05:47:56 +0600
Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w3ONuL5v001935 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 24 Apr 2018 19:56:23 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com w3ONuL5v001935
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1524614184; bh=VSgGuy5+ohULbYpU0zLwgsdUfC4=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=HU/n1sqWo4LpfiEwjV5KmOx3bPpcBEtRVtJ+HPM5Ts5GobSAiEcuuhat4ikgSA6IF 4SrmqQObSb+iaDUuTd6F+WE1nCk9iBUT0J0y6a89yeyoMsBurhPlFe+uF2zsXfK7ME ky2PIau4kORJe5QBzwyR5xi/6T+sQAp3ynRvtdkA=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com w3ONuL5v001935
Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd51.lss.emc.com (RSA Interceptor); Tue, 24 Apr 2018 19:56:07 -0400
Received: from MXHUB308.corp.emc.com (MXHUB308.corp.emc.com [10.146.3.34]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w3ONu6Fc014635 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 24 Apr 2018 19:56:07 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB308.corp.emc.com ([10.146.3.34]) with mapi id 14.03.0382.000; Tue, 24 Apr 2018 19:56:06 -0400
To: Mikael Abrahamsson <swmike@swm.pp.se>, "Ruediger.Geib@telekom.de" <Ruediger.Geib@telekom.de>
CC: "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: [tsvwg] residential broadband BCP PHB and CP treatment Re: CC/bleaching thoughts for draft-ietf-tsvwg-le-phb-04
Thread-Index: AQHT2GK3QYzDf+FYzUueQoZxlCcnhaQJdzIAgAAFEwCAABtDAIAATfSAgAApirCAAOtVAIADY+0AgAACpICAABx9gIAABbkAgAIMN6A=
Date: Tue, 24 Apr 2018 23:56:06 +0000
Message-ID: <CE03DB3D7B45C245BCA0D24327794936300F3BFE@MX307CL04.corp.emc.com>
References: <20180406160344.xwfqgzhzfto56jhq@faui48f.informatik.uni-erlangen.de> <LEJPR01MB10334C794BDA7E125917576E9CBC0@LEJPR01MB1033.DEUPRD01.PROD.OUTLOOK.DE> <alpine.DEB.2.20.1804190826550.18650@uplift.swm.pp.se> <adf6493b-45fd-9d0c-70f5-5d343cad22dd@gmail.com> <alpine.DEB.2.20.1804200635060.18650@uplift.swm.pp.se> <LEJPR01MB103305081F93A808ED0AF7159CB40@LEJPR01MB1033.DEUPRD01.PROD.OUTLOOK.DE> <alpine.DEB.2.20.1804200849320.18650@uplift.swm.pp.se> <LEJPR01MB10338267E78F2107698C70BF9CB40@LEJPR01MB1033.DEUPRD01.PROD.OUTLOOK.DE> <alpine.DEB.2.20.1804201458270.18650@uplift.swm.pp.se> <CE03DB3D7B45C245BCA0D24327794936300EBB0F@MX307CL04.corp.emc.com> <alpine.DEB.2.20.1804210739060.18650@uplift.swm.pp.se> <LEJPR01MB1033F2AB7F4E80F1777636F29C890@LEJPR01MB1033.DEUPRD01.PROD.OUTLOOK.DE> <alpine.DEB.2.20.1804231138440.18650@uplift.swm.pp.se> <LEJPR01MB10337F46B7A06BB9805D5CDA9C890@LEJPR01MB1033.DEUPRD01.PROD.OUTLOOK.DE> <alpine.DEB.2.20.1804231333360.18650@uplift.swm.pp.se>
In-Reply-To: <alpine.DEB.2.20.1804231333360.18650@uplift.swm.pp.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.238.21.33]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com
X-RSA-Classifications: public
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/DDZoUpv7V0jq7VDyXWH57QhrQi0>
Subject: Re: [tsvwg] residential broadband BCP PHB and CP treatment Re: 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: Tue, 24 Apr 2018 23:56:29 -0000

Mikael,

<WG Chair Hat= OFF>

As an individual, I haven't completely thought this through, but my initial reaction is that there are two problems here that may not have the same solution, as link 1 is rather different from links 4 and 5:

> INTERNET<-1->PEERING ROUTER<-2->CORE ROUTER<-3->BNG<-4->HGW<-5->COMPUTER
> 
> 1. This link connects the ISP to the Internet (peers, IXes, transit)
> 2. This link connects core/peering routers to each other.
> 3. This link connects core to BNG.
> 4. This link connects the residential access to HGW (DSL/PON/P2P eth/DOCSIS)
> 5. This link connects devices within the home (wifi/ethernet)
> 
> I want to document recommendations regarding PHB and CP (re-)mapping that
> can be done egress/ingress on 1 (peering router ingress/egress), 4 (BNG
> ingress/egress), 4(HGW ingress/egress) and 5 (HGW/hosts egress/egress,
> RFC8325) most likely based on IP level information such as DSCP.

The simplest (and special) case is Network Control traffic.  That should not be flowing from the COMPUTER to the operator's network, so the BNG has to bleach CS6 (and CS7) inbound on link 4, and the HGW ought to bleach those DSCPs inbound on link 5 if the HGW managed by the operator.  OTOH, BGP traffic using CS6 (and perhaps CS7) is to be expected on link 1 and bleaching CS6 when used for BGP traffic is a bad idea for obvious reasons ;-).

> In my experience it's very common that today's behaviour is to set CP=0
> ingress on 1 (peering router ingress) and 4 (BNG ingress) and PHB is all
> BE. This is what I want to change.

That was also a goal of RFC 8100, primarily for link 1 where the operator uses MPLS and aligns DSCP usage with the MPLS TC field ...

> It can involve setting MPLS EXP/802.1p information based on DHCP CP (link
> 2 and 3, potentially 4), but that's up to the individual ISP what they
> want to do (I am not interested in recommending values for that).

It may not be that simple ... RFC 8100 was written for MPLS-based networks (where at least link 2 uses MPLS) where the operator aligns DSCP usage with the MPLS TC field.   One of the conclusions to be drawn from RFC 8100 is *in that operator's MPLS world*, link 1 is unlikely exhibit richness of DSCP usage approaching what is described in RFC 8325 or the rtcweb-qos draft.  This is because the number of DSCP values in use across MPLS links is limited when internal DSCP usage is aligned with the MPLS TC field.

If there are two different regimes for DSCP usage (link 1 vs. links 4 and 5), then the configuration concern that I think underlies this thread is how to map between them.  For RFC 8100, section 4 specifies traffic aggregates, including the DSCPs to use.   The mapping from the larger set of DSCPs that may be used on links 4 and 5 to the DSCPs in section 4 is then obtained by reading that section in concert with RFC 4594 ... and I won't disagree with the criticism that this is not easy for the uninitiated to figure out :-(.

It's also the case that LE/scavenger traffic isn't handled particularly well by RFC 8100 - this was raised as a concern while we were working on RFC 8100 (I'm an author), and at the time it was mostly deferred (RFC 8100 remarks it to BE at the interconnection).  I'll admit that one of my concerns at the time was that if we held up work in order to nail down all the considerations around LE/scavenger traffic, RFC 8100 would likely still not be published.

Thanks, --David

> -----Original Message-----
> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Mikael
> Abrahamsson
> Sent: Monday, April 23, 2018 7:44 AM
> To: Ruediger.Geib@telekom.de
> Cc: tsvwg@ietf.org
> Subject: Re: [tsvwg] residential broadband BCP PHB and CP treatment Re:
> CC/bleaching thoughts for draft-ietf-tsvwg-le-phb-04
> 
> On Mon, 23 Apr 2018, Ruediger.Geib@telekom.de wrote:
> 
> > Mikael,
> >
> > and it's not easier for me to understand your discussion.
> 
> Let me try some schematics for a simplified network that's pertinent to
> what I want to achieve:
> 
> INTERNET<-1->PEERING ROUTER<-2->CORE ROUTER<-3->BNG<-4->HGW<-5-
> >COMPUTER
> 
> 1. This link connects the ISP to the Internet (peers, IXes, transit)
> 2. This link connects core/peering routers to each other.
> 3. This link connects core to BNG.
> 4. This link connects the residential access to HGW (DSL/PON/P2P
> eth/DOCSIS)
> 5. This link connects devices within the home (wifi/ethernet)
> 
> I want to document recommendations regarding PHB and CP (re-)mapping
> that
> can be done egress/ingress on 1 (peering router ingress/egress), 4 (BNG
> ingress/egress), 4(HGW ingress/egress) and 5 (HGW/hosts egress/egress,
> RFC8325) most likely based on IP level information such as DSCP.
> 
> In my experience it's very common that todays behaviour is to set CP=0
> ingress on 1 (peering router ingress) and 4 (BNG ingress) and PHB is all
> BE. This is what I want to change.
> 
> It can involve setting MPLS EXP/802.1p information based on DHCP CP (link
> 2 and 3, potentially 4), but that's up to the individual ISP what they
> want to do (I am not interested in recommending values for that).
> 
> Does this help?
> 
> --
> Mikael Abrahamsson    email: swmike@swm.pp.se