Re: [PCN] New Version Notificationfordraft-ietf-pcn-baseline-encoding-01

<philip.eardley@bt.com> Tue, 21 October 2008 09:36 UTC

Return-Path: <pcn-bounces@ietf.org>
X-Original-To: pcn-archive@optimus.ietf.org
Delivered-To: ietfarch-pcn-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFF203A6A16; Tue, 21 Oct 2008 02:36:12 -0700 (PDT)
X-Original-To: pcn@core3.amsl.com
Delivered-To: pcn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A528A3A68F0 for <pcn@core3.amsl.com>; Tue, 21 Oct 2008 02:36:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.353
X-Spam-Level:
X-Spam-Status: No, score=-3.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUgNjEzxQlFn for <pcn@core3.amsl.com>; Tue, 21 Oct 2008 02:36:10 -0700 (PDT)
Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 7954B3A6A16 for <pcn@ietf.org>; Tue, 21 Oct 2008 02:36:10 -0700 (PDT)
Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Oct 2008 10:37:18 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 21 Oct 2008 10:37:17 +0100
Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA3BF@E03MVB1-UKBR.domain1.systemhost.net>
In-Reply-To: <1B6169C658325341A3B8066E23919E1C01E206AE@S4DE8PSAANK.mitte.t-com.de>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [PCN] New Version Notificationfordraft-ietf-pcn-baseline-encoding-01
Thread-Index: AckuCkBa3j1de1NSR46ftBFwicREnwAAN6jgAR1FfnAAN9hTkA==
From: philip.eardley@bt.com
To: toby.moncaster@bt.com
X-OriginalArrivalTime: 21 Oct 2008 09:37:18.0755 (UTC) FILETIME=[9C37CF30:01C93360]
Cc: pcn@ietf.org
Subject: Re: [PCN] New Version Notificationfordraft-ietf-pcn-baseline-encoding-01
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PCN WG list <pcn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/pcn>
List-Post: <mailto:pcn@ietf.org>
List-Help: <mailto:pcn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: pcn-bounces@ietf.org
Errors-To: pcn-bounces@ietf.org

{ The key section for the WG to note is Appendix B where I have put in a
{ couple of questions that I would welcome input on.
{ 
{ The first of these is where to put the text (now set out as a table)
about
{ valid and invalid transitions at PCN nodes? Should this be part of the
{ baseline encoding or should it be split between a new edge node
behaviour
{ document and Phil's marking behaviour.

My view is that this should be in the encoding drafts, as what
transitions are valid depends on the encoding (eg the answer would be
different for PSDM). However, I also think - since other encodings are
seen as extensions of the baseline encoding - that the baseline should
define what 'extensions' means - it presumably means that there are
restrictions on those other encodings in terms of what transitions are
valid, eg that 11 MUST correspond to some kind of PCN-marking. 

{ 
{ The second question relates to how to best handle the unexpected
presence
{ of the EXP codepoint. There is a potential for this to happen during
any
{ partial deployment of an experimental encoding extension scheme.
Whilst it
{ would be best for an operator to ensure all nodes run the same
encoding
{ there is a chance this might not happen. The best solution as I see it
is
{ for the baseline scheme to treat EXP the same as NM but to raise a
{ management alarm...

I think this is reasonable. 

{ 
{ I have also highlighted another point in Appendix A which needs a
{ decision: should we as a WG recommend that RFC3168 full functionality
{ tunnels SHOULD NOT be used in a PCN-domain or would it be better to
put
{ our collective voices behind Bob's attempts to correct the anomalous
{ behaviour of tunnels which he is currently trying to push through
TSVWG
{ (draft-briscoe-tsvwg-ecn-tunnel-01)

'should we recommend...' - don't know.
'should we put our collective voices..' - yes. 


_______________________________________________
PCN mailing list
PCN@ietf.org
https://www.ietf.org/mailman/listinfo/pcn