[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [CCAMP] draft-ietf-ccamp-gmpls-g-694-lambda-labels and unique resource identification
Hi Lou,
Sounds like the logical choice.
Thanks for trying to explain the restart scenario.
Cheers,
Anders
> -----Original Message-----
> From: Lou Berger [mailto:lberger at labn.net]
> Sent: den 4 november 2009 22:26
> To: Anders Gavler
> Cc: Greg Bernstein; ccamp at ietf.org
> Subject: Re: [CCAMP] draft-ietf-ccamp-gmpls-g-694-lambda-labels and unique
> resource identification
>
> Anders,
> What I'm saying is that up until now GMPLS has supported labels
> that
> allow a node (based on it's local value allocation policy, or fixed TDM
> slots) to uniquely map from a label back to internal transport
> resources. The current draft breaks this. IMO there are two options:
> (a) accept this (model) change, or
> (b) fix the draft.
>
> I'm in favor of (b) particularly as there are some straight forward
> solutions to this.
>
> Lou
> On 11/4/2009 1:19 PM, Anders Gavler wrote:
> > Hi Lou,
> >
> > Are you saying that there is no way to store and/or access this type of
> information in a good enough way and this is the reason why you need it at
> a restart event (re-signalling), or are you saying that you would need it
> anyway?
> >
> > Cheers,
> > Anders
> >
> >> -----Original Message-----
> >> From: Lou Berger [mailto:lberger at labn.net]
> >> Sent: den 3 november 2009 20:36
> >> To: Anders Gavler
> >> Cc: Greg Bernstein; ccamp at ietf.org
> >> Subject: Re: [CCAMP] draft-ietf-ccamp-gmpls-g-694-lambda-labels and
> unique
> >> resource identification
> >>
> >> Anders,
> >> See below.
> >>
> >> On 11/3/2009 1:55 PM, Anders Gavler wrote:
> >>> Lou,
> >>>
> >>> I still do not get it.
> >>>
> >>> As long as a node uniquely can identify an LSP that starts, ends, or
> >> transits this node it should also be able to uniquely map which local
> >> resources the LSP corresponds to (e.g. tunable or non-tunable
> transponder,
> >> wavelength, ports etc).
> >>>
> >>
> >> How does one specify use of a particular laser from an upstream node?
> >> Today that is done using label in ERO.
> >>
> >>> If this is true I do not see why the label needs to directly map to a
> >> certain laser since they both can map to a uniquely identifiable LSP
> and
> >> this information could be stored and used at restart.
> >>>
> >>
> >> So what happens when the node losses all/some state?
> >>
> >> Lou
> >>
> >>> /Anders
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: ccamp-bounces at ietf.org [mailto:ccamp-bounces at ietf.org] On
> Behalf
> >> Of
> >>>> Lou Berger
> >>>> Sent: den 3 november 2009 18:58
> >>>> To: Greg Bernstein
> >>>> Cc: ccamp at ietf.org
> >>>> Subject: Re: [CCAMP] draft-ietf-ccamp-gmpls-g-694-lambda-labels and
> >> unique
> >>>> resource identification
> >>>>
> >>>> Greg,
> >>>> In the cases I'm referring to we're talking per node resource
> >>>> information which typically has node (pair) local scope with the
> >>>> exception of ERO and RROs. So no, I don't think an end-to-end LSP
> >>>> attribute is a match.
> >>>>
> >>>> Lou
> >>>>
> >>>> On 11/3/2009 12:50 PM, Greg Bernstein wrote:
> >>>>> Lou, do you think this information is better in a label or in some
> >> kind
> >>>>> of LSP attribute? In the WSON compatibility draft we tentatively put
> >>>>> similar information into a new ERO subobject for attributes. Those
> >>>>> attributes included things like modulation format, FEC, and whether
> >>>>> regeneration should occur at a node along the path. We didn't put
> them
> >>>>> with the traffic descriptor since they can change along a path. I
> >> didn't
> >>>>> think we should put them into labels... But I'm flexible.
> >>>>>
> >>>>> Regards
> >>>>>
> >>>>> Greg
> >>>>>
> >>>>> Lou Berger wrote:
> >>>>>> Jonas,
> >>>>>> A very good question! In the common/general setup case I think
> >>>> it
> >>>>>> won't matter. But there are cases where it may:
> >>>>>>
> >>>>>> - In GMPLS we have a precedent of being able to use the label to
> >>>>>> represent a specific physical resource, be it a time slot,
> frequency
> >> or
> >>>>>> even port. If we assume that this is a function worth preserving
> >> (and
> >>>> I
> >>>>>> believe it is, at least with today's equipment) than it is
> >>>>>> desirable/required to be able to use GMPLS to control a specific
> >> laser.
> >>>>>> Even a tunable one. With the current definition, this isn't
> >> possible.
> >>>>>>
> >>>>>> - The more practical/import case is graceful restart. In certain
> >>>>>> restart cases, the restarting node may need to match particular
> node
> >>>>>> resources (e.g., tunable lasers) against a particular frequency to
> >>>>>> ensure no data loss and the restarting node may no longer have the
> >>>>>> information to do the matching. In all other cases that I know
> about,
> >>>>>> GMPLS allows for sufficient information for a node to reconstruct
> >> this
> >>>>>> mapping.
> >>>>>>
> >>>>>> - MP to CP handover may also need to identify specific node
> resources
> >>>>>> (e.g., tunable lasers).
> >>>>>>
> >>>>>> I believe these are the primary cases.
> >>>>>>
> >>>>>> I hope this helps,
> >>>>>> Lou
> >>>>>>
> >>>>>> On 11/2/2009 5:35 AM, Jonas Mårtensson wrote:
> >>>>>>
> >>>>>>> Lou,
> >>>>>>>
> >>>>>>> Maybe this is a silly question but if all lasers in the system are
> >>>> tunable, why does it matter which one is used? Can't the node decide
> >> this
> >>>> locally?
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Jonas
> >>>>>>>
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: ccamp-bounces at ietf.org [mailto:ccamp-bounces at ietf.org]
> >>>>>>>> On Behalf Of Lou Berger
> >>>>>>>> Sent: den 30 oktober 2009 14:02
> >>>>>>>> To: Richard Rabbat
> >>>>>>>> Cc: ccamp at ietf.org
> >>>>>>>> Subject: Re: [CCAMP]
> >>>>>>>> draft-ietf-ccamp-gmpls-g-694-lambda-labels and unique
> >>>>>>>> resource identification
> >>>>>>>>
> >>>>>>>> Richard,
> >>>>>>>>
> >>>>>>>> Okay let me try again with a specific case. If I have an rro
> >>>>>>>> or ero that identifies the label (lambda) per your document,
> >>>>>>>> how does a node know which laser the label corresponds to
> >>>>>>>> when all lasers in the system are tunable?
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>> Lou
> >>>>>>>>
> >>>>>>>> On 10/29/2009 2:22 PM, Richard Rabbat wrote:
> >>>>>>>>
> >>>>>>>>> sorry for the lag.
> >>>>>>>>> do you want to describe your use-case further in terms of what
> you
> >>>>>>>>> can't do and your proposed change?
> >>>>>>>>> thanks,
> >>>>>>>>> Richard.
> >>>>>>>>>
> >>>>>>>>> On Thu, Oct 15, 2009 at 8:53 AM, Lou Berger <lberger at labn.net
> >>>>>>>>> <mailto:lberger at labn.net>> wrote:
> >>>>>>>>>
> >>>>>>>>> Authors,
> >>>>>>>>> Have you given any additional thought on the
> >>>>>>>>>
> >>>>>>>> repesentation of
> >>>>>>>>
> >>>>>>>>> tunable
> >>>>>>>>> lasers (and unique resource identification) beyond what
> >>>>>>>>>
> >>>>>>>> is currently in
> >>>>>>>>
> >>>>>>>>> the draft? The current text is:
> >>>>>>>>> If the node has a tunable wavelength transponder, the
> tuning
> >>>>>>>>> wavelength is considered as a part of wavelength switching
> >>>>>>>>> operation.
> >>>>>>>>>
> >>>>>>>>> In the past, labels used for TE LSPs always represented
> >>>>>>>>>
> >>>>>>>> a specific
> >>>>>>>>
> >>>>>>>>> resource that is uniquely identifiable by the node that
> >>>>>>>>>
> >>>>>>>> allocates the
> >>>>>>>>
> >>>>>>>>> label and resource. Such unique identification is
> >>>>>>>>>
> >>>>>>>> important/required
> >>>>>>>>
> >>>>>>>>> for certan restart and other corner cases. Your current
> >>>>>>>>>
> >>>>>>>> definition works
> >>>>>>>>
> >>>>>>>>> fine for fixed lasers that can only be mapped to a
> >>>>>>>>>
> >>>>>>>> single fiber. But,
> >>>>>>>>
> >>>>>>>>> the defined global label will not uniquely identify a
> >>>>>>>>>
> >>>>>>>> resource on a node
> >>>>>>>>
> >>>>>>>>> when (a) tunable lasers are used, or (b) when a node
> >>>>>>>>>
> >>>>>>>> supports multiple
> >>>>>>>>
> >>>>>>>>> fixed lasers that can be (optically) switched to a
> >>>>>>>>>
> >>>>>>>> particular output
> >>>>>>>>
> >>>>>>>>> interface.
> >>>>>>>>>
> >>>>>>>>> What are your thoughts on how to provide such link-scoped
> >> unique
> >>>>>>>>> resource identification in the context of your draft?
> >>>>>>>>>
> >>>>>>>>> I don't think it'll be too difficult to address this
> >>>>>>>>>
> >>>>>>>> critical point, and
> >>>>>>>>
> >>>>>>>>> see a couple of straightforward solutions if you'd like
> >>>>>>>>>
> >>>>>>>> to discuss
> >>>>>>>>
> >>>>>>>>> off-line.
> >>>>>>>>>
> >>>>>>>>> Much thanks,
> >>>>>>>>> Lou
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> CCAMP mailing list
> >>>>>>>>> CCAMP at ietf.org <mailto:CCAMP at ietf.org>
> >>>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> CCAMP mailing list
> >>>>>>>> CCAMP at ietf.org
> >>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> _______________________________________________
> >>>>>> CCAMP mailing list
> >>>>>> CCAMP at ietf.org
> >>>>>> https://www.ietf.org/mailman/listinfo/ccamp
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> --
> >>>>> ===================================================
> >>>>> Dr Greg Bernstein, Grotto Networking (510) 573-2237
> >>>>>
> >>>>>
> >>>> _______________________________________________
> >>>> CCAMP mailing list
> >>>> CCAMP at ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/ccamp
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >
> >
> >
> >
> >
> >