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@ietf.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