Re: [CCAMP] Comments about draft-beeram-ccamp-network-assigned-upstream-label-00

[John E Drake <[e-mail]>]

Zafar,

Both Igor and I have listed technical issues with RFC3473 and your response is that you really really like RFC3473.  I'm happy for you but unimpressed.

John

Sent from my iPhone

On Nov 4, 2013, at 9:43 AM, "Zafar Ali (zali)" <[e-mail]<mailto:[e-mail]>> wrote:

Igor, John-

Please see in-line.

From: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Monday, November 4, 2013 8:57 AM
To: zali <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: Comments about draft-beeram-ccamp-network-assigned-upstream-label-00

Zafar,
1)  Using an error indication as a part of normal protocol operation is not good design practice.
Use of Path error and notify message is an integral part of the RSVP-TE design. Also please note that we are not debating about a new procedure being proposed but talking about a procedure that is already implemented and deployed.

IB>> The way I interpret this discussion is something like this:

John: I believe that white is a lighter color than black.
Zafa: Well, John, black is an integral part of the color pallet. Many mature applications successfully use black for their various purposes. My implementations, for example, use black for pretty much everything….. So, it is not clear which color is lighter, and why do we need other colors at all. :=)

I mean to say that your, Zafar, comments IMHO are not constructive technical arguments.
Igor

Hi Igor and John:

This is really funny. This is the first time I have heard that running code has no merit at IETF :) This is especially when the running code is directly coming from RFC3473. You are calling it "not constructive technical arguments"! Last I heard we believed in running code (See your T-shirt from the election day from IETF Atlanta).

Your draft is ONLY applicable for a use case where upstream and downstream alien wavelength are different. When upstream and downstream alien wavelength are same, use of acceptable label set and label set objects constitute the running code. However, your draft neither makes that applicability statement nor makes any mention or cover or reference to procedure I quoted from RFC3473.

Thanks

Regards…Zafar



From: Zafar Ali (zali) [mailto:[e-mail]]
Sent: Monday, November 04, 2013 1:51 AM
To: John E Drake; Igor Bryskin
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: Comments about draft-beeram-ccamp-network-assigned-upstream-label-00

Hi John:

Please see in-line.

Thanks

Regards … Zafar

From: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Sunday, November 3, 2013 11:57 AM
To: zali <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: Comments about draft-beeram-ccamp-network-assigned-upstream-label-00

Zafar,
That because this already defined method has the following issues:
1)  Using an error indication as a part of normal protocol operation is not good design practice.
Use of Path error and notify message is an integral part of the RSVP-TE design. Also please note that we are not debating about a new procedure being proposed but talking about a procedure that is already implemented and deployed.
2)  Acceptable Label Set is optional so its presence is not guaranteed
So is the case of newly defined upstream label set. Also please note that many part of the RSVP-TE protocol are designed using optional objects.
3)  The information it provides may be out of date by the time the LSP is re-signaled.
This is an implementation issue. A node sending the acceptable label set has the responsibility to guarantee that information provides in the acceptable label set remains valid for re-signaling time. E.g., UNI-N implementation can cache the label for the re-signaling time.
4)  Most importantly, Acceptable Label Set is generated hop by hop, unlike Upstream Label Set which exercises the entire path.  This means that its use to determine a valid wavelength would require a potentially unbounded number of crankbacks, both single and multi-hop, with no guarantee that such a wavelength could be found.
In the use case of align wavelength addressed in this draft, the acceptable label set communication is restricted to the UNI-C and UNI-N node.
Yours Irrespectively,

John

From:[e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Zafar Ali (zali)
Sent: Sunday, November 03, 2013 8:12 AM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [CCAMP] Comments about draft-beeram-ccamp-network-assigned-upstream-label-00

Hi Igor and co-authors-

Please note that [RFC3473] already considers the case where upstream label may not be acceptable to a downstream node. Specifically, [RFC3473] states that:
"when a Path message containing an Upstream_Label object is received, the receiver first verifies that the upstream label is acceptable. If the label is not acceptable, the receiver MUST issue a PathErr message with a "Routing problem/Unacceptable label value" indication. The generated PathErr message MAY include an Acceptable Label Set Object".
Acceptable_Label_Set objects may be carried in PathErr and ResvErr messages [RFC3473].

However, your draft does not mention or cover this already defined method.

Thanks

Regards … Zafar