RE: [PCN] PCN & tunnelling

"Anna Charny (acharny)" <acharny@cisco.com> Wed, 24 October 2007 13:30 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 1IkgJF-00076I-V3; Wed, 24 Oct 2007 09:30:09 -0400
Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IkgJE-00075I-7t for pcn-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 09:30:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkgJD-00074z-Ri for pcn@ietf.org; Wed, 24 Oct 2007 09:30:07 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkgJC-0005mq-BN for pcn@ietf.org; Wed, 24 Oct 2007 09:30:07 -0400
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 24 Oct 2007 06:30:05 -0700
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l9ODU5fG029704; Wed, 24 Oct 2007 06:30:05 -0700
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9ODU3x9015210; Wed, 24 Oct 2007 13:30:04 GMT
Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Oct 2007 09:29:55 -0400
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 09:29:53 -0400
Message-ID: <BABC859E6D0B9A4D8448CC7F41CD2B070558B5C0@xmb-rtp-203.amer.cisco.com>
In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC5F4@E03MVZ1-UKDY.domain1.systemhost.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [PCN] PCN & tunnelling
Thread-Index: AcgWJ+54M2I8eYc4QJu/kWUfuySz/QAGbMXg
From: "Anna Charny (acharny)" <acharny@cisco.com>
To: philip.eardley@bt.com, pcn@ietf.org
X-OriginalArrivalTime: 24 Oct 2007 13:29:55.0174 (UTC) FILETIME=[F6F11860:01C81641]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15502.002
X-TM-AS-Result: No--23.672600-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8912; t=1193232605; x=1194096605; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20(acharny)=22=20<acharny@cisco.com> |Subject:=20RE=3A=20[PCN]=20PCN=20&=20tunnelling |Sender:=20; bh=WdYszEm6eKzHSPeclwQuZlP/r9K3ciTGMZD0GEPckpU=; b=hKbIwqzBmUnds2VsgRgJxa2FKgiumBD2QopvgaDU92GqHBNvgf2BmPAI4kXPa6i4+rwlHeam eZaxFzJNzJwkIqki83iGnKNzpKZnp3t0DinoREHcrepGQXkkaH/jCMND;
Authentication-Results: sj-dkim-4; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d
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="===============0345042589=="
Errors-To: pcn-bounces@ietf.org

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