[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Solicit the comments on LMP Data Channel Status I-D
Hi all,
For case 2.2, as we have described in the draft, I think it's a local policy decision how this mismatched state should be handled. Some deployments may decide to automatically clean up the data plane state so it matches the control plane state, but others may choose to raise an alert to the management plane and leave the data plane untouched just in case it is in use. In such cases, data channel mismatches may arise after restart and might not be cleared up by the restart procedures.
Regards,
Dan
----- Original Message -----
From: <Dimitri.Papadimitriou@alcatel-lucent.be>
To: "Diego Caviglia (GA/ERI)" <diego.caviglia@ericsson.com>
Cc: <ccamp@ops.ietf.org>; <owner-ccamp@ops.ietf.org>
Sent: Wednesday, April 04, 2007 1:29 AM
Subject: Re: Solicit the comments on LMP Data Channel Status I-D
> diego
>
> > I think that the reason wht timeslot 2 is not usable is out of the
> > scope of the ID.
>
> but this is kernel of the problem, the origin tells where the solution
> shall be targeted
>
> the i-d refers to the deletion case (2.2), fine but there is cleanup
> timeout interval to free resources in rsvp
>
> thanks,
> -d.
>
>
>
>
>
> "Diego Caviglia \(GA/ERI\)" <diego.caviglia@ericsson.com>
> Sent by: owner-ccamp@ops.ietf.org
> 03/04/2007 13:26
>
> To: <ccamp@ops.ietf.org>
> cc:
> Subject: Re: Solicit the comments on LMP Data Channel
> Status I-D
>
>
> This was bounced.
>
> D
>
>
> > Hi Dimitri,
> > my understunding of the ID was that it tries to 'synchronize'
> > the status of the timeslots that are facing the same link.
> >
> > Otherwise downstream NE can choose a timeslot that is not good for the
> > upstream node
> >
> >
> > NE-A NE-B
> > Timeslots Timeslots
> > 1-OK 1-OK
> > 2-OK 2-KO
> > 3-OK 3-OK
> > 4-OK 4-OK
> >
> > So NE-A can choose Timeslot 2 because it see it good while is not good
> in
> > NE-B. I think that the reason wht timeslot 2 is not usable is out of
> the
> > scope of the ID.
> >
> > BR
> >
> > Diego
> >
> >
> >
> >
> >
> >
> > Dimitri.Papadimitriou@alcatel-lucent.be on 03/04/2007 11.57.12
> >
> > To: "Diego Caviglia" <Diego.Caviglia@marconi.com>, Dan Li
> > <danli@huawei.com>, ccamp <ccamp@ops.ietf.org>
> > cc:
> >
> > Subject: Re: Solicit the comments on LMP Data Channel Status I-D
> >
> > diego & dan
> >
> > "Since the error condition can arise from a variety of situations
> > (including
> > control plane failure and restart, management plane intervention,
> attempt
> > to clean up a partitioned control plane, etc.) we believe that it would
> be
> > useful to have optional extensions to LMP to detect and report the
> > problem.
> > Resolution of the problem remains an issue for the management plane."
> >
> > we have three classes of "errors" those outside scope of the CP, those
> > resulting from CP operations (bug-fixing/mis-use/mis-config/etc.) and
> > then those that are strictly specific to the LMP and operations
> >
> > only the latter shall be in-scope - all these circular dependencies we
> > are introducing in this control plane are just breaking one of the main
> > design principle of networks
> >
> > -> which are the remaining "situations" ?
> >
> > thanks,
> > -d.
> >
> >
> >
> >
> >
> > "Diego Caviglia" <Diego.Caviglia@marconi.com>
> > 03/04/2007 11:35
> >
> > To: "Dan Li <danli"
> > cc: "ccamp <ccamp", "\"\"Deborah A. Brungard\" <dbrungard\"",
> > ""Farrel@smtpoutuk01.marconi.com, Adrian" <adrian", Dimitri
> > PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Julien Meuric <julien.meuric",
> > ""Bardalai@smtpoutuk01.marconi.com, Snigdho" <Snigdho.Bardalai"
> > Subject: Re: Solicit the comments on LMP Data Channel
> > Status I-D
> >
> >
> >
> > Hi Dan,
> > as stated in Prague I think that the ID addresses a real problem.
> >
> > BR
> >
> > Diego
> >
> >
> >
> > Dan Li <danli@huawei.com> on 03/04/2007 10.47.58
> >
> > To: ccamp <ccamp@ops.ietf.org>
> > cc: "Deborah A. Brungard" <dbrungard@att.com>, "Farrel, Adrian"
> > <adrian@olddog.co.uk>, Dimitri Papadimitriou
> > <Dimitri.Papadimitriou@alcatel-lucent.be>, Julien Meuric
> > <julien.meuric@francetelecom.com>, Diego Caviglia
> > <Diego.Caviglia@marconi.com>, "Bardalai, Snigdho"
> > <Snigdho.Bardalai@us.fujitsu.com>
> >
> > Subject: Solicit the comments on LMP Data Channel Status I-D
> >
> > Hi all,
> >
> > In Prague we saw three optical vendors stating that this I-D addresses a
> > real problem that they see in deployed networks. We also saw one
> operator
> > expressing interest in the work.
> >
> > To summarise the problem that we are addressing:
> >
> > Under some circumstances the opposite ends of data links may get into
> > mismatched states. For example, one end of the data link may be
> allocated
> > and cross-connected, while the other end is available for use. This
> > represents an error condition.
> >
> > The problem is particularly bad when the data link is a component link
> of
> > a
> >
> > bundle, because the problem cannot be detected from the TE
> advertisements.
> > Further, existing LMP mechanisms do not allow us to discover the
> problem.
> >
> > If left undetected and unresolved, the situation may lead to LSP setup
> > failures or to misconnection of LSPs.
> >
> > Since the error condition can arise from a variety of situations
> > (including
> >
> > control plane failure and restart, management plane intervention,
> attempt
> > to
> > clean up a partitioned control plane, etc.) we believe that it would be
> > useful to have optional extensions to LMP to detect and report the
> > problem.
> >
> > Resolution of the problem remains an issue for the management plane.
> >
> > We would like to hear from people who believe that this is or is not a
> > real
> >
> > problem in the network so that we can judge whether to ask the chairs to
> > make this a WG draft.
> > Best regards,
> >
> >
> > Dan Li
> >
> > Advanced Technology Department
> > Wireline Networking Business Unit
> > Huawei Technologies Co., LTD.
> > Huawei Base, Bantian, Longgang,
> > Shenzhen 518129 P.R.China
> > Tel: +86-755-28973237
> > Fax: +86-755-28972935
> >
> ***************************************************************************************
> >
> >
> > This e-mail and its attachments contain confidential information from
> > HUAWEI, which is intended only for the person or entity whose address is
> > listed above. Any use of the information contained herein in any way
> > (including, but not limited to, total or partial disclosure,
> reproduction,
> > or dissemination) by persons other than the intended recipient(s) is
> > prohibited. If you receive this e-mail in error, please notify the
> sender
> > by phone or email immediately and delete it!
> >
> ***************************************************************************************
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>
>