Rolf
Thank you for the review
On 19/05/2011 14:24, Rolf Winter wrote:
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 1.2 is saying that the flow label generator MUST NOT generate
and apply a reserved label.
Section 3 is saying that if there is a label put in that position it
must have been
put there by some application that wanted a diagnostic so process it.
The intent is careful what you send, liberal with what you receive.
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.
This is dealing with the single large flow case. There is no way to load
balance a single large flow at the speeds we need to operate and at the
price performance point needed. This is noting that the customer needs
to help out.
Clearly if the user is unable to modify their application they get the
performance they get, and indeed risk running foul of ingress policing
by the provider.
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?
I added:
"In addition MPLS-TP makes extensive use of the fate sharing between OAM
and data packets, which is defeated by the flow LSE."
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?
Yes. The PW assumes that all IP packets are as well behaved as the IETF
requires them to be. It is not the job of PWE3 to specify or influence
the congestion behavior of IP packets, we just carry them as a "wire" would.
section 2:
s/identify flows/identifies flows/
I am not sure. Let's leave it to RFCed.
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"
The point is that the operator would prefer for their own reasons to see
load balancing so they probably want to turn it on and hope that at some
future stage the user modifies their profile to the mutual benefit of
user and provider.
The do nothing refers to taking no further action.
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.
PWS are not LSPs and there is work on this WRT LSPs in MPLS WG. This is
a heads up that this other work is happening, that both parties are
aware of what the other is doing. It seems reasonable to put it in its
own section.
section 9:
s/This is can be regarded as/This can be regarded as/
This section was re-written following genart f/b from Mary Barns.
Regards
Stewart
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf