[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 must disagree with you. Let us get out of the pure CCAMP context to come to the real world.
In transmission networks, we will see both control and management planes being used together for a long time. In transmission networks, operators are used to making manual operations even if equipments are control plane-enabled: programmed work, configuration of legacy rings where control plane does not exist, maintenance... More generally, one could always find some specific operational cases which need human intervention but which does not justify the development of a specific control plane feature.
You may try to solve this problem by saying this pool of resource is "purely" (provided this means something in terms of operations) handled by the control plane and that other pool is not seen; however, besides the fact that that kind of partitionning would still be configured manually with possible mistakes, you would have major drawbacks in terms of operations and resource optimization.
What is proposed in the ID is just a mechanism relying on a control plane protocol to detect *data plane* discrepencies which may occur because of the cross-connection nature of the circuit-switched world and of the manual operations you will never completely get rid of.
Regards,
Julien
-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Dimitri.Papadimitriou@alcatel-lucent.be
hi diego
not sure to understand, an automated control plane (at the end the purpose
of this WG) is used to control XC, and other related resource reservations
now you state that there could be manual operations that fails ??? i think
this simply falls outside the scope of the WG, on the other hand if some
TS are unproper for cross-connection i assume the CP does not even take
them into account, as label are downstream assigned where is the issue ?
thanks,
- d.
"Diego Caviglia \(GA/ERI\)" <diego.caviglia@ericsson.com>
Hi Dimitri,
there can an HW problem with the unit and some of its TS are
not good or for some reason that TS have been cross-connected by NMS for
error or may for testing at commissioning of the TNE and due to human
error have not been deleted and so on....
BR
Diego
-----Original Message-----
From: Dimitri.Papadimitriou@alcatel-lucent.be
[mailto: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>
> 03/04/2007 11:35
>
>
> 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
>
>
> 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