Subject: [PCN] FW: Some comments on draft-ietf-pcn-baseline-encoding-02

From: <[email-masked]>
Date: Thu, 14 May 2009 10:21:21 +0100

There were some effectively LC comments from Gorry that were posted to
the list (and copied below).
http://www.ietf.org/mail-archive/web/pcn/current/msg02090.html

Toby

-----Original Message-----
From: Gorry Fairhurst [mailto:[email-masked]] 
Sent: 05 May 2009 17:50
To: Moncaster,T,Toby,CXR9 R
Cc: [email-masked]
Subject: Re: Some comments on draft-ietf-pcn-baseline-encoding-02

Greetings Toby!

Thanks, I was pleased to see many of the comments had been addressed.
There are some comments that you may like to consider further as you
process any other LC comments (marked **).

I hope this helps, this document seems quite mature and looks nearly
finished.

Best wishes,

Gorry

[email-masked] wrote:
> Hi Gorry,
>  
> here is your list of comments with my annotations of how I addressed
them in version 03 (the current version which is in WGLC). My comments
marked {TM}...
>  
> Toby
> 
> ________________________________
> 
> From: Gorry Fairhurst [mailto:[email-masked]]
> Sent: Fri 27/03/2009 18:20
> To: [email-masked]
> Cc: Briscoe,RJ,Bob,CXR9 R; Moncaster,T,Toby,CXR9 R;
[email-masked]; Gorry
> Subject: Some comments on draft-ietf-pcn-baseline-encoding-02
> 
> 
> 
> Here are some comments on pcn baseline encoding, the document seems in
> good shape, but there are probably a few things I would update to help
> others to read this document.
> 
> Gorry
> 
> 
> General comments:
> 
> - It would be really nice to see the explanation.
> 
> {TM} this comment really applies to lots of the drafts. 
> We have now concocted a new Intro paragraph (elevator pitch)
> to set the scene + I re-wrote the abstract (see later)
> 
True. I found the new abstract is much clearer, if i had read this
and the new introduction I do not think that I would have made that
comment.

> - I had problems reading this to understand what was the implication
on
> packet forwarding - the key thing that I thought was missing, I later
> found in 4.2. Have the authors thought about placing this section
ahead
> of the others and then explicitly calling out with a [very short]
> subsection on what to do if there were a DSCP conflict and how the
> original traffic could be mapped to not-PCN and the where to find
> details on how to traffic ECN-enabled traffic on this DSCP (i.e.
tunnel?).
> 
> {TM}I still need to write a sub-section to address this, but am not 
> sure where it should fit in the structure. Probably within 4.3 or as a
> new subsection 4.3.1. I can then refer to it in the intro...
> 

> 
> - I found Table 2 hard to understand, then discovered there were some
> encodings missing.
> 
> {TM} Completely replaced with text sections for ingress and egress 
> + a new table for the interior nodes.
> Let me know if this is any clearer (not sure how else to clarify
> it as there are so many posisble transitions)
> 
Looks good.

> - I think the security considerations could be improved.
> 
> {TM} Did my best but they are still not ideal. 
> Any suggestions on additions gratefully received!
> 
> - To me, Appendix A.2 seems reasonable.
>
** This point seems weak:
    "o  Leakage of traffic into PCN-domain: ECT(1) is slightly less
likely"

I think you should be stronger e.g.:
"Overall this seemed to suggest ECT(0) was most appropriate to use."
- e.g. On the basis of the above considerations, ECT(0) was selected for
use.

> 
> ----------------------
> Specific comments:
> 
> Abstract
> -  English seems to me to need a little polishing.
> s/in order// ?
> - Please mention ECN code points in the abstract.
> - Later you say a sentence such as:
>     The PCN encoding states are defined using a combination of the
DSCP
>     and ECN fields within the IP header. The baseline PCN encoding
>     closely follows the semantics of ECN [RFC3168].
> 
> {TM} re-wrote abstract completely. Let me know if you think it is
better or not
> 
> Abstract
> " below the physical link rate." - This seems very odd to me, I
thought
> this was about the link capacity.
> 
> {TM} I think its about link rate but this is more to do with the
architecture
> and marking behaviour. The new intro which has been agreed by most 
> people
> uses rate not capacity...
> 
> Abstract
> "states but such schemes will be described in other documents."
>         ^
> - insert comma, or better still separate this into two sentences (to
me
> it seems an odd way for a PS abstract to finish).
> 
The rewrite looks good to me.

