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

From: "Diego Caviglia \(GA/ERI\)" <[email-masked]>
Date: Tue, 3 Apr 2007 13:26:32 +0200

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
>
>
>
>
>
>
> [email-masked] on 03/04/2007 11.57.12
>
> To:    "Diego Caviglia" <[email-masked]>, Dan Li
>       <[email-masked]>, ccamp <[email-masked]>
> 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" <[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: [email-masked]
Date: Tue, 3 Apr 2007 19:29:07 +0200

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\)" <[email-masked]>
Sent by: [email-masked]
03/04/2007 13:26
 
        To:     <[email-masked]>
        cc: 

This was bounced.
 
D

---

From: "Diego Caviglia \(GA/ERI\)" <[email-masked]>
Date: Wed, 4 Apr 2007 09:05:25 +0200

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: [email-masked] [mailto:[email-masked]] 
Sent: martedì 3 aprile 2007 19.29
To: Diego Caviglia (GA/ERI)
Cc: [email-masked]; [email-masked]
Subject: Re: Solicit the comments on LMP Data Channel Status I-D

diego

thanks,
-d.

        To:     <[email-masked]>
        cc: 

This was bounced.
 
D

---

From: [email-masked]
Date: Wed, 4 Apr 2007 09:19:25 +0200

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.

04/04/2007 09:05
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     <[email-masked]>, <[email-masked]>
        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: [email-masked] 
[mailto:[email-masked]] 
Sent: martedì 3 aprile 2007 19.29
To: Diego Caviglia (GA/ERI)
Cc: [email-masked]; [email-masked]
Subject: Re: Solicit the comments on LMP Data Channel Status I-D

diego

thanks,
-d.

        To:     <[email-masked]>
        cc: 

This was bounced.
 
D

---

From: "Diego Caviglia \(GA/ERI\)" <[email-masked]>
Date: Wed, 4 Apr 2007 09:27:34 +0200

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: [email-masked] [mailto:[email-masked]] 
Sent: mercoledì 4 aprile 2007 9.19
To: Diego Caviglia (GA/ERI)
Cc: [email-masked]; [email-masked]
Subject: RE: Solicit the comments on LMP Data Channel Status I-D

hi diego

thanks,
- d.

Hi Dimitri,

BR

Diego

-----Original Message-----

diego

thanks,
-d.

        To:     <[email-masked]>
        cc: 

This was bounced.
 
D

---

From: [email-masked]
Date: Wed, 4 Apr 2007 09:40:53 +0200

diego

what you are stating is that changing the CP state of some local resources 
(at granularity not advertized to neighbors via routing) MAY require 
re-sync with neighbors such as to prevent label mismatch in case you are 
enforcing same label in both directions 

but we have already the min/max reservable subobject in LMP (hence it is a 
pure TS mismatch that you try to detect) 

on the other side:

as TS where not visible to LMP i fail to see why do not re-sync label 
space that can be used via signaling on the upstream node then ?

in case of explicit label routing your technique won't work anyway

thanks,
- d.

04/04/2007 09:27

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. 

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

hi diego

thanks,
- d.

Hi Dimitri,

BR

Diego

-----Original Message-----

diego

thanks,
-d.

        To:     <[email-masked]>
        cc: 

This was bounced.
 
D

---

From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
Date: Wed, 4 Apr 2007 10:30:58 +0200

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: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]

diego

thanks,
-d.

This was bounced.
 
D

> So NE-A can choose Timeslot 2 because it see it good while is not good

in
> to clean up a partitioned control plane, etc.) we believe that it
would 
be
> The problem is particularly bad when the data link is a component link

of

---

From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
Date: Wed, 4 Apr 2007 10:44:35 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]

hi diego

thanks,
- d.

Hi Dimitri,

BR

Diego

-----Original Message-----

diego

thanks,
-d.

This was bounced.
 
D

in
of

---

