IETF Logo Mail Archive

Re: [Tsv-art] DCSP mapping

"Black, David" <David.Black@dell.com> Thu, 20 September 2018 14:35 UTC

Return-Path: <David.Black@dell.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4191130F61 for <tsv-art@ietfa.amsl.com>; Thu, 20 Sep 2018 07:35:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level:
X-Spam-Status: No, score=-2.711 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=hOKiG7Av; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=A5se0eID
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 QT0kx0_N8yyK for <tsv-art@ietfa.amsl.com>; Thu, 20 Sep 2018 07:35:56 -0700 (PDT)
Received: from esa7.dell-outbound.iphmx.com (esa7.dell-outbound.iphmx.com [68.232.153.96]) (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 E06F5130F3A for <tsv-art@ietf.org>; Thu, 20 Sep 2018 07:35:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1537454152; x=1568990152; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=rKFgwDlGuUD/dm7QiRuEdlr5XxFhHdLFvl2j4H3NG3k=; b=hOKiG7AvfXgyjgvTOq34e3vn9jto4+IbfpwMQdioqE0GyAk22TbalRzu nHhetSHybWjyD9MstiAKoVsA3e1hzki/rBhEXs15LdyLtLByw/yN3S3BQ CXsw9WWlcoQbVCxIaGjNMoxb/rEAsjgYjbZMCwGw43X3CLGQSgfX3CPht I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2FkAACirqNbhyWd50NbHAEBAQQBAQoBAYFQgTSBOX8oCoNpiBVfjV6DPZMRFIErOwsYCwuEPgIXg0w0GAEDAQECAQECAQECEAEBAQoLCQgpIwyCNSQBDi8cLwkGAQEBAQEBJwEBAQEBAQEBAQEBAQEBAQEBARcCQwESAQEYAQEBAQMBARAREQwfDwwLBAIBCBEEAQEDAgYdAwICAiULFAEICAIEARIIGoJ/AYIBAQ6ZOIlXAQEBbYEugnyHEwMFgQuLPT6BEkaCTIMbAQGBLgESAQ0Ugn8xgiaccAMEAgKQOYFEhFCJDpROAgQCBAUCFIFCgR1xcFCCbIIzg0+FFIU+b4s3gR+BHgEB
X-IPAS-Result: A2FkAACirqNbhyWd50NbHAEBAQQBAQoBAYFQgTSBOX8oCoNpiBVfjV6DPZMRFIErOwsYCwuEPgIXg0w0GAEDAQECAQECAQECEAEBAQoLCQgpIwyCNSQBDi8cLwkGAQEBAQEBJwEBAQEBAQEBAQEBAQEBAQEBARcCQwESAQEYAQEBAQMBARAREQwfDwwLBAIBCBEEAQEDAgYdAwICAiULFAEICAIEARIIGoJ/AYIBAQ6ZOIlXAQEBbYEugnyHEwMFgQuLPT6BEkaCTIMbAQGBLgESAQ0Ugn8xgiaccAMEAgKQOYFEhFCJDpROAgQCBAUCFIFCgR1xcFCCbIIzg0+FFIU+b4s3gR+BHgEB
Received: from mx0b-00154901.pphosted.com (HELO mx0a-00154901.pphosted.com) ([67.231.157.37]) by esa7.dell-outbound.iphmx.com with ESMTP/TLS/AES256-SHA256; 20 Sep 2018 09:35:51 -0500
Received: from pps.filterd (m0089484.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w8KEXi13142754 for <tsv-art@ietf.org>; Thu, 20 Sep 2018 10:35:53 -0400
Received: from esa1.dell-outbound2.iphmx.com (esa1.dell-outbound2.iphmx.com [68.232.153.201]) by mx0b-00154901.pphosted.com with ESMTP id 2mm49kb0p1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <tsv-art@ietf.org>; Thu, 20 Sep 2018 10:35:53 -0400
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-SHA256; 20 Sep 2018 20:35:51 +0600
Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w8KEZmYf008314 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 20 Sep 2018 10:35:50 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com w8KEZmYf008314
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1537454151; bh=Am8kaxSss0V1FBZZvMHqI0AyaIM=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=A5se0eIDd44UKdHAxxr6Xy1zef6JQ7asHBFTDvqQolVNAoErb+QQPxY8I1wq04mMS Y4B33l/jdIWFoqdUeLRkTQRYM6LkdmyQi8JU2sm+MLolca/U1mEnAB9U7X2YRjBlRL XCRN77vp56bN8mv6ir/SsXFxmNInIgdBQCVPl0cY=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com w8KEZmYf008314
Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd55.lss.emc.com (RSA Interceptor); Thu, 20 Sep 2018 10:35:28 -0400
Received: from MXHUB312.corp.emc.com (MXHUB312.corp.emc.com [10.146.3.90]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w8KEYs6x030128 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Thu, 20 Sep 2018 10:35:32 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB312.corp.emc.com ([10.146.3.90]) with mapi id 14.03.0399.000; Thu, 20 Sep 2018 10:35:01 -0400
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, "ietf@kuehlewind.net" <ietf@kuehlewind.net>, "tsv-art@ietf.org" <tsv-art@ietf.org>
Thread-Topic: [Tsv-art] DCSP mapping
Thread-Index: AQHUUM64OHrk0P/PBkaEEmaPwVAwU6T5X7QA///bBqA=
Date: Thu, 20 Sep 2018 14:35:01 +0000
Message-ID: <CE03DB3D7B45C245BCA0D2432779493630295360@MX307CL04.corp.emc.com>
References: <81F8CC39-469C-45AA-A01C-3142C9439605@kuehlewind.net> <62e7537082694d8abe1c8b66e35e0776@ericsson.com>
In-Reply-To: <62e7537082694d8abe1c8b66e35e0776@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.238.21.34]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-20_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809200144
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/ofj1Q1zVhWLs98qva0Fu2KOmcog>
Subject: Re: [Tsv-art] DCSP mapping
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Sep 2018 14:36:07 -0000

There's no simple answer here.  The overall framework is in RFC 2983, but it probably doesn't have the specific guidance that's desired.

For IPsec, the simple discussion in RFC 2474 has been superseded by material in RFC 4301.

Thanks, --David

> -----Original Message-----
> From: Tsv-art [mailto:tsv-art-bounces@ietf.org] On Behalf Of Magnus
> Westerlund
> Sent: Thursday, September 20, 2018 8:41 AM
> To: ietf@kuehlewind.net; tsv-art@ietf.org
> Subject: Re: [Tsv-art] DCSP mapping
> 
> 
> [EXTERNAL EMAIL]
> Please report any suspicious attachments, links, or requests for sensitive
> information.
> 
> 
> Hi,
> 
> Yes, the coping is only relevant if the entity decapsulating the packet isn't
> sitting on an administrative boundary between two different domains with
> potentially different markings. For LISP it appears likely that the LISP
> decapsulator will need to perform DSCP remapping and policing functions.
> 
> Cheers
> 
> Magnus Westerlund
> 
> -----Original Message-----
> From: Tsv-art <tsv-art-bounces@ietf.org> On Behalf Of Mirja Kuehlewind
> (IETF)
> Sent: den 20 september 2018 12:42
> To: TSV-ART <tsv-art@ietf.org>
> Subject: [Tsv-art] DCSP mapping
> 
> Hi all,
> 
> while reviewing lisp (rfc6830bis) I wasn’t really able to find guidance on what
> to do with DSCP for IP in IP tunnels. rfc6830bis say "SHOULD be copied from
> the inner-header DSCP field“ on encapsulation and decapsulation. Other
> docs even say MUST (e.g. rfc6333 section-7.1). rfc2474 section-7.2 say that
> for IPsec it MUST NOT be copied on decapsulation. So I guess, at least for
> decapsulation, it might not alway make sense to overwrite the inner DSCP
> with the changed outer DSCP and I would think that in most cases this is
> rather a local policy question. Do we have any more guidance on this in any
> RFC that I couldn’t find, or is further guidance needed here?
> 
> 
> Mirja
> 
> P.S: For rfc6830bis I would like the author to add a sentence that this SHOULD
> may depend on local policy. („In absence of a different local policy for use of
> DCSP, the DCSP field SHOULD be copied..“ or something like this)
> 
> 
> _______________________________________________
> Tsv-art mailing list
> Tsv-art@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art

v2.23.0 | Report a Bug | By Email