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

["Spencer Dawkins" <[e-mail]>]

Hi, Toby,

I've been there ;-)

Like I said, I'm good either way, and thanks for the quick response.

Spencer

----- Original Message ----- 
From: <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Monday, September 28, 2009 7:40 PM
Subject: RE: New Version Notification - 
draft-ietf-pcn-baseline-encoding-07.txt


Oh bugger! I phrased that rather clumsily didn't I...

I am certain that the "outermost" in the third paragraph can be removed 
without in any way affecting the meaning. After all, unless you are 
explicitly referring to tunnelled packets then it is taken as read that you 
are talking about the outermost header!

So in summary, I am completely OK to remove this mention of "outermost" and 
will try and re-boot my brain out of thinking about everything in terms of 
tunnels (which seem to keep cropping up in my work at the moment!). Do you 
need me to explicitly remove this in a new revision or can we get the RFC 
Editor to do so when the document advances?

Toby

____________________________________________________________________
Toby Moncaster, Senior Researcher, Network Infrastructure Practise
B54/70 Adastral Park, Ipswich, IP53RE, UK. [phone]



> -----Original Message-----
> From: Spencer Dawkins [mailto:[e-mail]]
> Sent: 26 September 2009 04:18
> To: Russ Housley
> Cc: [e-mail]; General Area
> Review Team
> Subject: Re: New Version Notification - draft-ietf-pcn-baseline-
> encoding-07.txt
>
> 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