Hello,
I've reviewed this document as part of the transport area directorate's ongoing
effort to review key IETF documents. These comments were written primarily for
the transport area directors, but are copied to the document's authors for
their information and to allow them to address any issues raised. The authors
should consider this review together with any other last-call comments they
receive. Please always CC tsv-dir(_at_)ietf(_dot_)org if you reply to or
forward this review.
Generally, this is a well written document. This draft is basically ready for
publication, but has a few nits the authors might consider before publication.
And here go my comments. First a few on the content but most are purely
editorial.
CONTENT:
Section 3 says:
"If a flow LSE is present, it MUST be checked to determine whether it
carries a reserved label. If it is a reserved label the packet is
processed according to the rules associated with that reserved label,
otherwise the LSE is discarded."
However section 1.2 states:
"Note that the flow label MUST NOT be an MPLS reserved label."
Isn't that a contradiction to a certain extend. I mean, if there is a reserved
label in the flow LSE, isn't that an error and should not be processed?
section 8.4:
The second bullet in the section under: "The issues described above are
mitigated by the following two factors:". I wonder whether that isn't a bit
farfetched. I mean, in principle you suggest that customers could change e.g.
the way their applications behave to let the ingress PE to be able to better
apply the flow label. That sounds like asking a customer to change something on
their application end to have a better network connectivity.
section 8.5.
Isn't a bigger problem here that you cannot guarantee that the OAM packets
follow the same ECMP path and that violates the fate sharing requirement?
section 12:
You essentially say that the behaviour of IP packets are well defined regarding
congestion and nothing needs to be done. Other payload needs to be dealt with
by PW congestion avoidance (whatever that means). So IP packets that are not
reacting to congestion (such as UDP) are no concern but other packets with the
same behaviour are? Is that a correct reading of the text?
EDITORIAL:
Abstract:
Remove the "END" at the end.
Intro:
page 3. first para: s/equipments[RFC4385]/equipments [RFC4385]/
page 3. first para: s/times )/times)/
page 3. fourth para: s/the type PW/the type of PW/
page 3. fourth para: s/[RFC5286] ./[RFC5286]./
section 1.2:
page 5. first para: s/which knows flow LSE/which knows a flow LSE/
section 2:
s/identify flows/identifies flows/
section 4:
page 7: s/is unable process/is unable to process/
section 4.1:
page 8: s/(seeSection 11 )/(see Section 11)/
page 8: s/T= 0/T=0/
section 7:
s/Ingress and Egress PE's/ingress and egress PEs/
section 8.1:
page 12: s/past[I-D.stein-pwe3-pwbonding]/past [I-D.stein-pwe3-pwbonding]/
section 8.3:
page 12: s/An example of such a case is the of the/An example of such a case is
the one of the/ or /An example of such a case is the/
section 8.4:
Option one says: "The operator can choose to do nothing and the system will
work as it does without the flow label."
Isn't this option to not use the flow label. If so a better wording would maybe
be: "The operator can choose to do nothing, i.e. to not employ the flow label"
Option 3: 2/flows,/flows./
Why is section 9 not section 8.7? I mean it is concerned with applicability
which is what section 8 is about.
section 9:
s/This is can be regarded as/This can be regarded as/
section 10:
s/be will preceded/be preceded/
section 12:
s/multiple ECMP/multiple ECMPs/
Best,
Rolf
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3
6BL | Registered in England 2832014
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf