Re: [Gen-art] New Version Notification - draft-ietf-pcn-baseline-encoding-07.txt

"Spencer Dawkins" <spencer@wonderhamster.org> Sat, 26 September 2009 03:17 UTC

Return-Path: <spencer@wonderhamster.org>
X-Original-To: gen-art@core3.amsl.com
Delivered-To: gen-art@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77F823A67B1 for <gen-art@core3.amsl.com>; Fri, 25 Sep 2009 20:17:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.112
X-Spam-Level: *
X-Spam-Status: No, score=1.112 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_50=0.001, SARE_RECV_IP_219128=1.666, STOX_REPLY_TYPE=0.001]
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 m+DBWOgVu8nB for <gen-art@core3.amsl.com>; Fri, 25 Sep 2009 20:17:10 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id A9FF13A672F for <gen-art@ietf.org>; Fri, 25 Sep 2009 20:17:10 -0700 (PDT)
Received: from S73602b ([219.133.197.20]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0Lg28h-1M2yo714Rf-00pOWb; Fri, 25 Sep 2009 23:18:21 -0400
Message-ID: <9490E4A9F20D47C895D8A79DC3C88AE2@china.huawei.com>
From: Spencer Dawkins <spencer@wonderhamster.org>
To: Russ Housley <housley@vigilsec.com>
References: <20090925135609.CC580F2404B@odin.smetech.net>
Date: Sat, 26 Sep 2009 11:18:04 +0800
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5843
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-Provags-ID: V01U2FsdGVkX181eH/WKfYiysLILXZolx8Ar7sy1mvwJ+ABEmK Ng+MCnGP3F568DLd2lFNjgqMCAnESRgBrDBPp8Mvpd76V40xxg Ph0cRmvjPJ52Ut1Canjy1wgcpvptYY2
Cc: General Area Review Team <gen-art@ietf.org>, draft-ietf-pcn-baseline-encoding@tools.ietf.org
Subject: Re: [Gen-art] New Version Notification - draft-ietf-pcn-baseline-encoding-07.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Sep 2009 03:17:11 -0000

Hi, Russ,

Addng The Usual Suspects for our conversation...

> Was your comment about "outermost IP" resolved?

At least "sort of". My biggest concern with 05 was that this qualifier was
introduced suddenly, at the end of section 4, with no explanation. That 
usage has gone away in 07, but there's a NEW usage that was added in 07, in 
section 6, which now says

(second paragraph)

   On its own, this baseline encoding cannot support both ECN marking
   end to end and PCN marking within a PCN-domain.  It is possible to do
   this by carrying e2e ECN across a PCN domain within the inner header
   of an IP in IP tunnel, or by using a richer encoding such as the
   proposed experimental scheme in [I-D.ietf-pcn-3-state-encoding].

(third paragraph)

   In any PCN deployment, traffic can only enter the PCN-Domain through
   PCN-ingress-nodes and leave through PCN-egress-nodes. PCN-ingress-
   nodes ensure that any packets entering the PCN- domain have the ECN-
-> field in their outermost IP header set to the appropriate PCN
   codepoint. PCN-egress-nodes then guarantee that the ECN-field of any
   packet leaving the PCN-domain has the correct ECN semantics. This
   prevents leakage of ECN marks into or out of the PCN-domain and thus
   reduces backward compatibility issues.

If the third paragraph is about tunneled packets, I'd prefer it to say "any 
tunnelled packets entering the PCN-domain". If the third paragraph is about 
all packets (whether tunneled or not), I'd prefer s/outermost//.

You guys are the ones who get to say whether this preference matters, of 
course :-)

Since most of this text is new, I should also ask - 05 called out both 
IP-in-IP and IPsec tunnels, while 07 calls out only IP-in-IP (plus the 
experimental encoding that was added). Was that change intentional? I'm just 
asking about the difference, I don't have a preference ...

Spencer