> S1
> Makes no mention of ECN fields, which would be nice for people wanting
> to look for documents that show the meaning of the ECN-field.
> 
> {TM} It now mentions ECN
** Good, although a NIT is it would be nice to see the term "ECN"
defined (expanded) the first time it appears in the introduction.

> 
> S1
> "Other extensions have also been suggested all of which can build on
the
> baseline encoding."
> - Seems very bold. is the WG sure that *ALL* can build on this?
> 
> {TM} removed claim and replaced with "can be easily extended" plus 
> pointed out the guidelines later in doc (but no xref)
> 
** NiT: I misread /states and rules/ when I first read this, perhaps you
could put some punctuation in here?
e.g.
/However, the encoding can be easily extended to provide more
    states. Rules for such extensions are given in this document./

> S1
> "MUST extend this baseline scheme"
> - How? - The draft places a normative requirement, but doesn't say
what
> is intended. Is this by updating this specification? By obsoleting
this
> spec? using some common part of the same framework? - I don't see what
> is being required.
> 
> {TM} removed this
> 
OK - that avoids this issue.

> S3, bullet 2
>     o  PCN-marked - codepoint indicating packets that have been marked
at
>        a PCN-interior-node using some PCN marking behaviour
>        [pcn-marking-behaviour].  Also PM.
>                                  ^^^^^^^
> - is this an alternative or a definition of the term PN?
> 
> {TM} its the official abbreviation. I've clarified all these
definitions
> 
> S3:
>     o  Not-marked - codepoint indicating packets that are PCN-capable
but
>                                                                      ^
> - comma?
> S3:
>        are not PCN-marked.  Also NM.
>                              ^^^^^^^
> - is this an alternative or, as I think, a definition of the term NM?
> 
> 
> S3:
>    By definition packets carrying such codepoints are PCN-packets.
>                 ^
> - comma?
> 
> S3:
>     o  PCN-compatible Diffserv codepoint - a Diffserv codepoint for
which
>        the ECN field is used to carry PCN markings rather than
[RFC3168]
>        markings.
> - Could this definition be placed as bullet one or bullet two?
> 
> {TM} re-ordered all the definitions...
> 
Fine now.

> S3:
>     In addition the document uses the terminology defined in
[pcn-arch].
>                ^
> - comma?
> 
> S4:
>     allows for traffic that is not PCN capable to be marked as such
(Not-
>     PCN).
> - I'd like to see this more clearly called out. The reader of this
spec
> may be trying to figure out how these codepoints are used with PCN and
> how to transport the traditional use of ECN or where the DSCP is
already
> used for non PCN traffic. The structure of the document did not really
> help me in this case at all (although the framework seems to be
> addressing this case). A very short section that simply sets out the
NON-PCN
> 
> {TM} This probably still needs to be addressed. If I add a section as 
> asked for above on DSCPs this would naturally sit there. But not sure 
where
> best to insert the section?
>
** This question still seems to need an answer.
> 
> S4
>             to prevent any possible future compatability issues.
> - remove /any/ - or are sure?
> 
> {TM} I was fairly sure but I removed it anyway
> 
done.
> 
> S4
>     o  Any packet that is not PCN-enabled (Not-PCN) but which shares
the
>                                                     ^
> 
> S4
> Table 2 is not easily understood. In fact, I got pretty confused, then
> discovered there were some encodings missing. I'd really like to see
all
> the encodings or a different table format.
> 
> {TM} see comment above
> 
> S4
>        packet MUST be treated as if it were NM.
>                                       ^^^^^^
> - as if it carried the NM marking?
> 
> {TM} yep
> 
> S4
> End 4.0 has a truncated sentence
> 
> {TM} Ooops! Don't know what happened there. Over-enthusiastic use of
delete key
> 
> 
> 4.1 says:
> If the packet is being tunneled then only the 11 codepoint gets copied
> into the inner header upon decapsulation.
> 
> - This language seems odd to me.
> 
> {TM} rephrased this to hopefully make it clearer 
> - and people will have to read Bob's ECN tunnel draft (which is much
> clearer in its new form) to find out more
> 
> 
> An additional constraint is the need to minimise
>     the use of DiffServ codepoints as
>                                    ^^
> -English? - because?
> 
> {TM} sorry,  missed this one...
> 
** Please fix

