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

[Igor Bryskin <[e-mail]>]

Lou,
Please, see in-line.

Igor

> 	Perhaps it would be useful to refocus a moment on the specific limitations the draft is focusing on.
> 
> There's no question that 3473 made certain choices based on expected 
> uses and probabilities that may not hold, but we do need to be careful 
> when changing fundamentals of the protocol (e.g. moving away from the 
> use of the upstream label object as the basic object that indicates a 
> bidirectional LSP.)
> 
> IB>> There is no intention to do so.
> 

I think you have proposed at least a couple of pretty major changes, but if we focus on these details, we risk missing the main point -- so I'd like to leave this until there is understanding, and perhaps agreement on the requirement.

IB>> Which in your opinion of proposed changes may cause problems for existing deployments?

> So is it fair to say that the main limitation that the draft is trying to address is the inability to support downstream selection of upstream labels?
> 
> IB>> Correct. Considering that both directions are equally important
> for the LSP user, it does not make much sense to have different tools 
> to negotiate labels in each direction.
> 

Minimizing mechanisms / avoiding duplication is always a good design objective.  Of course, this also means that if there is a defined mechanism we should avoiding changing it unless there's good reason, e.g., it's broken.

IB>> This depends on the definition of "broken". I hope you agree that the whole business with the upstream label is meaningful only if one assumes that for a given bidirectional G- LSP labels for the forward and reverse directions do not match necessarily. This IMHO is a correct assumption even for WDM layer and also in accordance with RFC3473 addressing other layers as well. But if one makes such an assumption, one also has to assume that there could be distinct acceptable label sets in the forward and reverse directions. Let assume that ingress UNI-C likes labels 1,3,5,7,.... In forward direction and 2,4,6,8,... in reverse direction. When the UNI-C originates Path message, it specifies, for example:
Suggested DS label : 1; DS label set: 1,3,5,7,....; US label: 2
Let's assume that the network sets up the tail of the LSP with DS label = 3, and US label=7 (i.e. it cannot accommodate label 2 for whatever reason). According to RFC3473 UNI-N will send PathErr with the acceptable upstream label set consisting of exactly one label 7. Please, note that UNI-N in case of the WDM layer will always provide exactly one label in the acceptable upstream label set - the one which is already reserved by the network and egress UNI-C for this LSP. All other labels that might be available at the time of the path computation are not reserved and hence could be taken by other LSPs. The question is *what the ingress UNI-C is supposed to do with the signaled acceptable label 7, which is not acceptable for the ingress UNI-C as an upstream label?* It will have no other choice but to tear down the established G-LSP and to try it again, guessing another upstream label, e.g. 4. This potentially very lengthy ping-pong process will repeat itself until the ingress UNI-C either guesses correctly or runs out of guesses. Although it could take an hour to complete the process, technically the approach is not broken, however, unacceptable if compared to the one signaling round approach suggested in the draft.  

> But there are other limitations as well. See below.
> 
> The draft also allows for both symmetric and asymmetric label value allocation.  IS this a requirement, or asymmetric just included for completeness?
> 
> IB>> Even in case of WDM layer there are scenarios (e.g. single-fiber
> configurations) when the same wavelength cannot be used for both 
> directions. For non-WDM layer it is perfectly OK to use 
> label-asymmetrical LSPs. So we do want to maintain both options.
> 

okay. it is good to differentiate desirable vs required capabilities.

> Are there other requirements / limitations you are trying to address?
> IB>> Today there is no way to *require* a bi-directional LSP to be label-symmetrical.

True.  This has always been a local allocation policy.  It's probably worth describing in greater detail why you see it needs to be changed.

IB>> As John and Pavan mentioned many times already, for a UNI-C (e.g. router) in the majority of the cases it is required for upstream/downstream labels to be the same. It cannot afford to rely on the UNI-N local policies, which for whatever reason (e.g. existence of uni-directional P2P or P2MP G-LSPs) may locally decide to assign different labels. The point is that UNI-C has no way today to *request* the label symmetricity.  

Thanks,
Lou
> 
> 
> Lou
> 
> On 11/04/2013 01:24 PM, John E Drake wrote:
>> 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
>>>
>>
>>
>> _______________________________________________
>> CCAMP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ccamp
>>
> 
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
> 
> 
> 
>