Subject: Re: [CCAMP] draft-ietf-ccamp-gmpls-g-694-lambda-labels and unique resource identification

From: Greg Bernstein <[email-masked]>
Date: Sun, 01 Nov 2009 08:28:46 -0800

Hi Lou and Richard,
I think a related example that came up in a discussion at a previous 
CCAMP was of identifying a specific regenerator or wavelength converter 
used at a particular node. I would think that there could be a "tight 
binding" between a regenerator or wavelength converter and the laser.
In the latest  "compatibility draft 
<http://www.ietf.org/id/draft-bernstein-ccamp-wson-compatibility-01.txt>" 
and updated "signaling draft 
<http://tools.ietf.org/html/draft-bernstein-ccamp-wson-signaling-05>" we 
start to identify extensions for specifying regeneration at a particular 
node via additional signaling attributes.

We initially kept this stuff separate from the label, but that was  
mainly to preserve the notion of wavelengths as labels.

Best Regards

Greg

Lou Berger wrote:
> 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 <[email-masked]
>> <mailto:[email-masked]>> 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
>>     [email-masked] <mailto:[email-masked]>
>>     https://www.ietf.org/mailman/listinfo/ccamp
>>
>>
>>     
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
>
>
>   

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

---

From: Jonas Mårtensson <[email-masked]>
Date: Mon, 2 Nov 2009 11:35:28 +0100

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: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Lou Berger
> Sent: den 30 oktober 2009 14:02
> To: Richard Rabbat
> Cc: [email-masked]
> 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
> 
> > do you want to describe your use-case further in terms of what you 
> > can't do and your proposed change?
> > thanks,
> > Richard.
> >

---

From: Lou Berger <[email-masked]>
Date: Tue, 03 Nov 2009 12:39:55 -0500

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

---

From: Greg Bernstein <[email-masked]>
Date: Tue, 03 Nov 2009 09:50:01 -0800

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:
>>>>            Have you given any additional thought on the 
>>>>         
>>> repesentation of
>>>       
>>>>     tunable
>>>>     lasers (and unique resource identification) beyond what 
>>>>         
>>> is currently in
>>>       
>>>>     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.
>>>>
>>>>     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
>>>>
>>>>

---

From: Lou Berger <[email-masked]>
Date: Tue, 03 Nov 2009 12:57:52 -0500

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

---

From: Anders Gavler <[email-masked]>
Date: Tue, 3 Nov 2009 19:55:34 +0100

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). 

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. 

/Anders

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Lou Berger
> Sent: den 3 november 2009 18:58
> To: Greg Bernstein
> Cc: [email-masked]
> Subject: Re: [CCAMP] draft-ietf-ccamp-gmpls-g-694-lambda-labels and unique
> resource identification
> 
> Greg,
> >>> 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
> >>>
> >>>

---

From: Lou Berger <[email-masked]>
Date: Tue, 03 Nov 2009 14:36:06 -0500

Anders,
	See below.

> 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-tuna…

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

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 3 Nov 2009 14:39:05 -0500

Anders,

Let me try to explain this. Within a given node there could be multiple ways how an incoming interface:lambda could be cross-connected with outgoing interface: lambda:
a) transparent;
b) fixed regeneration;
c) tunable regeneration;
d) chain of tunable/fixed transponders;
e)etc.

It is quite possible that a node on its own cannot decide on what is the proper way to build the cross-connect simply because it cannot see the network-wide picture, while a centralized authority (i.e. PCE, NMS) can. For example, because of optical impairment consideration the signal should be regenerated on this node with or without wavelength conversion. Note also that it is possible that more than one tunable resources with overlapping ranges are available on a given link, and (in the roadm directionless technology) the same transponder may be available from more than one links.

You should see by now why it is paramount to be able to specify in the ERO not only link/lambda pairs but also the physical IDs of concrete transponders.

This is one reason, amother is, as Lou pointed out, restarts. Think about the situation when you restart the node and during restart procedures two LSPs are associated with wrong transponders. Then when you delete one LSP you will bring down unintentionally the other one as well.

Hope this helps.

Igor  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Anders Gavler
Sent: Tuesday, November 03, 2009 1:56 PM
To: Lou Berger; Greg Bernstein
Cc: [email-masked]
Subject: Re: [CCAMP] draft-ietf-ccamp-gmpls-g-694-lambda-labels and unique resource identification

Lou,

I still do not get it. 

/Anders

---

