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
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
