Re: [CCAMP] Network Assigned Upstream Label

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 <lberger@labn.net> 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 <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(tm) 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
> >
> >
>
>