> S4.1
>     The encoding scheme above seems to meet all these constraints and
> - is this WG consensus, or author's?
** Seems fine, then I'd be happier making this decision and saying "This
was judged by the PCN WG to ..."
> 
> {TM} I think its more or less WG consensus by now... 
> It took a lot of arguing to get to this scheme and many dead ends...
> 
> S4.2
>     Enabling PCN for a DSCP switches on PCN marking behaviour for
packets
>                        ^^^^^^^^^^^^^
> - Better phrase here?
> 
> {TM} I've tried to improve the phrasing
> 
OK
> S4.2
>     but only if those packets also have their ECN field
>     set to indicate a codepoint other than Not-PCN.
> - presumably this refers to PCN router behaviour within a PCN domain?
> 
> {TM} Yes. Probably I should add this is only relevant within the
PCN-domain
** I think your proposed change would be an improvement.

> S4.2
>     Enabling PCN marking behaviour disables any other marking
behaviour
> - OK, but I think this should be clearer that this is for only for a
> specific DSCP.
> 
> {TM} missed this one
> 
** I think this should be changed.
> S5
>     o  The 00 codepoint in the ECN field MUST mean Not-PCN.
> - not sure /mean/ is the correct word, should it be /indicate/ (and
> following points)
> - and should this also say and /MUST NOT be  changed to any other
> codepoint within a PCN domain/?
> 
> {TM} Yes - and now does say this. Also corrected to indicate
> 
OK
> S5
>     o  Once set the 11 codepoint in the ECN field MUST NOT be changed
to
>               ^
> - insert comma
> - /doesn't/ change to /does not/
> 
> S5
>     o  Any experimental scheme MUST include details of all valid and
>        invalid codepoint transitions at any PCN nodes.
> - OK, you could say it MUST NOT update 00 or 11  (or is this now
implicit?)
> 
> {TM} added. Hopefully everyone agrees with this...
> 
> S8
>     Packets claim entitlement to be PCN marked by carrying a PCN-
> - English? I think the document should say that that a PCN domain has
> been pre-configured with domain edges, and that this document
describes
> behaviour within the domain.
> 
> {TM} I re-wrote section 8. Can you look and see if you think I
addressed
> most of these comments?
Better

> S8
>    However there is a
>     requirement to keep inter-domain scenarios in mind when defining
the
>     PCN encoding.
> - I found this rather vague, or more precisely too vague for me to
> understand the implications.
> 
Fixed.
> S8
>    Then any one domain's security against its neighbours would
>     be described as part of the proposed edge-node behaviour document.
> - I could not understand what the security implication was and what
was
> being requested of people who followed this document with new
proposals.
> 
> {TM} On re-reading I found this unhelpful so I removed and changed it
> 
OK

> S9
>     It also allows for the co-
>     existence of competing traffic within the same DSCP so long as
that
>     traffic doesn't require end-to-end ECN support.
> s/doesn't/does not/
> - This sounds categorical that this is not possible, but presumably
> tunnels may be used. Is there better language that could be chosen?
> 
> {TM} I missed this one. I should probably clarify that ECN can be 
> tunneled but that it is effectively disabled within the PCN-domain.
> 
** Not sure I understand what you propose that the new text would say. I
think that ECN markings may be tunneled across an ECN domain, by
encapsulating an IP packet with a tunnel header. How would the outer
header of the tunnel be treated if the tunnel egress endpoint was
outside the PCN domain?

** Section 8 also describes behaviour when IPsec is used to tunnel PCN
marked packets.

