[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Solicit the comments on LMP Data Channel Status I-D
We in BT would also agree with you Julien...a CP is useful (noting that
signalling and routing functions don't have to be lumped together) but
the MP is always essential.
regards, Neil
> -----Original Message-----
> From: owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of MEURIC Julien
> RD-CORE-LAN
> Sent: 04 April 2007 09:45
> To: Dimitri.Papadimitriou@alcatel-lucent.be; Diego Caviglia (GA/ERI)
> Cc: ccamp@ops.ietf.org
> Subject: 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
>
>