[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,
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
> >
> >
> >
> >
> >
> >