Re: [CCAMP] Network Assigned Upstream Label

Lou- 

Can you please be specific why you think acceptable label set only works
"rarely"? 

Thanks

Regards  Zafar

-----Original Message-----
From: "lberger@labn.net" <lberger@labn.net>
Date: Friday, February 28, 2014 3:51 PM
To: zali <zali@cisco.com>, Vishnu Pavan Beeram <vishnupavan@gmail.com>
Cc: "ccamp@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update

>Pavan,
>	I have personally seen some instances, albeit rare,  when acceptable
>label set worked, but resulting in a fair amount of added latency in LSP
>establishment.  So I can understand the instinct to optimize this.  --
>And I know your use case is different.
>
>One thing I grappled with when thinking about it at the time was to
>figure out when the downstream node can send data.  Now it's when the
>path message is received.  Your draft is silent on this point. Are you
>assuming use of ResvConf as some have in the past? I think this is a
>pretty important/fundamental point to address.
>
>Lou
>
>On 02/28/2014 03:36 PM, Zafar Ali (zali) wrote:
>> Hi Pavan- 
>> 
>> This is an academic optimization. What we can do is to write a BCP or
>> info draft based on method already documented in RFC3473 and wson
>> signaling. 
>> 
>> Thanks
>> 
>> Regards  Zafar
>> 
>> From: Vishnu Pavan Beeram <vishnupavan@gmail.com
>> <mailto:vishnupavan@gmail.com>>
>> Date: Friday, February 28, 2014 2:20 PM
>> To: "lberger@labn.net <mailto:lberger@labn.net>" <lberger@labn.net
>> <mailto:lberger@labn.net>>
>> Cc: "ccamp@ietf.org <mailto:ccamp@ietf.org>" <ccamp@ietf.org
>> <mailto:ccamp@ietf.org>>
>> Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update
>> 
>>     @Lou - Thanks for lending some direction to this thread (it was
>>     going in cycles).
>> 
>>     Zafar/Giovanni,
>> 
>>     Do you agree that wrt alien wavelengths, "signaling a setup request
>>     without knowing what upstream-label to use" is not some remote
>>     special case?
>>     Yes or No?
>> 
>>     Regards,
>>     -Pavan
>> 
>>     On Fri, Feb 28, 2014 at 12:19 PM, Lou Berger <lberger@labn.net
>>     <mailto:lberger@labn.net>> wrote:
>> 
>> 
>>         The use of / debate on acceptable label set goes all the way
>>         back to its
>>         introduction.  It always came down to a trade off of what
>>mechanism
>>         would be sufficient for the normal ("G") cases and to what level
>>         we'd
>>         optimize for special cases.  I think the draft implicitly
>>         revisits one
>>         particular trade off decision and argues that what was once a
>>         special
>>         case is now a common case -- that should be optimized.
>> 
>>         I really think this is the first point to reach any agreement
>>on.
>> 
>>         I personally think that the use of a special or reserved
>>         upstream label
>>         is a fine way, with established precedent, to indicate such
>>special
>>         processing. (That is, if we were to decided that such is
>>         warranted in
>>         this case.)
>> 
>>         Lou
>> 
>>         On 02/28/2014 09:36 AM, Giovanni Martinelli (giomarti) wrote:
>>         > Hi John,
>>         >
>>         > yes clear,  I was just bringing back on the table discussion
>>we got on
>>         > the same problem. The second option in better (although
>>contention
>>         > window is reduced but not avoided) however we had no numbers
>>to justify
>>         >  that such optimization or  at least not so strong  reasons
>>to update a
>>         > mechanism that was proven to work.
>>         >
>>         > Cheers
>>         > G
>>         >
>>         >
>>         > On 28 Feb 2014, at 14:10, John E Drake <jdrake@juniper.net
>><mailto:jdrake@juniper.net>
>>         > <mailto:jdrake@juniper.net <mailto:jdrake@juniper.net>>>
>>wrote:
>>         >
>>         >> Giovanni,
>>         >>
>>         >> Use of acceptable doubles the signaling overhead and opens
>>up a
>>         >> contention window:
>>         >>
>>         >> 1)      Path
>>         >> 2)      Path_err w/ acceptable label
>>         >> 3)      Contention window
>>         >> 4)      Path w/ acceptable label
>>         >> 5)      Resv
>>         >>
>>         >> Versus:
>>         >>
>>         >> 1)      Path w/ downstream assigned label request
>>         >> 2)      Resv w/ downstream assigned label
>>         >>
>>         >> Also, it¹s generally considered a bad idea to include error
>>messages
>>         >> in the normal operation of a protocol
>>         >>
>>         >> Yours Irrespectively,
>>         >>
>>         >> John
>>         >>
>>         >> *From:* CCAMP [mailto:ccamp-bounces@ietf.org
>><mailto:ccamp-bounces@ietf.org>] *On
>>         Behalf Of *Giovanni
>>         >> Martinelli (giomarti)
>>         >> *Sent:* Friday, February 28, 2014 4:54 AM
>>         >> *To:* Vishnu Pavan Beeram
>>         >> *Cc:* ccamp@ietf.org <mailto:ccamp@ietf.org>
>><mailto:ccamp@ietf.org
>>         <mailto:ccamp@ietf.org>>
>>         >> *Subject:* Re: [CCAMP] Network Assigned Upstream Label -
>>Draft Update
>>         >>
>>         >> Hi Vishnu,
>>         >>
>>         >> On 28 Feb 2014, at 13:26, Vishnu Pavan Beeram
>><vishnupavan@gmail.com <mailto:vishnupavan@gmail.com>
>>         >> <mailto:vishnupavan@gmail.com
>><mailto:vishnupavan@gmail.com>>> wrote:
>>         >>
>>         >>
>>         >>     (2) The use of Label-Set/Acceptable Label-Set was meant
>>to be used
>>         >>     for exceptions. Using it always for every setup request
>>is a
>>         >>     compromised solution.
>>         >>
>>         >>
>>         >>
>>         >> At the time we discussed the wson signaling
>>         >> 
>>(http://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling-06), the
>>         >> acceptable label set was considered good enough. Not sure it
>>comes
>>         >> into play at every request since your label_set should have
>>reasonably
>>         >> good labels.
>>         >>
>>         >> Cheers
>>         >> G
>>         >
>>         >
>>         >
>>         > _______________________________________________
>>         > CCAMP mailing list
>>         > CCAMP@ietf.org <mailto:CCAMP@ietf.org>
>>         > https://www.ietf.org/mailman/listinfo/ccamp
>>         >
>> 
>>         _______________________________________________
>>         CCAMP mailing list
>>         CCAMP@ietf.org <mailto:CCAMP@ietf.org>
>>         https://www.ietf.org/mailman/listinfo/ccamp
>> 
>> 
>