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

["MEURIC Julien RD-CORE-LAN" <julien.meuric@orange-ftgroup.com>]

Hi Dimitri.

I agree case 2.2 might be borderline: this single specific case may be
not enough to trigger the proposed solution, but since there are other
drivers, the mechanism introduced could help solving that issue also.

Cheers,

Julien


-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Dimitri.Papadimitriou@alcatel-lucent.be

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>

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