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

[Vishnu Pavan Beeram <[e-mail]>]

Lou,

OK. We'll add some text ("informational" section) in the next version
detailing how existing mechanisms can be used to let the downstream node
know when the LSP is operational.

Regards,
-Pavan



On Fri, Feb 28, 2014 at 4:33 PM, Lou Berger <[e-mail]> wrote:

> 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(tm) 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
> >     >
> >     >
> >
> >
>
>