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