From: <[email-masked]>
Date: Wed, 4 Apr 2007 09:56:46 +0100

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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of MEURIC Julien 
> RD-CORE-LAN
> Sent: 04 April 2007 09:45
> To: [email-masked]; Diego Caviglia (GA/ERI)
> Cc: [email-masked]
> 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
> 
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> 
> hi diego
> 
> but this is kernel of the problem, the origin tells where the 
> solution shall be targeted 
> 
> >            my understunding of the ID was that it tries to 
> > 'synchronize' the status of the timeslots that are facing the same 
> > link.
> >
> > NE-B.  I think that the reason wht timeslot 2 is not usable 
> is out of
> the
> > scope of the ID.
> >
> > BR
> >
> > Diego
> >
> >
> >
> >
> >
> >
> > (including control plane failure and restart, management plane 
> > intervention,
> attempt
> > problem. Resolution of the problem remains an issue for the 
> management 
> > plane."
> >
> > are introducing in this control plane are just breaking one of the 
> > main design principle of networks
> >
> > 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
> > 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.
> >
> > problem in the network so that we can judge whether to ask 
> the chairs 
> > to make this a WG draft. Best regards,
> >
> >
> > Dan Li
> >

---

From: Dan Li <[email-masked]>
Date: Wed, 04 Apr 2007 20:14:38 +0800

Hi all,

For case 2.2, as we have described in the draft, I think it's a local policy decision how this mismatched state should be handled. Some deployments may decide to automatically clean up the data plane state so it matches the control plane state, but others may choose to raise an alert to the management plane and leave the data plane untouched just in case it is in use. In such cases, data channel mismatches may arise after restart and might not be cleared up by the restart procedures.

Regards,

Dan

---

From: [email-masked]
Date: Wed, 4 Apr 2007 16:46:41 +0200

hello julien

i think we are diverging in this discussion - imho, the questions are 

is the proposal intended to detect running data plane failures resulting 
from some control plane component e.g. signaling ? or 
mis-use/mis-configurations triggered by user/management plane/others ?

is the proposal intended to provide near real time mechanism (fast 
detection) or an off-line mechanism (diagnostic) ? what is the diameter of 
the detection/verification such as to ensure proper localisation ?

what is the expectation from the control plane and mechanism like those 
enabled by LMP (i.e. why LMP is suitable both in terms of messaging and 
processing) ?

thanks,
-d. 

"MEURIC Julien RD-CORE-LAN" <[email-masked]>
Sent by: [email-masked]
04/04/2007 10:44
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Diego Caviglia 
\(GA/ERI\)" <[email-masked]>
        cc:     <[email-masked]>
        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: [email-masked] [mailto:[email-masked]] On Behalf 
Of [email-masked]

hi diego

thanks,
- d.

Hi Dimitri,

BR

Diego

-----Original Message-----

diego

thanks,
-d.

This was bounced.
 
D

in
of

---

From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
Date: Thu, 5 Apr 2007 10:17:40 +0200

Hi Dimitri.

Please, see my answer in-line.

Regards,

Julien

-----Original Message-----

hello julien

i think we are diverging in this discussion

[JM] I don't believe so. The requirement does not come from a lack in
GMPLS specifications themselves but rather from operational concerns
because, in most cases, GMPLS-controlled networks will co-exist with
legacy networks and legacy procedures.

- imho, the questions are 

[JM] I think both could occur, but human mistake is probably the major
factor to deal with. If you are fearing we may be dealing with broken
implementations, I would say it is not the idea.

is the proposal intended to provide near real time mechanism (fast 
detection) or an off-line mechanism (diagnostic) ? what is the diameter
of 
the detection/verification such as to ensure proper localisation ?

[JM] Here, I feel that is up to the operator, but in my view it would
rather be a periodical or an on-demand procedure.

[JM] As LMP is already used to verify data plane connectivity, I
consider it is an apropriate candidate to support this feature. Anyway,
if you have a more suitable protocol to propose, I think it is not too
late to take it into account.

thanks,
-d. 

        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Diego
Caviglia 
\(GA/ERI\)" <[email-masked]>
        cc:     <[email-masked]>
        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.

always find some specific operational cases which need human
intervention 

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

Regards,

Julien

-----Original Message-----
Behalf 

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 

thanks,
- d.

Hi Dimitri,

BR

Diego

-----Original Message-----

diego

thanks,
-d.

This was bounced.
 
D

>            my understunding of the ID was that it tries to
'synchronize'

in
would 
be
> are introducing in this control plane are just breaking one of the
main

of