Re: [tsvwg] Considerations for assigning new DSCPs
Ruediger.Geib@telekom.de Tue, 23 February 2021 07:56 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 AB5733A2813 for <tsvwg@ietfa.amsl.com>; Mon, 22 Feb 2021 23:56:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.667
X-Spam-Level:
X-Spam-Status: No, score=-2.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.57, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 F33oIHgwTMRB for <tsvwg@ietfa.amsl.com>; Mon, 22 Feb 2021 23:56:53 -0800 (PST)
Received: from mailout41.telekom.de (mailout41.telekom.de [194.25.225.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEAB83A2810 for <tsvwg@ietf.org>; Mon, 22 Feb 2021 23:56:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1614067012; x=1645603012; h=from:to:cc:subject:date:message-id:mime-version; bh=FMczfLxAl1MLbxBUkU5eOgyGhZwF7c/mw7YjupQ6PNo=; b=QhrtmQ5ATCzsTFHKq174Ua/g9xrWZKsyq6zYB55Ot5LVKir5/EglXeH/ KYpqGJsQrG10bGm+bIwNNozh2rOXizdeUo2tD+RtsKZa66/dToc/v+0Km neuU0moNwRIyszJWKyrNh7Zhs56XzQ0o269j0jj2/KGfDUGI2x8kDkO1a 9g4+nIPKfhCukA+9Lvfp2TbDF6EiPjjb5ZNyZCKIbMZLsgeiK0D9iI/MV m8Ki9cqrb4SkAXyMY3ujFceMKQ0pRUu3oby21JTIXYMxXgbo0AaCeyfZZ 6j8LoAoE55sNFbz1oSksY6pXku+B5bniV4UsIglPrJZmdJ7cLR2Vu6kNC Q==;
IronPort-SDR: 0HB4dO2onac1h7bKIUcV/m6aelMOtSSc5YCLjIU1gYAAuTIcrpJlp5rB1qWkyqvzRtYZ99Lc4t aIk3hw8eE6XA==
Received: from qde8e4.de.t-internal.com ([10.171.255.33]) by MAILOUT41.dmznet.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 23 Feb 2021 08:56:49 +0100
IronPort-SDR: AmI9q6U8hvly/S1Ad4G3gRhawy2qaNLdI8hl+a8Uuly2oHeiSJAyu1fwbo8Uou4IdU7tqVnZd8 IHOiuNUGgXH8GA8PESQ9rla3VQGHazP0U=
X-IronPort-AV: E=Sophos;i="5.81,199,1610406000"; d="scan'208,217";a="958134074"
X-MGA-submission: MDFLOBU96UqxOeRVYAhNGh3ynU4wXsknwMNp5R2qHM5MBZ4amROkwhhMW2t3u4zkFpM9MeHGlJ3a/dXsTwWkCO1Gee6a4vaSobi44Gt8+lcLNBn2fY6cBakBVnp98sOQlKyJb0tl9jc9t8D8v26silZLu6CCvWm4+8rlr3Ayfep1pg==
Received: from he199743.emea1.cds.t-internal.com ([10.169.119.51]) by QDE8PP.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-SHA256; 23 Feb 2021 08:56:47 +0100
Received: from HE105864.EMEA1.cds.t-internal.com (10.169.119.41) by HE199743.emea1.cds.t-internal.com (10.169.119.51) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 23 Feb 2021 08:56:47 +0100
Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE105864.EMEA1.cds.t-internal.com (10.169.119.41) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 23 Feb 2021 08:56:47 +0100
Received: from DEU01-FR2-obe.outbound.protection.outlook.com (104.47.11.177) by O365mail02.telekom.de (172.30.0.235) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 23 Feb 2021 08:56:45 +0100
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SBzl4ddH9dUYMgpin4F/0i+QqDuJmu3IY0oh/Hq0xy3T5UVAFWb60dgEM8EluhB+Zc0oUBVQq3Z7d5qWXAm6xBktpJJqrYvTbYRn8pRJ4+cBvXCBsUktKzmKzfFDe12S7cFoNqPsjQxgm/XgotRt8+HhA0aHvQdP7gvHAg/ErVrejQGvTVoNoe+slfbAQScRP6dcYH5EefTmIrOdEX5wSHvFJbDdmpoD4QEMyMNBbqB1FC3kaz+1FEmOJgEO3vzsBw9JV43VQR1aUf51n7G+fHj/UujXwN7rxeopLaNp5vgDzYZDpEBEqrIE5AoLfQJ7BnYJXYEqy6wbYGCoZw1gSg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FMczfLxAl1MLbxBUkU5eOgyGhZwF7c/mw7YjupQ6PNo=; b=gwxhDxSNRKl8XNMtBN3qQyZqfZaUfkJMm49myRQXQp3GwjCPvzWR5u4ED9Rm/BHLIbRT1CvrcV3cuqbfhWesghI182E3xHglmtbh2EBdHsiYZGL0qhY8rIfHY6VsUVaLFwDsQCZxcHsKFOoBUzqxgl6koO3PStYzIA/ZJoj/QK8glcAvHXU1AD88QNJbVEMd8labHzNqy1Au9wtrCQ1doluTlvMCxlpTRV97w+z/xMTDPIFJk2uUjdYstsqtO/G+8RivVqGo9zU5XPi53fMOyZxctalr4sUkozAQf0nSP+SRP3o90NOsiBbnboyMkcyvzZJRH1hTuhwi5ScaOLqjVg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telekom.de; dmarc=pass action=none header.from=telekom.de; dkim=pass header.d=telekom.de; arc=none
Received: from FRYP281MB0112.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:2::11) by FR2P281MB0219.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:d::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.8; Tue, 23 Feb 2021 07:56:46 +0000
Received: from FRYP281MB0112.DEUP281.PROD.OUTLOOK.COM ([fe80::cd9f:f557:94c6:43]) by FRYP281MB0112.DEUP281.PROD.OUTLOOK.COM ([fe80::cd9f:f557:94c6:43%7]) with mapi id 15.20.3890.018; Tue, 23 Feb 2021 07:56:46 +0000
From: Ruediger.Geib@telekom.de
To: ana@erg.abdn.ac.uk
CC: tsvwg@ietf.org
Thread-Topic: Re: [tsvwg] Considerations for assigning new DSCPs
Thread-Index: AdcJtIMqtht3f4EIQziqPeQyoh9a0Q==
Date: Tue, 23 Feb 2021 07:56:46 +0000
Message-ID: <FRYP281MB01120EA51B9AFC7C9C05FCE89C809@FRYP281MB0112.DEUP281.PROD.OUTLOOK.COM>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: erg.abdn.ac.uk; dkim=none (message not signed) header.d=none;erg.abdn.ac.uk; dmarc=none action=none header.from=telekom.de;
x-originating-ip: [87.147.144.95]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a79034f2-5bef-4c8d-c461-08d8d7d091a1
x-ms-traffictypediagnostic: FR2P281MB0219:
x-microsoft-antispam-prvs: <FR2P281MB021937803621263178B0058E9C809@FR2P281MB0219.DEUP281.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ebooJXtcl3LGa72HeAxtge0mSHkG4nol/jJ8fMcekPsZEUgEL0uxge0BVuW4Vthtr/3hICAi1cPOmJEYgK1A/BZCHi7+6b5pRx1JtKJZNgAKkVbMKQXqtCnZZvA5nv9scMaTzjGEM9nTgy+Wla/eW6nayLn+aG9meC+vcgk3doKDNcR/BotJzuUidd6Y7OR+TeUIFysSA/7DfuD/HvpsvjVpqNTU66bMW4Mz+9t+j/buCV22tFjvQIEzOCGNuKm1pKoq0vwaoY8+jqVWzbjCBwFLTWdxr0hCjAbQqS82/SR1lkvdUeJG0FdSgaJ5v70+tfwvD9S43PM/2TBVSz/wBrC6rERvAjjTvVeilrObylCoQYAVthTkq15XrtedLfs5qUXemZ3+37MJX0ESvOAPn7IIW6YdDeC+mJRd0A5JOqw5YOenFAq05s4BgfT78u/f52cq3K9jppQvOzHHz9fAnpM8zXPmhLjSwUYCwro5kC9YNQilLoXjMY40oMTIsnamI5uEtGH+Co78s+nuBaZqSohsThK+jdQWz4l3eoM0iS8JXN+5eFVB4NXt/PjimSkU
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:FRYP281MB0112.DEUP281.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(376002)(396003)(366004)(346002)(39860400002)(136003)(9326002)(316002)(66574015)(6916009)(296002)(4326008)(5660300002)(8936002)(8676002)(33656002)(66446008)(64756008)(2906002)(7696005)(76116006)(66476007)(86362001)(66946007)(52536014)(66556008)(71200400001)(9686003)(26005)(55016002)(478600001)(6506007)(186003)(17423001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: AUJBAeTekNbIRY39nwxK76PaDJdjwx7leiLsnsCjNltalNq+2TBU8Wjm42liL7lefBMv0suC7mQqxtp+yAa8RxO0KPnx/Fgp/Ulefxihe/H7dsyhq5ag4+rmmnSjLw/iqwmZAw2ggSK5tQ8mh2Qsj85IkdNk/YDolj68qWIdm67reP/Kt7z4+EGS3gzLrkuFUxarEvMO81LLZbcEdITC9jxxZCjZu0ZsfxQ0uv5ryA6GamEWgxqX51jRk/+cTxlXYNXSbjHVwIrJGcshC2yuTS6xZ94JY+XZpHDrg01irAOzHGezqh+mAQ+NhpJRt0P3i9duitPIh2MeBrHYPyVnb+4FBggLN1TIVj7RtdogGABnSMsGNI+4e6wMwWgtZ+bKYAYL3oOhEzEWikJgHzzMWjbri++zxO5A6GpKq193xO6TgQFY+EFPfruy/q9xUwHZp7fKdUy874ANGh+t5wilaJEzNXS7voGkxww7w5W1ndBXRZZ0FAYb7sWcj8UhWN05EEplsyK0Xlcju0SGLYs2W4sQNc5NpLTZi2WK4lgP2ouvCe0JdH4kK5XwlSODyXGb9FuTHcwfleer/3lH5N4cNXI2lzvJSoaUPuy+wBwu5mmYs6VyAo0cY+L0mh85wskuVxAeDIUPRs25DzurRhPIgXRkhp1LiepuReyqRc4JlVTw7SWISrGRxlB1TtgVV4g3GKuZX3ebQcc7z8j/bPspSQ==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_FRYP281MB01120EA51B9AFC7C9C05FCE89C809FRYP281MB0112DEUP_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: FRYP281MB0112.DEUP281.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: a79034f2-5bef-4c8d-c461-08d8d7d091a1
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2021 07:56:46.8536 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 86Ml0TDLg/oOT6/LGUZcw2RB5aKeBGg6R4TpU0KB/rWdnSQvfwCFv/OOxHCRaRMh9ZdnUllF50DRYZ+hJXFG2oqzQmb6ibzemKWKhQJAYJs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: FR2P281MB0219
X-TM-SNTS-SMTP: 368E18D7D29BB549D1CCA5AB73007FCE37E52546C4AC6D978397F58DE4B2B9782000:8
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/5qzjGVYSbf-BQnuoDJLyAr5-w9M>
Subject: Re: [tsvwg] Considerations for assigning new DSCPs
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
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, 23 Feb 2021 07:56:56 -0000
Hi Ana, thanks for your draft. The text as is reviews the standards and operational situation fairly good. There's one particular scenario, which I'd like to be mentioned: a network operator may have deployed an own operational DiffServ scheme, which works with a set of DSCPs. If DSCP based classification is configured for any router within that domain, the network operator needs to decide, how to treat packets received with such a DSCP at an interconnection link without an an operational DSCP. Similar, a network operator may operate an interconnection agreement with a DiffServ related SLA in place. A set of DSCPs is agreed upon for exchange then. Again, a network operator will have to determine, how to ensure that only suitable traffic carries the DSCPs agreed between both parties at the interconnection. I'd appreciate if the above problem is included in the text. DiffServ isn't "greenfield deployment". As an aside, router vendors often support default behaviours to set the MPLS TC. A quite common one is to copy the most significant DSCP bits into the MPLS TC field. Without further action, the local behaviour may be default forwarding. If the next hop classifies on MPLS TC, this might not be true there too. That means operators wishing to support different policies have to configure a suitable policy (leaving the DSCP unchanged and setting MPLS TC to Default PHB is one of them). Finally, from my experience, DSCP to PHB assignment isn't fully compatible between any two network providers. Default is the only exception, EF DSCP 46 (decimal) and CS6 for a network management PHB are often seen too. That also means, the same DSCP may be deployed with different PHBs in separate domains supporting DiffServ. Regards, Ruediger
- [tsvwg] Considerations for assigning new DSCPs Ana Custura
- Re: [tsvwg] Considerations for assigning new DSCPs Ruediger.Geib
- Re: [tsvwg] Considerations for assigning new DSCPs Martin Duke