Re: Solicit the comments on LMP Data Channel Status I-D

[Dimitri.Papadimitriou@alcatel-lucent.be]

hi adrian

i am simply pointing out that using LMP as a watch dog for signaling
and routing components bug-fix is a non starter, and errors resulting
from their mis-use but also the errors resulting from the concurrent 
control of the resource / component set falls into the same category

we are left with errors resulting from de-synchronization of the CP
status of data channels - in which condition - can this occur ? and
in which condition there is no resulting information that can not be
used to detect them ?

referring to the draft 2.1 and 2.3 are errors due to the fact the CP
is not in the chain and 2.2 is the fundamental reason for RSVP (soft
state)

so my question what remains ?

thanks,
-d.





"Adrian Farrel" <adrian@olddog.co.uk>
03/04/2007 12:16
Please respond to "Adrian Farrel"
 
        To:     "Diego Caviglia" <Diego.Caviglia@marconi.com>, "Dan Li" 
<danli@huawei.com>, "ccamp" <ccamp@ops.ietf.org>, Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc: 
        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!
> 
***************************************************************************************
>
>
>
>
>
>
>
>
>
>
>