[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,
If you are in a SONET/SDH environment I'm pretty sure you'll use bidirectional LSP with upstream and downstream label set to the same value.
In that condition labels are chosen by upstream node.
Not sure to get your point. The possible failures I've highlighted in my e-mail are already managed by CP. OSPF-TE will advertise that the available bw of, say a STM4 with a 'broken' TS, is not 4 VC4 and 1 VC4_4c but is 3 VC4 and 0 VC4_4c. The problem is that, for scalability reason, it is not advertised which VC4 is not usable.
In my understanding the ID tries to address that case, sharing information about which TS is good and which is not at link level.
Ciao
Diego
-----Original Message-----
From: Dimitri.Papadimitriou@alcatel-lucent.be [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]
Sent: mercoledì 4 aprile 2007 9.19
To: Diego Caviglia (GA/ERI)
Cc: ccamp@ops.ietf.org; owner-ccamp@ops.ietf.org
Subject: RE: Solicit the comments on LMP Data Channel Status I-D
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>
Sent by: owner-ccamp@ops.ietf.org
04/04/2007 09:05
To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: <ccamp@ops.ietf.org>, <owner-ccamp@ops.ietf.org>
Subject: RE: Solicit the comments on LMP Data Channel
Status I-D
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]
Sent: martedì 3 aprile 2007 19.29
To: Diego Caviglia (GA/ERI)
Cc: ccamp@ops.ietf.org; owner-ccamp@ops.ietf.org
Subject: Re: Solicit the comments on LMP Data Channel Status I-D
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>
Sent by: owner-ccamp@ops.ietf.org
03/04/2007 13:26
To: <ccamp@ops.ietf.org>
cc:
Subject: Re: Solicit the comments on LMP Data Channel
Status I-D
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
>
> To: "Diego Caviglia" <Diego.Caviglia@marconi.com>, Dan Li
> <danli@huawei.com>, ccamp <ccamp@ops.ietf.org>
> cc:
>
> 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!
>
***************************************************************************************
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>