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

From: Stewart Bryant <[email-masked]>
Date: Wed, 06 Jul 2011 14:22:18 +0100

Mary

Thank you for the review

Unless I comment here I have fixed as per your suggestion.
>
> 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?
>
The text in section 1.2 now says:

It is useful to give consideration to the choice of TTL value in the 
flow LSE [RFC3032]
The flow LSE is at the bottom of label stack, therefore, even when 
penultimate hop popping is employed, it will always be will preceded by 
the PW label on arrival at the PE. If, due to an error condition the 
flow LSE becomes top of stack it might be examined as if it were a 
normal LSE, and the packet might then be forwarded. This can be 
prevented by setting the flow LSE TTL to 1, thereby forcing the packet 
to be discarded by the forwarder. Note that this may be a departure from 
considerations that apply to the general MPLS case.

and in the Security section:

Section 1.2 describes considerations that apply to the TTL value used in 
the flow LSE. The use of a TTL value of one prevents the accidental 
forwarding of a packet based on the label value in the flow LSE.
> - 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.
I concatenated the 2nd and 3rd paras which I think fixes the problem.

>
> - 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".
Fixed the English
> 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.

Here is where the term "all ones" comes from

For TLV types 1 and 2, this is done
by using the special bit value of all ones (1) (e.g., 0xFFFFFFFF for
a type 1 TLV).  Per [RFC3471], for TLV types 3, 4, and 5, this is
done by setting the Interface ID field to the special value
0xFFFFFFFF.

... and this seems to the name people use.

- Stewart