[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Solicit the comments on LMP Data Channel Status I-D
Hi Dimitri,
I think Adrian is right. In the draft section 1, it clearly states:
"This document defines simple additions to the Link Management Protocol (LMP) [RFC4204] to provide a control plane tool that can assist in the location of stranded resources by allowing adjacent LSRs to confirm data channel statuses, and provides triggers for notifying the management plane if any discrepancies are found."
We just want to report the mismatch issue, but not trying to do the automatic correction.
Thanks,
Dan
----- Original Message -----
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "Diego Caviglia" <Diego.Caviglia@marconi.com>; "Dan Li" <danli@huawei.com>; "ccamp" <ccamp@ops.ietf.org>; <Dimitri.Papadimitriou@alcatel-lucent.be>
Sent: Tuesday, April 03, 2007 6:16 PM
Subject: Re: Solicit the comments on LMP Data Channel Status I-D
> Hi Dimitri,
>
> If I understand you correctly, you are saying that only problems caused by
> the control plane should be detected and/or reported by the control plane.
> Is that what you said?
>
> If so, how do you account for using LMP to verify link configuration, or
> RSVP-TE to report data plane faults?
>
> But perhaps you are simply saying that the control plane should not be
> engineered to handle defects in the control plane (especially implementation
> defects). I would agree with you on that point, but I don't think that is
> what Dan is proposing. As far as I understand it, he is covering the case
> where the control plane cannot correctly tidy up after itself, or where
> there has been a misconfiguration through the management plane.
>
> Note that he is not proposing automatic correction of such situations, but
> rather a mechanism for detecting them and reporting them.
>
> A
> ----- Original Message -----
> From: <Dimitri.Papadimitriou@alcatel-lucent.be>
> To: "Diego Caviglia" <Diego.Caviglia@marconi.com>; "Dan Li"
> <danli@huawei.com>; "ccamp" <ccamp@ops.ietf.org>
> Sent: Tuesday, April 03, 2007 10:57 AM
> 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!
> > ***************************************************************************************
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>