Re: [Gen-art] [PCN] Fwd: Gen-ART Review of draft-ietf-pcn-baseline-encoding-05

<toby.moncaster@bt.com> Wed, 26 August 2009 15:54 UTC

Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Date: Wed, 26 Aug 2009 16:10:50 +0100
Message-ID: <AEDCAF87EEC94F49BA92EBDD49854CC70CC818C9@E03MVZ1-UKDY.domain1.systemhost.net>
In-Reply-To: <6E7D1A1DCF204A0D99F33ED580828511@china.huawei.com>
Thread-Topic: [PCN] Fwd: [Gen-art] Gen-ART Review of draft-ietf-pcn-baseline-encoding-05
Thread-Index: AcomXFbmAlb5a/S9S3eFZPzhCj0EyQAADDsA
References: <5E43A7EBE4804970AD0C52F08C272CDB@china.huawei.com> <7AF37E93-87EE-4C7C-9205-965544C8480B@nokia.com> <cf33bfb67c18c82307017566ab382e2f@petri-meat.com> <6E7D1A1DCF204A0D99F33ED580828511@china.huawei.com>
From: toby.moncaster@bt.com
To: spencer@wonderhamster.org, slblake@petri-meat.com
Cc: gen-art@ietf.org, draft-ietf-pcn-baseline-encoding@tools.ietf.org
Subject: Re: [Gen-art] [PCN] Fwd: Gen-ART Review of draft-ietf-pcn-baseline-encoding-05
Precedence: list

I think I may be able to clear this up... This text was added as part of a set of changes when we were debating the impact of tunnels on PCN encoding, hence the mention of "outermost IP header". At the time there was a lot of text about tunnelling in the draft which has subsequently been significantly reduced. In practise in the context it's in we can just drop the words "outermost IP header" as this document isn't actually about tunnelling...

Toby

> -----Original Message-----
> From: Spencer Dawkins [mailto:spencer@wonderhamster.org]
> Sent: 25 August 2009 18:18
> To: slblake@petri-meat.com
> Cc: draft-ietf-pcn-baseline-encoding@tools.ietf.org; General Area
> Review Team
> Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review of draft-ietf-pcn-
> baseline-encoding-05
> 
> Hi, Steve,
> 
> Thanks for the quick response.
> 
> >>>
> >>>      DSCPs.  Guidelines for mixing traffic-types within a PCN-
> domain
> >>>      are given in [I-D.ietf-pcn-marking-behaviour].
> >>>
> >>>   o  Any packet that is not-PCN but which shares the same Diffserv
> >>>      codepoint as PCN-enabled traffic MUST have the ECN field of
> its
> >>>      outermost IP header equal to 00.
> >>>
> >>> Spencer (minor): this is the only point in the specification (that
> I
> >>> can
> >>> find) that makes reference to the "outermost IP header". I'm not
> sure
> >>> whether to suggest s/outermost// here or to ask that a statement be
> >>> added
> >>> earlier in the document to clearly state that PCN encoding only
> >>> protects
> >>> inelastic traffic when it's used for the outermost IP header, but
> the
> >>> current text seems to call attention to this in a way that makes
> the
> >>> reader
> >>> wonder what is special about THIS requirement that isn't true of
> the
> >>> other
> >>> requirements listed.
> >
> > I'm sorry, but I'm having a hard time following this comment.  Could
> you
> > please clarify?
> 
> I'm probably not saying this well - my question is basically why this
> requirement calls out "ECN field of its outermost IP header", when
> other
> requirements that mention ECN field do not. If there's a reason why
> s/outermost// in this case would be wrong, I don't know what it is, and
> that's what worries me - should the other requirements ALSO say
> "outermost"?
> 
> I'm not asking for this change, just trying to understand.
> 
> Thanks,
> 
> Spencer

[Gen-art] Gen-ART Review of draft-ietf-pcn-baseli… Spencer Dawkins
Re: [Gen-art] [PCN] Fwd: Gen-ART Review of draft-… Spencer Dawkins
Re: [Gen-art] [PCN] Fwd: Gen-ART Review of draft-… toby.moncaster