Subject: [Gen-art] Gen-ART LC review: draft-ietf-pwe3-fat-pw-06

From: Mary Barnes <[email-masked]>
Date: Wed, 18 May 2011 13:10:53 -0500

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at <
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you
may receive.

Document: draft-ietf-pwe3-fat-pw-06
Reviewer:  Mary Barnes
Review Date:  18 May 2011
IETF LC End Date:  20 May 2011

Summary:  Almost ready

Minor issues/suggestions:

- Section 1.2 - While the 3rd paragraph notes that the TTL is described in
the security section I think a bit more text might be helpful as I could not
understand why the fact that the TTL in the flow LSE is never used to
determine whether a packet should be discarded, introduces restrictions on
the TTL value.  Certainly, the relevant text is in the security section,
however, it's very little text and I personally think a backward reference
in the security section to an earlier section in the document is often more
helpful than a forward reference.  Also, it's not clear to me what that
issue has to do with security - what is the security issue that is addressed
by this choice of TTL?

- Section 7, 3rd paragraph: What are the circumstances referenced in the 1st
sentence? I assume it's referring to the method of load balancing described
in this document rather than the situation described in the previous
paragraph or perhaps it's both   It might be more clear to include the 2nd-
 paragraphs as bullets so it's clear they are relating to the method of load
balancing in this document and are not related.

- Section 8.3, 1st paragraph, last sentence:  This sentence does not make
sense:
   An example of such a case is
   the of the flow label mechanism in networks using a link bundle with
   the all ones component [RFC4201].
There's a word missing here: "the ? of the flow label mechanism".
Also, the "with all ones component" phrase was unclear.  I assumed it was
referring to some functionality in RFC 4201.  I think it would be much
clearer to say "the special bit value of all ones" since the "ones
component" terminology is not used in RFC 4201.

- Section 9: This section lacks clarity. In the first sentence it might be
helpful to qualify "this technique" as "the technique described in this
document".  Also, by further application, do you mean "an additional
application of this technique" or "an extension of this technique" (I've
assumed the latter in my suggested rewrite below).
The second sentence has a "this" that it's not clear to what it's referring
- I think it's referring to the "further application of this technique".
The third sentence also has a "this" that I think is referring to the "work
on the generalization" which is described in the referenced draft.  And this
construct in the third sentence is not at all clear  "…can be regarded as a
complementary, but distinct, approach since similar although consideration
may apply…"
Is this saying that the generalization of this to MPLS described in the
draft is complementary, but distinct from the technique described in this
document?  If so, perhaps, the following suggestion can clarify this
section.
   An extension of this technique is to create a basis
   for hash diversity without having to peek below the label stack for
   IP traffic carried over LDP LSPs.
   The generalisation of this extension to MPLS has been
   described in [I-D.kompella-mpls-entropy-label].
   This generalization can be regarded as a complementary, but distinct,
   approach from the technique described in this document.
   While similar consideration may apply to the identification
   of flows and the allocation of flow label values, the flow labels are
   imposed by different network components, and the associated
   signalling mechanisms are different.

Nits:

- There's a stray END at the end of the abstract to the far right.
- Section 1, first sentence:  exit -> exist
- Section, 2nd para, 3rd sentence: hundred's -> hundreds

---

From: Mary Barnes <[email-masked]>
Date: Wed, 18 May 2011 13:16:41 -0500

Resending due to wrong alias in my first email =============>

Summary:  Almost ready

Nits: