Re: [CCAMP] Network Assigned Upstream Label

Zafar, Hi!

You still haven't answered my question. It needs a simple yes/no answer.

Do you agree that wrt alien wavelengths, "signaling a setup request without
knowing what upstream-label to use" is not some remote special case?

Regards,
-Pavan

On Fri, Feb 28, 2014 at 3:36 PM, Zafar Ali (zali) <zali@cisco.com> 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>
> Date: Friday, February 28, 2014 2:20 PM
> To: "lberger@labn.net" <lberger@labn.net>
> Cc: "ccamp@ietf.org" <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> 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>> 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(tm) to include error messages
>> >> in the normal operation of a protocol
>> >>
>> >> Yours Irrespectively,
>> >>
>> >> John
>> >>
>>  >> *From:* CCAMP [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>
>> >> *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>> 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
>> > https://www.ietf.org/mailman/listinfo/ccamp
>> >
>>
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org
>> https://www.ietf.org/mailman/listinfo/ccamp
>>
>
>