RE: [PCN] PCN & tunnelling
"Geib, Ruediger" <Ruediger.Geib@t-systems.com> Wed, 24 October 2007 11:10 UTC
Return-path: <pcn-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ike7v-0003Se-6A; Wed, 24 Oct 2007 07:10:19 -0400
Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Ike7t-0003N9-MW for pcn-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 07:10:17 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ike7t-0003N1-46 for pcn@ietf.org; Wed, 24 Oct 2007 07:10:17 -0400
Received: from tcmail31.telekom.de ([217.6.95.238]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ike7s-0000x0-Hf for pcn@ietf.org; Wed, 24 Oct 2007 07:10:17 -0400
Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 24 Oct 2007 13:10:11 +0200
Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Oct 2007 13:10:11 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [PCN] PCN & tunnelling
Date: Wed, 24 Oct 2007 13:10:10 +0200
Message-Id: <1B6169C658325341A3B8066E23919E1C0DE924@S4DE8PSAANK.mitte.t-com.de>
In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC5F4@E03MVZ1-UKDY.domain1.systemhost.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: PCN & tunnelling
thread-index: AcgWJ+54M2I8eYc4QJu/kWUfuySz/QABQXZQ
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: philip.eardley@bt.com
X-OriginalArrivalTime: 24 Oct 2007 11:10:11.0053 (UTC) FILETIME=[719DC1D0:01C8162E]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606
Cc: pcn@ietf.org
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: PCN WG list <pcn.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pcn>
List-Post: <mailto:pcn@ietf.org>
List-Help: <mailto:pcn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1616903898=="
Errors-To: pcn-bounces@ietf.org
Phil, I guess this is a general DiffServ issue too. In case [2] you assume the same DSCP to be used by the tunnel end point PCN domain as at the tunnel entry. This assumption may not hold, if the set DSCP is used for another service class or unused at the end point. I had a brief glance on RFC2983, "Differentiated Services and Tunnels". Downpropagation of outer IP header DSCP/PCN settings may be a fairly good recommendation. Regards, Rudiger -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Wednesday, October 24, 2007 12:24 PM To: pcn@ietf.org Subject: [PCN] PCN & tunnelling Hi, I was chatting with Bob about section 5.8 tunnelling. We've realised there's the following nasty case which we hadn't thought about. The scenario is when a tunnel starts inside a PCN-domain and finishes outside it. First we follow what happens when the current text is followed. Imagine that the pkt is PCN-marked by some PCN-node before the tunnel start node. On encapsulation the PCN-mark is copied onto the outer header. Hence the PCN-egress-node 'sees' the PCN-mark as normal - this is ok. The PCN-egress-node clears the marking in the (outer) header and forwards the pkt into the next domain. The pkt is decapsulated at the tunnel end point. But the decapsulated pkt is already PCN-marked. Potential problems: [1] if it's decapsulated in a non-PCN-domain, then the pkt may confuse nodes in this domain [depending on what encoding is used for a PCN-mark] ; [2] if it's decapsulated in a PCN-domain, then the pkt is PCN-marked [which might lead this PCN-domain to terminate or block a flow unnecessarily]. The problem arises because the PCN-egress-node clears PCN-marking on the outer header but not on the inner header. (This is a new problem compared with ECN & tunnelling.) Possible solution: if the pkt is PCN-marked, then the tunnel start node checks whether the tunnel egress is inside or outside the PCN-domain - if it's outside, then it clears the PCN-marking on the inner header (effectively it does this on behalf of the PCN-egress-node). (Also, the PCN-mark is copied onto the outer header, as the current text says.) Thoughts? Thanks, Phil/
_______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn
- [PCN] PCN & tunnelling philip.eardley
- Re: [PCN] PCN & tunnelling Michael Menth
- RE: [PCN] PCN & tunnelling philip.eardley
- RE: [PCN] PCN & tunnelling Geib, Ruediger
- RE: [PCN] PCN & tunnelling philip.eardley
- RE: [PCN] PCN & tunnelling Geib, Ruediger
- RE: [PCN] PCN & tunnelling philip.eardley
- RE: [PCN] PCN & tunnelling Geib, Ruediger
- RE: [PCN] PCN & tunnelling Anna Charny (acharny)
- RE: [PCN] PCN & tunnelling philip.eardley
- RE: [PCN] PCN & tunnelling Black_David
- RE: [PCN] PCN & tunnelling philip.eardley
- RE: [PCN] PCN & tunnelling Black_David