From: Jonas Mårtensson <[email-masked]>
Date: Tue, 3 Nov 2009 22:45:47 +0100

Hi Igor,

I understand that it is useful to be able to indicate whether  
regeneration should be performed. What was less clear to me was why it  
matters exactly which regenerator or laser is used. If I understand  
you correctly you say that one motivation is that different regens may  
have different capabilities (eg tuning range) and/or connectivity and  
therefore it could make a difference which one you use from a global  
optimization perspective. For example, if a fixed laser is available  
at the desired wavelength it might be better to use this rather than a  
tunable one in order to have more flexibility for future connections.

I'm still not clear about the restart issue though.

Thanks,
Jonas

3 nov 2009 kl. 20.40 skrev "Igor Bryskin" <[email-masked]>:

> Anders,
>
> Let me try to explain this. Within a given node there could be  
> multiple ways how an incoming interface:lambda could be cross- 
> connected with outgoing interface: lambda:
> a) transparent;
> b) fixed regeneration;
> c) tunable regeneration;
> It is quite possible that a node on its own cannot decide on what is  
> the proper way to build the cross-connect simply because it cannot  
> see the network-wide picture, while a centralized authority (i.e.  
> PCE, NMS) can. For example, because of optical impairment  
> consideration the signal should be regenerated on this node with or  
> without wavelength conversion. Note also that it is possible that  
> more than one tunable resources with overlapping ranges are  
> available on a given link, and (in the roadm directionless  
> technology) the same transponder may be available from more than one  
> links.
>
> You should see by now why it is paramount to be able to specify in  
> the ERO not only link/lambda pairs but also the physical IDs of  
> concrete transponders.
>
> This is one reason, amother is, as Lou pointed out, restarts. Think  
> about the situation when you restart the node and during restart  
> procedures two LSPs are associated with wrong transponders. Then  
> when you delete one LSP you will bring down unintentionally the  
> other one as well.
>
> Hope this helps.
>
> Igor
>
> 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).
>
> 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.
>
> /Anders
>
>
>>>> even port.  If we assume that this is a function worth preserving  
>>>> (and
>> I

---

From: Anders Gavler <[email-masked]>
Date: Wed, 4 Nov 2009 19:19:55 +0100

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

> From: Lou Berger [mailto:[email-masked]]
> Sent: den 3 november 2009 20:36
> To: Anders Gavler
> Cc: Greg Bernstein; [email-masked]
> 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).
> >
> 
> > 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.
> >
>

---

From: Anders Gavler <[email-masked]>
Date: Wed, 4 Nov 2009 19:20:58 +0100

Hi Igor,

About global optimisation I guess I can see your point, but unless these scenarios are quite common and not some corner case isn't there a risk of having to distribute too much information about the internal node structure, and the use of it, than meets the scalability requirements. E.g. using the suggested pool concepts would lead to less, but still enough (hopefully), information distributed about the resources in the network. 

Cheers,
 Anders

> From: Jonas Mårtensson
> Sent: den 3 november 2009 22:46
> To: Igor Bryskin
> Cc: Anders Gavler; Lou Berger; Greg Bernstein; [email-masked]

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 4 Nov 2009 14:42:49 -0500

Hi Anders,

Here is a couple of reasons why you need to be able to signal tun. Traspobder physical IDs.

1. Suppose, two transponders tuned to the same frequency are associated with two LSPs on a given NE. Suppose, the NE is restarted. Resync procedures will resurrect CP state for both LSPs. However, if neighboring NEs do not know about IDs of the transponders, the CP on the rebooting NE could be easily confused and associate CP states of the two LSPs with wrong transponders. If, some time later, one deletes one of the LSPs, the second LSP will be hit. Note, that this situation can be avoided if the transponder IDs are present somewhere in the RSVP Path message (e.g. in ERO) 

2. Suppose, two tun. transponders with overlapping ranges are available for two new LSPs. Suppose, LSP 1 needs to use a frequency within both ranges, while the second LSP needs to use frequency within only one of the ranges (i.e. outside of the other range). If Path message of the first LSP does not contain ID of the "right" transponder, it can easily choose the second one and block the setup of the second LSP.

Igor 

-----Original Message-----
From: Anders Gavler [mailto:[email-masked]] 
Sent: Wednesday, November 04, 2009 1:21 PM
To: Igor Bryskin
Cc: Jonas Mårtensson; Greg Bernstein; [email-masked]; Lou Berger
Subject: RE: [CCAMP] draft-ietf-ccamp-gmpls-g-694-lambda-labels and unique resource identification

