[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [CCAMP] draft-ietf-ccamp-gmpls-g-694-lambda-labels and unique resource identification
Hi Igor,
Thanks for adding a couple of cases, especially the first one that clarifies the possible problems at a node restart. I did not anticipate that this was a likely scenario.
Cheers,
Anders
> -----Original Message-----
> From: Igor Bryskin [mailto:IBryskin at advaoptical.com]
> Sent: den 4 november 2009 20:43
> To: Anders Gavler
> Cc: Jonas Mårtensson; Greg Bernstein; ccamp at ietf.org; Lou Berger
> Subject: RE: [CCAMP] draft-ietf-ccamp-gmpls-g-694-lambda-labels and unique
> resource identification
>
> Hi Anders,
>
> Here is a couple of reasons why you need to be able to signal tun.
> Traspobder physical IDs.
>
> 1. Suppose, two transponders tuned to the same frequency are associated
> with two LSPs on a given NE. Suppose, the NE is restarted. Resync
> procedures will resurrect CP state for both LSPs. However, if neighboring
> NEs do not know about IDs of the transponders, the CP on the rebooting NE
> could be easily confused and associate CP states of the two LSPs with
> wrong transponders. If, some time later, one deletes one of the LSPs, the
> second LSP will be hit. Note, that this situation can be avoided if the
> transponder IDs are present somewhere in the RSVP Path message (e.g. in
> ERO)
>
> 2. Suppose, two tun. transponders with overlapping ranges are available
> for two new LSPs. Suppose, LSP 1 needs to use a frequency within both
> ranges, while the second LSP needs to use frequency within only one of the
> ranges (i.e. outside of the other range). If Path message of the first LSP
> does not contain ID of the "right" transponder, it can easily choose the
> second one and block the setup of the second LSP.
>
> Igor
>
> -----Original Message-----
> From: Anders Gavler [mailto:Anders.Gavler at acreo.se]
> Sent: Wednesday, November 04, 2009 1:21 PM
> To: Igor Bryskin
> Cc: Jonas Mårtensson; Greg Bernstein; ccamp at ietf.org; Lou Berger
> Subject: RE: [CCAMP] draft-ietf-ccamp-gmpls-g-694-lambda-labels and unique
> resource identification
>
> Hi Igor,
>
> About global optimisation I guess I can see your point, but unless these
> scenarios are quite common and not some corner case isn't there a risk of
> having to distribute too much information about the internal node
> structure, and the use of it, than meets the scalability requirements. E.g.
> using the suggested pool concepts would lead to less, but still enough
> (hopefully), information distributed about the resources in the network.
>
> Cheers,
> Anders
>
> > -----Original Message-----
> > From: Jonas Mårtensson
> > Sent: den 3 november 2009 22:46
> > To: Igor Bryskin
> > Cc: Anders Gavler; Lou Berger; Greg Bernstein; ccamp at ietf.org
> > Subject: Re: [CCAMP] draft-ietf-ccamp-gmpls-g-694-lambda-labels and
> unique
> > resource identification
> >
> > Hi Igor,
> >
> > I understand that it is useful to be able to indicate whether
> > regeneration should be performed. What was less clear to me was why it
> > matters exactly which regenerator or laser is used. If I understand
> > you correctly you say that one motivation is that different regens may
> > have different capabilities (eg tuning range) and/or connectivity and
> > therefore it could make a difference which one you use from a global
> > optimization perspective. For example, if a fixed laser is available
> > at the desired wavelength it might be better to use this rather than a
> > tunable one in order to have more flexibility for future connections.
> >
> > I'm still not clear about the restart issue though.
> >
> > Thanks,
> > Jonas
> >
> > 3 nov 2009 kl. 20.40 skrev "Igor Bryskin" <IBryskin at advaoptical.com>:
> >
> > > Anders,
> > >
> > > Let me try to explain this. Within a given node there could be
> > > multiple ways how an incoming interface:lambda could be cross-
> > > connected with outgoing interface: lambda:
> > > a) transparent;
> > > b) fixed regeneration;
> > > c) tunable regeneration;
> > > d) chain of tunable/fixed transponders;
> > > e)etc.
> > >
> > > It is quite possible that a node on its own cannot decide on what is
> > > the proper way to build the cross-connect simply because it cannot
> > > see the network-wide picture, while a centralized authority (i.e.
> > > PCE, NMS) can. For example, because of optical impairment
> > > consideration the signal should be regenerated on this node with or
> > > without wavelength conversion. Note also that it is possible that
> > > more than one tunable resources with overlapping ranges are
> > > available on a given link, and (in the roadm directionless
> > > technology) the same transponder may be available from more than one
> > > links.
> > >
> > > You should see by now why it is paramount to be able to specify in
> > > the ERO not only link/lambda pairs but also the physical IDs of
> > > concrete transponders.
> > >
> > > This is one reason, amother is, as Lou pointed out, restarts. Think
> > > about the situation when you restart the node and during restart
> > > procedures two LSPs are associated with wrong transponders. Then
> > > when you delete one LSP you will bring down unintentionally the
> > > other one as well.
> > >
> > > Hope this helps.
> > >
> > > Igor
> > >
> > > -----Original Message-----
> > > From: ccamp-bounces at ietf.org [mailto:ccamp-bounces at ietf.org] On
> > > Behalf Of Anders Gavler
> > > Sent: Tuesday, November 03, 2009 1:56 PM
> > > To: Lou Berger; Greg Bernstein
> > > Cc: ccamp at ietf.org
> > > Subject: Re: [CCAMP] draft-ietf-ccamp-gmpls-g-694-lambda-labels and
> > > unique resource identification
> > >
> > > Lou,
> > >
> > > I still do not get it.
> > >
> > > As long as a node uniquely can identify an LSP that starts, ends, or
> > > transits this node it should also be able to uniquely map which
> > > local resources the LSP corresponds to (e.g. tunable or non-tunable
> > > transponder, wavelength, ports etc).
> > >
> > > If this is true I do not see why the label needs to directly map to
> > > a certain laser since they both can map to a uniquely identifiable
> > > LSP and this information could be stored and used at restart.
> > >
> > > /Anders
> > >
> > >
> > >> -----Original Message-----
> > >> From: ccamp-bounces at ietf.org [mailto:ccamp-bounces at ietf.org] On
> > >> Behalf Of
> > >> Lou Berger
> > >> Sent: den 3 november 2009 18:58
> > >> To: Greg Bernstein
> > >> Cc: ccamp at ietf.org
> > >> Subject: Re: [CCAMP] draft-ietf-ccamp-gmpls-g-694-lambda-labels and
> > >> unique
> > >> resource identification
> > >>
> > >> Greg,
> > >> In the cases I'm referring to we're talking per node resource
> > >> information which typically has node (pair) local scope with the
> > >> exception of ERO and RROs. So no, I don't think an end-to-end LSP
> > >> attribute is a match.
> > >>
> > >> Lou
> > >>
> > >> On 11/3/2009 12:50 PM, Greg Bernstein wrote:
> > >>> Lou, do you think this information is better in a label or in some
> > >>> kind
> > >>> of LSP attribute? In the WSON compatibility draft we tentatively put
> > >>> similar information into a new ERO subobject for attributes. Those
> > >>> attributes included things like modulation format, FEC, and whether
> > >>> regeneration should occur at a node along the path. We didn't put
> > >>> them
> > >>> with the traffic descriptor since they can change along a path. I
> > >>> didn't
> > >>> think we should put them into labels... But I'm flexible.
> > >>>
> > >>> Regards
> > >>>
> > >>> Greg
> > >>>
> > >>> Lou Berger wrote:
> > >>>> Jonas,
> > >>>> A very good question! In the common/general setup case I think
> > >> it
> > >>>> won't matter. But there are cases where it may:
> > >>>>
> > >>>> - In GMPLS we have a precedent of being able to use the label to
> > >>>> represent a specific physical resource, be it a time slot,
> > >>>> frequency or
> > >>>> even port. If we assume that this is a function worth preserving
> > >>>> (and
> > >> I
> > >>>> believe it is, at least with today's equipment) than it is
> > >>>> desirable/required to be able to use GMPLS to control a specific
> > >>>> laser.
> > >>>> Even a tunable one. With the current definition, this isn't
> > >>>> possible.
> > >>>>
> > >>>> - The more practical/import case is graceful restart. In certain
> > >>>> restart cases, the restarting node may need to match particular
> > >>>> node
> > >>>> resources (e.g., tunable lasers) against a particular frequency to
> > >>>> ensure no data loss and the restarting node may no longer have the
> > >>>> information to do the matching. In all other cases that I know
> > >>>> about,
> > >>>> GMPLS allows for sufficient information for a node to reconstruct
> > >>>> this
> > >>>> mapping.
> > >>>>
> > >>>> - MP to CP handover may also need to identify specific node
> > >>>> resources
> > >>>> (e.g., tunable lasers).
> > >>>>
> > >>>> I believe these are the primary cases.
> > >>>>
> > >>>> I hope this helps,
> > >>>> Lou
> > >>>>
> > >>>> On 11/2/2009 5:35 AM, Jonas Mårtensson wrote:
> > >>>>
> > >>>>> Lou,
> > >>>>>
> > >>>>> Maybe this is a silly question but if all lasers in the system are
> > >> tunable, why does it matter which one is used? Can't the node
> > >> decide this
> > >> locally?
> > >>>>>
> > >>>>> Regards,
> > >>>>> Jonas
> > >>>>>
> > >>>>>
> > >>>>>> -----Original Message-----
> > >>>>>> From: ccamp-bounces at ietf.org [mailto:ccamp-bounces at ietf.org]
> > >>>>>> On Behalf Of Lou Berger
> > >>>>>> Sent: den 30 oktober 2009 14:02
> > >>>>>> To: Richard Rabbat
> > >>>>>> Cc: ccamp at ietf.org
> > >>>>>> Subject: Re: [CCAMP]
> > >>>>>> draft-ietf-ccamp-gmpls-g-694-lambda-labels and unique
> > >>>>>> resource identification
> > >>>>>>
> > >>>>>> Richard,
> > >>>>>>
> > >>>>>> Okay let me try again with a specific case. If I have an rro
> > >>>>>> or ero that identifies the label (lambda) per your document,
> > >>>>>> how does a node know which laser the label corresponds to
> > >>>>>> when all lasers in the system are tunable?
> > >>>>>>
> > >>>>>> Thanks,
> > >>>>>> Lou
> > >>>>>>
> > >>>>>> On 10/29/2009 2:22 PM, Richard Rabbat wrote:
> > >>>>>>
> > >>>>>>> sorry for the lag.
> > >>>>>>> do you want to describe your use-case further in terms of what
> > >>>>>>> you
> > >>>>>>> can't do and your proposed change?
> > >>>>>>> thanks,
> > >>>>>>> Richard.
> > >>>>>>>
> > >>>>>>> On Thu, Oct 15, 2009 at 8:53 AM, Lou Berger <lberger at labn.net
> > >>>>>>> <mailto:lberger at labn.net>> wrote:
> > >>>>>>>
> > >>>>>>> Authors,
> > >>>>>>> Have you given any additional thought on the
> > >>>>>>>
> > >>>>>> repesentation of
> > >>>>>>
> > >>>>>>> tunable
> > >>>>>>> lasers (and unique resource identification) beyond what
> > >>>>>>>
> > >>>>>> is currently in
> > >>>>>>
> > >>>>>>> the draft? The current text is:
> > >>>>>>> If the node has a tunable wavelength transponder, the
> > >>>>>>> tuning
> > >>>>>>> wavelength is considered as a part of wavelength switching
> > >>>>>>> operation.
> > >>>>>>>
> > >>>>>>> In the past, labels used for TE LSPs always represented
> > >>>>>>>
> > >>>>>> a specific
> > >>>>>>
> > >>>>>>> resource that is uniquely identifiable by the node that
> > >>>>>>>
> > >>>>>> allocates the
> > >>>>>>
> > >>>>>>> label and resource. Such unique identification is
> > >>>>>>>
> > >>>>>> important/required
> > >>>>>>
> > >>>>>>> for certan restart and other corner cases. Your current
> > >>>>>>>
> > >>>>>> definition works
> > >>>>>>
> > >>>>>>> fine for fixed lasers that can only be mapped to a
> > >>>>>>>
> > >>>>>> single fiber. But,
> > >>>>>>
> > >>>>>>> the defined global label will not uniquely identify a
> > >>>>>>>
> > >>>>>> resource on a node
> > >>>>>>
> > >>>>>>> when (a) tunable lasers are used, or (b) when a node
> > >>>>>>>
> > >>>>>> supports multiple
> > >>>>>>
> > >>>>>>> fixed lasers that can be (optically) switched to a
> > >>>>>>>
> > >>>>>> particular output
> > >>>>>>
> > >>>>>>> interface.
> > >>>>>>>
> > >>>>>>> What are your thoughts on how to provide such link-scoped
> > >>>>>>> unique
> > >>>>>>> resource identification in the context of your draft?
> > >>>>>>>
> > >>>>>>> I don't think it'll be too difficult to address this
> > >>>>>>>
> > >>>>>> critical point, and
> > >>>>>>
> > >>>>>>> see a couple of straightforward solutions if you'd like
> > >>>>>>>
> > >>>>>> to discuss
> > >>>>>>
> > >>>>>>> off-line.
> > >>>>>>>
> > >>>>>>> Much thanks,
> > >>>>>>> Lou
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> _______________________________________________
> > >>>>>>> CCAMP mailing list
> > >>>>>>> CCAMP at ietf.org <mailto:CCAMP at ietf.org>
> > >>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>> _______________________________________________
> > >>>>>> CCAMP mailing list
> > >>>>>> CCAMP at ietf.org
> > >>>>>> https://www.ietf.org/mailman/listinfo/ccamp
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>> _______________________________________________
> > >>>> CCAMP mailing list
> > >>>> CCAMP at ietf.org
> > >>>> https://www.ietf.org/mailman/listinfo/ccamp
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>> --
> > >>> ===================================================
> > >>> Dr Greg Bernstein, Grotto Networking (510) 573-2237
> > >>>
> > >>>
> > >> _______________________________________________
> > >> CCAMP mailing list
> > >> CCAMP at ietf.org
> > >> https://www.ietf.org/mailman/listinfo/ccamp
> > >
> > >
> > >
> > > _______________________________________________
> > > CCAMP mailing list
> > > CCAMP at ietf.org
> > > https://www.ietf.org/mailman/listinfo/ccamp
> > > _______________________________________________
> > > CCAMP mailing list
> > > CCAMP at ietf.org
> > > https://www.ietf.org/mailman/listinfo/ccamp
> > >
>
>