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

From: [email-masked]
Date: Tue, 3 Apr 2007 11:57:12 +0200

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" <[email-masked]>
03/04/2007 11:35
 
        To:     "Dan Li <danli"
        cc:     "ccamp <ccamp", "\"\"Deborah A. Brungard\" <dbrungard\"", 
""[email-masked], Adrian" <adrian", Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Julien Meuric <julien.meuric", 
""[email-masked], 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 <[email-masked]> on 03/04/2007 10.47.58

To:    ccamp <[email-masked]>
cc:    "Deborah A. Brungard" <[email-masked]>, "Farrel, Adrian"
       <[email-masked]>, Dimitri Papadimitriou
       <[email-masked]>, Julien Meuric
       <[email-masked]>, Diego Caviglia
       <[email-masked]>, "Bardalai, Snigdho"
       <[email-masked]>

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!
***************************************************************************************

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 3 Apr 2007 11:16:23 +0100

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: <[email-masked]>
To: "Diego Caviglia" <[email-masked]>; "Dan Li" 
<[email-masked]>; "ccamp" <[email-masked]>
Sent: Tuesday, April 03, 2007 10:57 AM
Subject: Re: Solicit the comments on LMP Data Channel Status I-D

---

From: Dan Li <[email-masked]>
Date: Tue, 03 Apr 2007 18:30:06 +0800

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

---

From: [email-masked]
Date: Tue, 3 Apr 2007 19:23:06 +0200

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" <[email-masked]>
03/04/2007 12:16
Please respond to "Adrian Farrel"
 
        To:     "Diego Caviglia" <[email-masked]>, "Dan Li" 
<[email-masked]>, "ccamp" <[email-masked]>, Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc: 
        Subject:        Re: Solicit the comments on LMP Data Channel 
Status I-D

Hi Dimitri,

Is that what you said?

engineered to handle defects in the control plane (especially 
implementation 

A