Hi Igor,

Cheers,
 Anders

---

From: Lou Berger <[email-masked]>
Date: Wed, 04 Nov 2009 16:25:54 -0500

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

---

From: Anders Gavler <[email-masked]>
Date: Wed, 4 Nov 2009 22:54:32 +0100

Hi Lou,

Sounds like the logical choice. 

Thanks for trying to explain the restart scenario.

Cheers,
 Anders

> Sent: den 4 november 2009 22:26
> To: Anders Gavler
> > 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
> >
> >>>> From: [email-masked] [mailto:[email-masked]] On
> Behalf
> >> Of
> >>>> Lou Berger
> >>>>>> represent a specific physical resource, be it a time slot,
> frequency
> >> or

---

From: Anders Gavler <[email-masked]>
Date: Wed, 4 Nov 2009 23:05:45 +0100

Hi Igor,

Thanks for adding a couple of cases, especially the first one that clarifies the possible problems at a node restart. I did not anticipate that this was a likely scenario.

Cheers,
 Anders

> From: Igor Bryskin [mailto:[email-masked]]
> Sent: den 4 november 2009 20:43
> To: Anders Gavler
> 1. Suppose, two transponders tuned to the same frequency are associated
> with two LSPs on a given NE. Suppose, the NE is restarted. Resync
> procedures will resurrect CP state for both LSPs. However, if neighboring
> NEs do not know about IDs of the transponders, the CP on the rebooting NE
> could be easily confused and associate CP states of the two LSPs with
> wrong transponders. If, some time later, one deletes one of the LSPs, the
> second LSP will be hit. Note, that this situation can be avoided if the
> transponder IDs are present somewhere in the RSVP Path message (e.g. in
> ERO)
> 
> 2. Suppose, two tun. transponders with overlapping ranges are available
> for two new LSPs. Suppose, LSP 1 needs to use a frequency within both
> ranges, while the second LSP needs to use frequency within only one of the
> ranges (i.e. outside of the other range). If Path message of the first LSP
> does not contain ID of the "right" transponder, it can easily choose the
> second one and block the setup of the second LSP.
> 
> Igor
> 
> About global optimisation I guess I can see your point, but unless these
> scenarios are quite common and not some corner case isn't there a risk of
> having to distribute too much information about the internal node
> structure, and the use of it, than meets the scalability requirements. E.g.
> using the suggested pool concepts would lead to less, but still enough
> (hopefully), information distributed about the resources in the network.
> 
> Cheers,
>  Anders
> 
> > > Behalf Of Anders Gavler
> > >> Behalf Of
> > >>>> frequency or

---

From: Greg Bernstein <[email-masked]>
Date: Thu, 05 Nov 2009 10:17:18 -0800

With the signal compatibility draft and signaling extensions we 
introduce more configuration information via attributes in the ERO.
If we add the tunable transponder id (very similar to a wavelength 
converter id) to the label will this be sufficient for restart or would 
we need to add some of our other attributes such as (FEC and modulation 
format) to permit restart.

Greg

Lou Berger wrote:
>>>>> From: [email-masked] [mailto:[email-masked]] On Behalf
>>>>>           
>>> Of
>>>       
>>>>> Lou Berger
>>>>> Subject: Re: [CCAMP] draft-ietf-ccamp-gmpls-g-694-lambda-labels and
>>>>>           
>>> unique
>>>       
>>>>> resource identification
>>>>>
>>>>> Greg,
>>>>>> Lou, do you think this information is better in a label or in some
>>>>>>             
>>> kind
>>>       
>>>>>> with the traffic descriptor since they can change along a path. I
>>>>>>             
>>> didn't
>>>       
>>>>>>> 	A very good question!  In the common/general setup case I think
>>>>>>>               
>>>>> it
>>>>>           
>>>>>>> represent a specific physical resource, be it a time slot, frequency
>>>>>>>               
>>> or
>>>       
>>>>>>> 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.
>>>       
>>>>>>> GMPLS allows for sufficient information for a node to reconstruct
>>>>>>>               
>>> this
>>>       
>>>>>>> mapping.
>>>>>>>
>>>>> tunable, why does it matter which one is used? Can't the node decide
>>>>>           
>>> this
>>>       
>>>>> locally?
>>>>>           
>>>>>>>> Regards,
>>>>>>>> Jonas
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>>>>>     What are your thoughts on how to provide such link-scoped
>>>>>>>>>>                     
>>> unique
>>>