Re: [CCAMP] Network Assigned Upstream Label - Draft Update

["Zafar Ali (zali)" <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>>
Date: Friday, February 28, 2014 2:20 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>
> <mailto:[e-mail]<mailto:[e-mail]>>> 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:[e-mail]<mailto:[e-mail]>] *On Behalf Of *Giovanni
>> Martinelli (giomarti)
>> *Sent:* Friday, February 28, 2014 4:54 AM
>> *To:* Vishnu Pavan Beeram
>> *Cc:* [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
>> *Subject:* Re: [CCAMP] Network Assigned Upstream Label - Draft Update
>>
>> Hi Vishnu,
>>
>> On 28 Feb 2014, at 13:26, Vishnu Pavan Beeram <[e-mail]<mailto:[e-mail]>
>> <mailto:[e-mail]<mailto:[e-mail]>>> 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
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/ccamp
>

_______________________________________________
CCAMP mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ccamp