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 isreally valuableand 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 labelWithout being too picky, I think all labels are semanticfulotherwise, wewould 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 correspondancebut 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 semanticsare link-localor 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 thoughtso, the comparison from this perspective with TDM labels isdifficult toparse, 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 linkcurrently 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 wereenthusiastic abouttransparent optical networks, but we were not properlyfocusing wavelengthconstraints because lambda-switching PXCs didn't take off.Therefore wedidn't examine the requirements for wavelength constraintsin routing andsignaling. The authors of this I-D are claiming newhardware requirementsfor 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 solved1. 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 afuture proof label space for inst. in case new frequenciesare insertedin the grid (introduces explicit ordering)- diff. values e.g. freq spacing starting from a referencevalue: pausesthe question of the reference value and does suffer from the former issue (introduces implicit ordering) - the solution available today - cumbersome in some control planeoperations (e.g. label set translation) and not easy totroubleshoot butindependent 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> ..