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

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 

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) 


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


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-lambda-labels
-00.txt>



.