Re: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt
dimitri papadimitriou <dpapadimitriou@psg.com> Mon, 31 October 2005 17:24 UTC
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWdOs-0005KB-Q5 for ccamp-archive@megatron.ietf.org; Mon, 31 Oct 2005 12:24:52 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22021 for <ccamp-archive@ietf.org>; Mon, 31 Oct 2005 12:24:30 -0500 (EST)
Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWdd6-0002YC-6t for ccamp-archive@ietf.org; Mon, 31 Oct 2005 12:39:32 -0500
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EWdHu-000DMl-Bz for ccamp-data@psg.com; Mon, 31 Oct 2005 17:17:38 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-4.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0
Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EWdHs-000DMI-F0; Mon, 31 Oct 2005 17:17:37 +0000
Message-ID: <436651AE.8010701@psg.com>
Date: Mon, 31 Oct 2005 18:17:34 +0100
From: dimitri papadimitriou <dpapadimitriou@psg.com>
Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Shiba, Sidney" <sidney.shiba@us.fujitsu.com>
CC: "Drake, John E" <John.E.Drake2@boeing.com>, Adrian Farrel <adrian@olddog.co.uk>, richard.rabbat@us.fujitsu.com, ccamp@ops.ietf.org
Subject: Re: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt
References: <7CA873794E52904EAA980A074B076779B17C61@rchemx01.fnc.net.local>
In-Reply-To: <7CA873794E52904EAA980A074B076779B17C61@rchemx01.fnc.net.local>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4be0d55bab88df9d21005ced9551e26
Content-Transfer-Encoding: 7bit
sidney - short note to clarify the comparison with SONET/SDH Shiba, Sidney wrote: > John, > > Comments inline: > > >>-----Original Message----- >>From: Drake, John E [mailto:John.E.Drake2@boeing.com] >>Sent: Monday, October 31, 2005 9:36 AM >>To: Shiba, Sidney; dpapadimitriou@psg.com >>Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org >>Subject: RE: comments on draft-shiba-ccamp-gmpls-lambda-labels-00.txt >> >> >>Sidney, >> >>But there's nothing in your picture that requires an absolute end-end >>global wavelength. The existing GMPLS solution with relative >>wavelengths of local significance should work just fine. > > > [Sidney] Sorry for the missing info. The optical switch is an all optical > switch (i.e., no OEO is necessary). The wavelength continuity constraint > indicates which wavelength (nominal value) all the optical switches > traversed by the lightpath needs to cross-connect. > > >>As I said in my previous note, your method precludes combining two or >>more parallel WDM links into a single TE link. > > [Sidney] Note the Label is complemented by the interface id of the link. > > I think this is the same approach used for parallel SONET OCn datalinks > where the label identifies a time-slot and interface id identifies the > datalink chosen for the connection. in RFC3946 the label does not include the interface id; the latter is part of the IF_ID RSVP_HOP TLV if you introduce a spectral wavelength label you will not be able anymore to correlate into the same (unbundled) link two data links having the same nominal wavelength; note: introducing "spectral label" would introduce a similar issue present in SDH/SONET where you can not correlate two or more "data links" in the same (unbundled) TE link with a resulting overlapping set of timeslots; however, the major difference compared with wavelength switching is that in SONET/SDH you need to construct very particular configurations for reaching this kind of restriction; also there is no real operational issue since so far with this simply because each timeslot in a given section is spatially equivalent and has identical TE properties; the situation is completely different in a wavelength switched environment >>Thanks, >> >>John >> >> >>>-----Original Message----- >>>From: Shiba, Sidney [mailto:sidney.shiba@us.fujitsu.com] >>>Sent: Monday, October 31, 2005 7:25 AM >>>To: Drake, John E; dpapadimitriou@psg.com >>>Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org >>>Subject: RE: comments on >> >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt >> >>>Hi John, >>> >>>Optical switches based on Wavelength Selective Switch (WSS) >> >>technology >> >>>requires the wavelength information for switching. This >> >>technology is >>NOT >> >>>wavelength agnostic. >>> >>> | | >>> | wdm | wdm >>> |2 |2 >>> --------- --------- >>> wdm 1| optical |3 wdm 1| optical |3 wdm >>> --------| switch |------------| switch |--------- >>> | (WSS) | | (WSS) | >>> --------- --------- >>> |4 |4 >>> | wdm | wdm >>> | | >>> >>>Note that the figure above shows an example of two optical switches >>>interconnect >>>by a single WDM fiber. In this example, each optical switch can be >> >>connect >> >>>to 4 >>>other optical switches. >>> >>>As you can see, the optical ports information do not provide enough >>>information >>>for wavelength switching. >>> >>>Hope that clarifies the application requirement. >>> >>>Thanks, >>> >>>Sidney >>> >>> >>>>-----Original Message----- >>>>From: Drake, John E [mailto:John.E.Drake2@boeing.com] >>>>Sent: Friday, October 28, 2005 5:33 PM >>>>To: dpapadimitriou@psg.com; Shiba, Sidney >>>>Cc: Adrian Farrel; richard.rabbat@us.fujitsu.com; >> >>ccamp@ops.ietf.org >> >>>>Subject: RE: comments on >> >>draft-shiba-ccamp-gmpls-lambda-labels-00.txt >> >>>> >>>>Hi, >>>> >>>>Below is the text of an e-mail is sent to the >> >>Ethernet/GMPLS mailing >> >>>>list. >>>> >>>>Upon reflection I am not sure using a real wavelength value makes >> >>much >> >>>>sense. Between a pair of adjacent nodes, there may be >>>>multiple pairs of >>>>switch ports in the same TE link that support a given >> >>frequency. If >>a >> >>>>real wavelength value is used, how do the two nodes agree on >>>>which pair >>>>of switch ports to use? >>>> >>>>Furthermore, the amount of configuration is the same - you >>>>still need to >>>>configure the wavelength of each switch port. >>>> >>>>Thanks, >>>> >>>>John >>>>============================================================== >>>>========== >>>>==== >>>>Adrian, >>>> >>>>In the transparent photonic lambda switch case, the >> >>labels also have >> >>>>only local significance. When an LSP is established, the input >> >>ports, >> >>>>as identified with local labels, are cross-connected to the output >>>>ports, as identified with local labels. >>>> >>>>There is just extra configuration to identify, using >> >>strictly local >> >>>>identifiers, the wavelength associated with the all of >> >>the switch's >> >>>>ports, and an additional CAC requirement that the >> >>wavelengths of the >> >>>>input and output ports are the same. >>>> >>>>Thanks, >>>> >>>>John >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] >>>>>Sent: Thursday, October 27, 2005 10:03 AM >>>>>To: Shiba, Sidney >>>>>Cc: dimitri.papadimitriou@alcatel.be; Adrian Farrel; >>>>>richard.rabbat@us.fujitsu.com; ccamp@ops.ietf.org >>>>>Subject: Re: comments on >>>> >>>>draft-shiba-ccamp-gmpls-lambda-labels-00.txt >>>> >>>>>shiba - see inline for some additional hints: >>>>> >>>>> >>>>>>>Shiba, Sidney wrote: >>>>>>> >>>>>>> >>>>>>>>Adrian, Dimitri, >>>>>>>> >>>>>>>>Thanks for reviewing these I-D. >>>>>>>> >>>>>>>>Wavelength continuity constraint does require the use of >>>> >>>>semanticful >>>> >>>>>>>>label whether it is spectral or index. >>>>>>> >>>>>>>=> see my reply to adrian on this specific point >>>>>>> >>>>>>> >>>>>>>>I agree with Dimitri that the >>>>>>>>wavelength indexing requires document updating each >> >>time a new >> >>>>>>>>spectrum is introduced. >>>>>>> >>>>>>>=> indeed and in addition it requires updating the already >>>>>>>signaled path >>>>>>> >>>>>>> >>>>>>>>The use of spectral label provides self maintainance, i.e., >>>>>>>>no need to update any document and the use of the >> >>nominal value >> >>>>>>>>provides a common semantic ground. >>>>>>> >>>>>>>=> what do you mean by self-maintenance - would you provide a >>>>>>>bit more detail >>>>>> >>>>>>[Sidney]What I've meant here was that it was not necessary to >>>>>>update any document when new wavelengths are >> >>inventoried. In the >> >>>>>>case of indexing approach, it would require the >>>> >>>>wavelength indexing >>>> >>>>>>document to be updated with implementation impacts. >>>>>> >>>>>>In the case, the nominal value is used, there is no need for >>>>>>documentation update. >>>>> >>>>>ok - what you mean here is that you are going to make use of the >>>> >>>>already >>>> >>>>>defined C-Type 2 - what about the specific encoding of the >>>> >>>>value space >>>>? >>>> >>>>>>>=> now i have a more specific question before being light-up >>>>>>>how do you know the frequency that you can support ? >>>>>> >>>>>>[Sidney] Some new technologies integrate optical switch and >>>> >>>>mux/demux >>>> >>>>>>capabilities, which allows the equipment to know the >> >>spectrum it >> >>>>>supports. >>>>> >>>>>indeed - but the question is what does happen if the >>>> >>>>"detected" values >>>> >>>>>(during initialization) do not match the nominal values ? you >> >>don't >> >>>>>initialize then ? >>>>> >>>>> >>>>>>>if these differ from the nominal values how are you going to >> >>deal >> >>>>with >>>> >>>>>these >>>>> >>>>>>>discrepancies ? >>>>>> >>>>>>[Sidney] These new technologies uses the nominal value as >>>> >>>>reference. >>>>We >>>> >>>>>can say >>>>> >>>>>>that a lightpath wavelength is identified by its >> >>nominal value. >>If >> >>>>the >>>> >>>>>equipment >>>>> >>>>>>is drifting from this nominal value, it is considered as >>>> >>>>a failure. >>>> >>>>>ok - but if the deviation is such you have overlap - how the >> >>control >> >>>>>plane is going to be able to detect such failure ? >>>>> >>>>> >>>>>>>this said i am not necessarily sure that having to >>>> >>>>maintain the data >>>> >>>>>plane >>>>> >>>>>>>specifics as part of the control plane is really helping >>>>>>>operations (is this method not just duplicating complexity ?) >>>>>> >>>>>>[Sidney] The wavelength is WDM specific as much as the SUKLM >> >>label >> >>>>>encoding >>>>> >>>>>>is for SONET. The wavelegth/frequency nominal value is used to >>>> >>>>identify >>>> >>>>>the >>>>> >>>>>>facilities to cross-connect. >>>>> >>>>>there is an equivalence but there is also a major >> >>difference, the >> >>>>>structure is invariant independently of the state of the >>>> >>>>network, with >>>> >>>>>spectral value space you may have labels that become unavailable >> >>due >> >>>>to >>>> >>>>>non-local usage of wavelength in the network >>>>> >>>>>hence, there is also no real coupling to the data plane >> >>more than >> >>>>>knowing the type of interface and some generic capabilities >>>>> >>>>> >>>>>>>>I'm not sure if the draft needs to be updated before the >>>>>>>>face-to-face meeting or after all comments are collected. >> >>Please >> >>>>>advise. >>>>> >>>>>>>=> suggest to keep discussion on - document update can be >>>>>>>performed at a later stage >>>>> >>>>>thanks, >>>>>- dimitri. >>>>> >>>>> >>>>>>>>>-----Original Message----- >>>>>>>>>From: owner-ccamp@ops.ietf.org >>>> >>>>[mailto:owner-ccamp@ops.ietf.org]On >>>> >>>>>>>>>Behalf Of Adrian Farrel >>>>>>>>>Sent: Thursday, October 27, 2005 4:45 AM >>>>>>>>>To: dpapadimitriou@psg.com; >> >>dimitri.papadimitriou@alcatel.be; >> >>>>>>>>>ccamp@ops.ietf.org >>>>>>>>>Subject: Re: comments on >>>>>>> >>>>>>>draft-shiba-ccamp-gmpls-lambda-labels-00.txt >>>>>>> >>>>>>> >>>>>>>>>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. >>>>>>>>> >>>>>>>>>So the point reduces to whether the scope of the semantics >>>>>>>>>are link-local >>>>>>>>>or wider. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>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? >>>>>>>>> >>>>>>>>>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? >>>>>>>>> >>>>>>>>> >>>>>>>>>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. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>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> >>>>>>>> >>>>>>>>. >>>>>>>> >>>>>>> >>>>>>. >>>>>> >>>> > > > . >
- comments on draft-shiba-ccamp-gmpls-lambda-labels… dimitri papadimitriou
- Re: comments on draft-shiba-ccamp-gmpls-lambda-la… Adrian Farrel
- Re: comments on draft-shiba-ccamp-gmpls-lambda-la… dimitri papadimitriou
- Re: comments on draft-shiba-ccamp-gmpls-lambda-la… dimitri papadimitriou
- Re: comments on draft-shiba-ccamp-gmpls-lambda-la… dimitri papadimitriou
- Re: comments on draft-shiba-ccamp-gmpls-lambda-la… dimitri papadimitriou
- Re: comments on draft-shiba-ccamp-gmpls-lambda-la… dimitri papadimitriou
- RE: comments on draft-shiba-ccamp-gmpls-lambda-la… Drake, John E
- RE: comments on draft-shiba-ccamp-gmpls-lambda-la… Shiba, Sidney
- RE: comments on draft-shiba-ccamp-gmpls-lambda-la… Drake, John E
- RE: comments on draft-shiba-ccamp-gmpls-lambda-la… Drake, John E
- RE: comments on draft-shiba-ccamp-gmpls-lambda-la… Shiba, Sidney
- RE: comments on draft-shiba-ccamp-gmpls-lambda-la… Shiba, Sidney
- RE: comments on draft-shiba-ccamp-gmpls-lambda-la… Payam Torab
- RE: comments on draft-shiba-ccamp-gmpls-lambda-la… Drake, John E
- RE: comments on draft-shiba-ccamp-gmpls-lambda-la… Shiba, Sidney
- RE: comments on draft-shiba-ccamp-gmpls-lambda-la… Drake, John E
- RE: comments on draft-shiba-ccamp-gmpls-lambda-la… Drake, John E
- Re: comments on draft-shiba-ccamp-gmpls-lambda-la… dimitri papadimitriou
- RE: comments on draft-shiba-ccamp-gmpls-lambda-la… neil.2.harrison
- RE: comments on draft-shiba-ccamp-gmpls-lambda-la… Shiba, Sidney
- RE: comments on draft-shiba-ccamp-gmpls-lambda-la… Drake, John E
- RE: comments on draft-shiba-ccamp-gmpls-lambda-la… Drake, John E
- RE: comments on draft-shiba-ccamp-gmpls-lambda-la… Payam Torab
- RE: comments on draft-shiba-ccamp-gmpls-lambda-la… Drake, John E