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

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



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.

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