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