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

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 27 Mar 2009 11:20:21 -0700

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.

- 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?).

- I found Table 2 hard to understand, then discovered there were some 
encodings missing.

- I think the security considerations could be improved.

- To me, Appendix A.2 seems reasonable.

----------------------
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].

Abstract
" below the physical link rate." - This seems very odd to me, I thought 
this was about the link 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).

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.

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?

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.

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?

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?

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

S4
            to prevent any possible future compatability issues.
- remove /any/ - or are sure?

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.

S4
       packet MUST be treated as if it were NM.
                                      ^^^^^^
- as if it carried the NM marking?

S4
End 4.0 has a truncated sentence

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.

An additional constraint is the need to minimise
    the use of DiffServ codepoints as
                                   ^^
-English? - because?

S4.1
    The encoding scheme above seems to meet all these constraints and
- is this WG consensus, or author's?

S4.2
    Enabling PCN for a DSCP switches on PCN marking behaviour for packets
                       ^^^^^^^^^^^^^
- Better phrase here?

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?

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.

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/?

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?)

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.

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.

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.

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 theer better language that could be chosen?

S11
- Should be removed by RFC-Ed?

S12: Refs.
- Are there no normative architecture specifications to define what PCN 
is? - Seems odd for a PS, could this be [pcn-arch].

S12: Refs.
- Why is RFC3168 also not normative?

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.

- 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?

A.2
    o  Leakage of traffic into PCN-domain: ECT(1) is less often correct.
- This does not make seem to make sense.

    o  Leakage of traffic out of PCN-domainL Either ECT is equally unsafe
                                           ^
- Character? /./

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/

Editorial question should it be "PCN capable" or "PCN-capable"?

---

From: <[email-masked]>
Date: Fri, 27 Mar 2009 22:19:23 -0000

Hi Gorry,
 
Thanks for the comments. I will try to address all of them when I submit the next version... Hope to get this done in next few weeks...
 
Toby

________________________________

From: Gorry Fairhurst [mailto:[email-masked]]
Sent: Fri 3/27/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

Gorry

General comments:

----------------------
Specific comments:

Abstract

Abstract

Abstract

S1

S1

S1

S3, bullet 2

S3:

S3:

S3:

S3:

S4:

S4

S4

S4

S4

S4

4.1 says:

S4.1

S4.2

S4.2

S4.2

S5

S5

S5

S8

S8
   However there is a

S8

S9

S11

S12: Refs.

S12: Refs.

A.1

A.2

A.2