[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt

shiba,

see inline

Shiba, Sidney wrote:


Dimitri,

See inline



-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
Behalf Of dimitri papadimitriou
Sent: Thursday, October 27, 2005 8:16 AM
To: Adrian Farrel
Cc: dimitri.papadimitriou@alcatel.be; ccamp@ops.ietf.org
Subject: Re: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt


adrian - see in-line

Adrian Farrel wrote:



Dimitri,
Thanks for your work reviewing these recent I-Ds. It is 
really valuable


and I'd welcome other people doing similar reviews.




there is a specific point to be clarified in this document:

semanticless vs semanticful label (even here there is a distinction
between spectral vs indexes i.e. using the wavelength index)

domain-wide vs link local significant label
Without being too picky, I think all labels are semanticful 
otherwise, we


would not know what resource they refered to.

actually you have unstructured label space whose 
interpretation can only 
be done in the context of the link associated to this label 
exchange and 
if you have an additional level of indirection -> 
"semanticless" as the 
value in itself (with its associated link) does not tell you 
more about 
the resource to be used (its just equivalent to an index) you 
need for 
instance to perform initial LMP exchange to know the data 
plane resource 
correspondance

but you have also structured label spaces like TDM whose 
interpretation 
can be done (together with the associated link) since they 
provide you 
with the exact timeslot position in the SONET/SDH 
multiplexing tree -> 
so the label value space carries a semantic

[Sidney] The use of spectral label allows to provide a consistent
solution from network engineering tool to the circuit provisioning.
No need to translate wavelength (engineering tool) to local id (ERO)
and back to wavelength (NE).

Note that this is not the main reason for the spectral label but
can be considered as extra that comes with this approach.

would be helphul to know the main reason then ?


hope this clarifies -



So the point reduces to whether the scope of the semantics 

are link-local


or wider.

see above - the discussion is important, in TDM this has been done in 
order to avoid timeslot position/index exchange while the 
structure is 
perfectly know and invariant - hence, draw an analogy with 
LSC requires 
careful thought



so, the comparison from this perspective with TDM labels is 

difficult to


parse, the latter is semanticful but link local

now, i don't specifically see what has changed the late 90's, early
y2k's, to have a change in the wavelength label definition;

This is the question I would like to get to the bottom of. 

In other words:


do we need this function?

It seems to me that the question being asked is this:

  If I want to compute a path that has some form of wavelength
  constraints, what information do I need access to?

you have at this level three type of constraints: spatial, 
spectral and link

currently GMPLS for wavelegnth constraints works with source-driven 
spatial routing (constraint-based source-routing so implying both TE 
routing and signaling exchanges) and receiver-driven spectral routing 
(via the label set/acceptable label set mechanism so implying only 
signaling exchanges)

[Sidney]We may need to increase the scope of this draft and add wavelength 
availability for allowing to shift from the spectral routing to spatial 
routing for optical networks. This approach would take care of wavelength 
blocking issue for non pre-engineered circuits.

well this is why i am asking the question, soon or later in order to 
benefit from these spectral labels you are going to come up with TE 
routing information exchange - before jumping there i would suggest that 
you take a look at the scaling properties of such approach

Another question might be:

  If I want to signal a path with wavelength constraints what
  information do I need to include in the signaling message?

shouldn't you ask the question, what's not workable with the present 
solution we have at hand in RFC3473 ?



I'd suggest that when we started on GMPLS, we were 

enthusiastic about


transparent optical networks, but we were not properly 

focusing wavelength


constraints because lambda-switching PXCs didn't take off. 

Therefore we


didn't examine the requirements for wavelength constraints 

in routing and


signaling. The authors of this I-D are claiming new 

hardware requirements


for the same function.

adrian, i am not sure to understand ... hence, i would like 
to know from 
authors how the following cornerstone problem has been solved

1. either the network is pre-engineered and you don't need to 
take care 
about any spectral routing specifics for traffic engineering purposes

[Sidney] In most of the cases, the network is pre-engineered using
spectral data, which will require a mapping effort. Of course, this
is feasable but we are proposing an approach that does not require
mapping effort when possible.

would it be possible that you provide with a real estimate of the effort 
required for such mapping - i did it and it just requires to have a 
single/common profile per wavelength/color that you can use based on the 
received label value index (in the pre-engineered case there properties 
are known)

2. or the network is not pre-engineered and i would like to 
know if the 
specifics of analog transmission/switching have been 
addressed such as 
to be compatible with the constraint-based routing mechanisms 
used today 
while keeping a low blocking probability

[Sidney] As I said previously, we might need to increase the scope 
of the draft to include wavelength availability information for the 
routing in order to keep low the blocking probability.

yes but this is where all complexity lies, as you don't know about the 
routing/selection of the wavelenght you are creating a closed loop such 
that your network will convergence problems; the major issue with lambda 
switching is that locality principle is not preserved, setting up a path 
in a non pre-engineered network implies that a reservation on a link can 
have impact on other link along the path but even on links that are not 
followed by that -

there are
several solution possible

- absolute values: the freq. of the wavelength: difficult to adopt
because referenced values are nominal and knowing all interactions
between wavelengths this knowledge is at the end of little practical
usage; (introduces implicit ordering)

- indexed values: the # of the wavelength: it does not provide for a

future proof label space for inst. in case new frequencies 

are inserted


in the grid (introduces explicit ordering)


- diff. values e.g. freq spacing starting from a reference 

value: pauses


the question of the reference value and does suffer from the former
issue (introduces implicit ordering)

- the solution available today - cumbersome in some control plane

operations (e.g. label set translation) and not easy to 

troubleshoot but


independent of any physical consideration (spectral), scale to any
number of wavelength per fiber, does not introduce any ordering, the
most flexible (since allowing each system to maintain its specific
control operations) and the less constraining since maintaining the
control plane operations independent of any data plane specifics





<http://www.ietf.org/internet-drafts/draft-shiba-ccamp-gmpls-l

ambda-labels


-00.txt>



.



.