RE: [PCN] PCN & tunnelling
<philip.eardley@bt.com> Wed, 24 October 2007 19:06 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 1IklYH-0001Az-VH; Wed, 24 Oct 2007 15:06:01 -0400
Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IklYG-0001As-C4 for pcn-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 15:06:00 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IklYF-00014L-Kz for pcn@ietf.org; Wed, 24 Oct 2007 15:05:59 -0400
Received: from smtp4.smtp.bt.com ([217.32.164.151]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IklY8-0006kp-Pp for pcn@ietf.org; Wed, 24 Oct 2007 15:05:53 -0400
Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Oct 2007 20:05:51 +0100
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 20:05:51 +0100
Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC5F7@E03MVZ1-UKDY.domain1.systemhost.net>
In-Reply-To: <BABC859E6D0B9A4D8448CC7F41CD2B070558B5C0@xmb-rtp-203.amer.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [PCN] PCN & tunnelling
Thread-Index: AcgWJ+54M2I8eYc4QJu/kWUfuySz/QAGbMXgAAt1T+A=
From: philip.eardley@bt.com
To: acharny@cisco.com, pcn@ietf.org
X-OriginalArrivalTime: 24 Oct 2007 19:05:51.0618 (UTC) FILETIME=[E51E5E20:01C81670]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: dadeebe491e67c033a493fd3c7d6792b
Cc:
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="===============1336389931=="
Errors-To: pcn-bounces@ietf.org
Anna, I don't know. For inspiration, I looked at rfc2983, diffserv & tunnels. S3.2 of this talks about partially capable DS configs - only tunnel ingress is DS-capable but not the egress. It says that If tunnel decapsulation processing discards the outer header's DSCP value without changing the inner header's DSCP value, the DS-capable tunnel ingress node is obligated to set the inner header's DSCP to a value compatible with the network at the tunnel egress. The value 0 [is a good suggestion] this approach is along the same lines to the one in the original email below. Unfortunately 2983 doesn't say how the tunnel ingress node knows about the characteristics of the network at the tunnel egress. Did the DS people have anything in mind that might apply in the PCN case? phil -----Original Message----- From: Anna Charny (acharny) [mailto:acharny@cisco.com] Sent: 24 October 2007 14:30 To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org Subject: RE: [PCN] PCN & tunnelling Hi Phil, Question: what would be the mechanism for knowing whether the egress of the tunnel is in the PCN domain or not? Are we assuming that a node somehow advertises its PCN capability? I do not think we ever explicitly assumed that? Anna ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Wednesday, October 24, 2007 6:24 AM 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
- RE: [PCN] PCN & tunnelling philip.eardley
- [PCN] PCN & tunnelling philip.eardley
- Re: [PCN] PCN & tunnelling Michael Menth
- RE: [PCN] PCN & tunnelling Geib, Ruediger
- RE: [PCN] PCN & tunnelling Anna Charny (acharny)
- RE: [PCN] PCN & tunnelling philip.eardley
- 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 Black_David
- RE: [PCN] PCN & tunnelling philip.eardley
- RE: [PCN] PCN & tunnelling Black_David