> S11
> - Should be removed by RFC-Ed?
> {TM} yes
> 
Done.
> S12: Refs.
> - Are there no normative architecture specifications to define what
PCN
> is? - Seems odd for a PS, could this be [pcn-arch].
> 
> {TM} indeed it does seem odd but that is what the charter states. 
> I think it is sort of trying to follow the lead of DiffServ where the
> architecture is an informational document. I have tried to refer to
> marking behaviour more often as that is standards track.
> 
Seems to be addressed.

> S12: Refs.
> - Why is RFC3168 also not normative?
>
done.
> 
> A.1
>   domain includes lower speed links
>                  ^^^^^^^^^^^^^^^^^^
> - Is this really the issue???  Or does this describe a PCN network
link
> with a link with low flow aggregation as an example of the case where
> other appropriate use is needed. If this is not the case, we should
> quantify what is meant by "lower speed" and be much more clear about
the
> guidance here. Either way, I find this confusing.
> 
> {TM} I have left this as is. Can others comment on whether they find
> this confusing also? It might almost be easier just to remove this
> section altogether>
>
The new text seems better.

** The terms "higher" and "lower" are comparative terms, and am I right
that here it relates to the ratio between the rates of the admitted
flows and the link rate (i.e. level of statistical multipelxing)?

> - A.1, suggests there is no fixed DSCP for PCN, this seems a pity from
> the point of view of a router knowing whether PCN is to be invoked, it
> therefore becomes yet one more thing that could be misconfigured. I
> presume this decision has been extensively discussed within the PCN
WG,
> so this probably does not need action?
> 
> {TM} This follows advice from the ADs concerning how slow it is to 
> get a standards track DSCP assigned. I believe the hope is that PCN
> will be rolled out by 1 or 2 operators and found to be successful.
> We can then come back and try for a complete set of DSCPs.
> Also this baseline encoding is a slight red herring as it is really
> just an enabler for experiments to see which alternative encoding is
> most sensible (and to see if encodings offering more codepoints are
> actually necessary). Current simulation results suggest schemes with
> a single marked state are less good than those with 2 marked states
> 
Understood, and I assume the ADs would support this. See comment at end.

> A.2
>     o  Leakage of traffic into PCN-domain: ECT(1) is less often
correct.
> - This does not make seem to make sense.
> 
> {TM} can't remember why we worked that out but it seemed to make sense
at
> the time... However I have tried to re-phrase this.
>
** Not sure this really answers the question. You seem already to have
reasons, if you can not clarify this, could you consider omitting it?

> 
>     o  Leakage of traffic out of PCN-domainL Either ECT is equally
unsafe
>                                            ^
> - Character? /./
done.
> A.2
>     o  Incremental deployment: Either ECT is suitable as long as they
are
>                                          ^           ^^^^^^^^^^^^^^^^
> - Please insert /codepoint/ and s/as long as/, providing that the
> codepoints are/
> 
done.
> Editorial question should it be "PCN capable" or "PCN-capable"?
> 
done.

** New nits:

Please change /any otehr/ to /any other/
and in abstract: /t o/ to /to/.

S4:
/      codepoint as PCN-enabled traffic MUST have the ECN field equal to
       00./
- This relates to the outer IP header, right?

S4.3:
/   Equipment complying with the baseline PCN encoding MUST allow PCN to
    be enabled for certain Diffserv codepoints. /
- I understand this, but if this is a requirement, I should have noted
that "certain" is probably not sufficient for a manufacturer to claim
compliance. Would it be compliant if the manufacturer supported this
only one DSCP value - and if so is there any interoperability between
different vendors. Maybe I am wrong, but I would expect manufacturers to
allow configuration of these codepoints from a a range of required
codepoints?

I observe you use both the keywords: MUST and SHALL, it is worth
checking these are consistently used - or consider changing all MUST to
SHALL.

Last, at the end of section 6 you write:
" It
    should be noted that this baseline encoding effectively disables
end-
    to-end ECN except where mechanisms are put in place to tunnel such
    traffic across the PCN-domain."

- I udnerstand this, but if I was reading this as someone wanting to
preserve  normal ECN semantics, I am not sure I would clearly see what
would  happen.

If I setup a tunnel across the DS domain, then the tunneled
packets ECN behaviour would be preserved, right? However, within the PCN
domain then I would see a different ECN behaviour, which would be ...

End.