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

[Lou Berger <[e-mail]>]

Pavan,
	I agree that there are existing mechanisms *could* be used, but your
document is changing the data place service model so it is the one that
needs to specify the new model...

Lou


On 02/28/2014 04:12 PM, Vishnu Pavan Beeram wrote:
> Lou, Hi!
> 
> The initial version (00) had some details illustrating when the
> downstream node can send data. But we stripped that out in the current
> version because it seemed more of an implementation detail. 
> 
> Implementations may choose to use "Resv Conf" (as you mentioned) or a
> 2-step graceful setup procedure using ADMIN_STATUS (start with the A bit
> set; clear it when the LSP is ready for use). Either approach doesn't
> need any new protocol extensions.
> 
> Regards,
> -Pavan
> 
> 
> On Fri, Feb 28, 2014 at 3:51 PM, Lou Berger <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
>     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 <[e-mail]
>     <mailto:[e-mail]>
>     > <mailto:[e-mail] <mailto:[e-mail]>>>
>     > Date: Friday, February 28, 2014 2:20 PM
>     > To: "[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>"
>     <[e-mail] <mailto:[e-mail]>
>     > <mailto:[e-mail] <mailto:[e-mail]>>>
>     > Cc: "[e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>" <[e-mail] <mailto:[e-mail]>
>     > <mailto:[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]>
>     >     <mailto:[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]>>
>     >         > <mailto:[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]> <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]>>
>     <mailto:[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]>>
>     >         >> <mailto:[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]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>     >         > https://www.ietf.org/mailman/listinfo/ccamp
>     >         >
>     >
>     >         _______________________________________________
>     >         CCAMP mailing list
>     >         [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>     >         https://www.ietf.org/mailman/listinfo/ccamp
>     >
>     >
> 
>