Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt,

From: Dan Li <[email-masked]>
Date: Wed, 23 Aug 2006 15:55:49 +0800

Hi,

Thanks Julien and Zafar for your comments. I agree with Julien. This I-D just wants to provide a control plane tool to detect the inconsistent data channel status in the tranport plane.

Actually I have received several private emails think this I-D addresses a real problem, but regarding the new LMP messages which are introduced in this I-D, some people pointed out that the already deployed channelstatus messages (id = 17, 18, 19 and 20) may be extended to carry also the timeslot information instead only data link. But I have a concern that the Fault Management Messages usually are triggered by fault detection, these messages should not be sent if no fault is detected. The confirmation of data channel status may need to be performed periodically or triggerd by user.

I would like to hear from you guys, what's your comments? Not only the concerns raised above, but also other issues in this I-D.

Regards,

Dan

----- Original Message ----- 
From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
To: "Zafar Ali (zali)" <[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: "ccamp" <[email-masked]>
Sent: Tuesday, July 11, 2006 2:31 AM
Subject: RE: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt,

Hi Zafar.

I don't really get you on this. I figure out you're referring to
removing the connection states when RSVP refreshes are not received any
more, aren't you? If so, I'm afraid this is not enough for transmission
devices, where resources can be physically cross-connected even though
there is no (or no longer) corresponding RSVP state. Therefore having a
mechanism to avoid such discrepancies would be welcome.

Regards,

Julien

P.S.: If you totally rely on a management plane, I agree this should be
useless (e.g. the NMS should already know if a cross-connection deletion
failed, cf. Diego's 2nd slides seen this morning).

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Zafar Ali (zali)

Dear Authors, 
 
RSVP refreshes do this job, so I am not sure motivation for this draft/
LMP extensions. 
 
n.b. The draft state, "Although such a situation can be resolved through
the use of the Acceptable Label Set object in GMPLS signaling [RFC3473],
such a procedure is inefficient since it may require an additional
signaling exchange for each LSP that is set up", so I assume that RSVP
signaling is present (Although I did not understand the quoted statement
from the ID). Even if RSVP is not present, e.g., optical core is
completely controlled by a management entity, I would argue introduce
presence of LMP. 
 
Thanks
 
Regards... Zafar

---

From: [email-masked]
Date: Wed, 23 Aug 2006 14:45:41 +0200

just a brief remark

i don't see why channel status verification can not be achieved with 
current mechanism described in section 12.7 of 4204 (and there is a
need to come with a complete set of messages for this purpose)

now i am even unclear how the problem you stated can occur

"The channel status of a data link may become mismatched during the 
   LSP deletion process. If the LSP deletion process is aborted in the 
   middle of the process (perhaps because of a temporary control plane 
   failure), the cross-connection at the upstream node may be removed 
   while the downstream node still keeps its cross-connection."

why do you think the notion of soft-state has been introduced ? once
the cleanup timeout (set to K times the refresh timeout) interval is
reached that then triggers a tear-down

thanks,
- d.

Dan Li <[email-masked]>
Sent by: [email-masked]
23/08/2006 09:55
 
        To:     [email-masked], "Zafar Ali (zali)" <[email-masked]>, 
MEURIC Julien RD-CORE-LAN <[email-masked]>
        cc:     ccamp <[email-masked]>
        Subject:        Re: High level comment on 
draft-li-ccamp-confirm-data-channel-status-00.txt,

Hi,

Thanks Julien and Zafar for your comments. I agree with Julien. This I-D 
just wants to provide a control plane tool to detect the inconsistent data 
channel status in the tranport plane.

Actually I have received several private emails think this I-D addresses a 
real problem, but regarding the new LMP messages which are introduced in 
this I-D, some people pointed out that the already deployed channelstatus 
messages (id = 17, 18, 19 and 20) may be extended to carry also the 
timeslot information instead only data link. But I have a concern that the 
Fault Management Messages usually are triggered by fault detection, these 
messages should not be sent if no fault is detected. The confirmation of 
data channel status may need to be performed periodically or triggerd by 
user.

I would like to hear from you guys, what's your comments? Not only the 
concerns raised above, but also other issues in this I-D.

Regards,

Dan

----- Original Message ----- 
From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
To: "Zafar Ali (zali)" <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Cc: "ccamp" <[email-masked]>
Sent: Tuesday, July 11, 2006 2:31 AM
Subject: RE: High level comment on 
draft-li-ccamp-confirm-data-channel-status-00.txt,

Hi Zafar.

Regards,

Julien

Dear Authors, 

 
Thanks
 
Regards... Zafar

---

From: Snigdho Bardalai <[email-masked]>
Date: Wed, 23 Aug 2006 11:14:32 -0500

Hi Dimitri,

Since a control-channel failure leads to RSVP hello failure the clean-up
timeout event will not occur (due to auto-refresh).

In case an intermediate or egress node initiates the deletion process and
there is a temporary control-plane failure that disallows the delete request
from reaching the ingress node, then there is a potential problem.

Even though the intermediate or egress node initiates the force deletion 
process
after the "no-response" timer expires the connection may get re-created once
the control-plane recovers, because the ingress may continuously be 
transmitting
Path messages. Even if the Path message contains the RECOVERY object, this
will cause re-creation of the connection (Refer to RFC 3473 Section 9.5.2).

One posible solution is to carry out a channel-status audit in order to 
detect
such anamolies.

Regards,
Snigdho

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 23 Aug 2006 19:43:27 +0100

Dimitri,

I think you are focusing in too closely on an example of how the problem can 
arise. The problem is simply that it is possible that the resources are not 
available in the same way at both ends of the link. The discussion then went 
down the path of how this might arise, and we have become stuck in a 
detailed example. Perhaps a better example would be the failure of a 
hardware component that is represents a label on the TE link, where the 
failure is known at the local node, but cannot be communicated to the remote 
node.

But related to your specific discussion...

> i am not sure to capture your point - let's say states are self-refreshed
> for some time, if the signaling channel is not up before pre-negotiated
> time - and you didn't fix this timer as being infinite - resources will be
> released when the cleanup elapses

So you are saying that there is a timer that can be set on the Hello such 
that if the Hello adjacency is not re-established in that time, all LSPs 
should be torn down. Yes. This is the Restart Cap object Restart Time.

But you say if "you didn't fix this timer as being infinite". But actually 
let's think about how operators like to use this timer. Sure they can say, I 
expect the CP to restart after a fault in 10 minutes, but wht about hardware 
faults? The CPU running the CP could fry, that is likely
to require a truck roll, and the user traffic must not be torn down just 
because of this fault.

So the Restart Time is typically set quite large. You will hear many people 
say that the user traffic is absolute - it must never be torn down because 
of a CP failure - and these people set the Restart Timer to all-f.

Now, once the time has been set large, we don't have automatic cleanup. So 
the cross-connects can get into a mess.

> in case one requires larger maintenance
> windows one provides such configuration beforehand

But note that this is not planned maintenance.

> mis-using one
> mechanism and then require another to reconstruct consistent states is the
> first point that needs to be clarified

So, are you saying that my description, above, represents a mis-use?
If so, how should I configure the Restart Time so that I can survive long CP 
outages?

> (it is also important to clarify
> that LMP does not "reserve resources" it just mediates data link states so
> if the error needs to be corrected it will any interfere with the entity
> that is making use of it

Completely agree with this point. LMP can report problems, but cannot fix 
them.

> what you are trying to achieve is detect mismatch but detect these mismach
> is not a solution to the problem

Agree completely.
What you have suggested before is that prevention is sufficient.
What I believe is that prevention of all cases is probably not possible, 
therefore detection and cure will be needed.

Detection (you are right) is not the same as cure. But cure without 
detection is improbable.

Note that cure is not necessarily the objective! There is a separate problem 
(sending Path with bad choice of label) that can be prevented after 
detection, without the need for cure.

Cure probably reuqires operator intervention.

> but more importantly what is the trigger
> to the detection itself? in brief how does one either of these sides
> knows it should start such "verification" process ... was it not at the
> end the reason for possibility of maintaining the "available" link on
> permanent verification state within LMP ?

Understanding the trigger for the detection process is important.

Section 4 of the I-D currently says:
   The data channel status confirmation related LMP messages are sent
   between adjacent nodes periodically or driven by some events

and this is not enough. We would need to know some more about the "period" 
and the "events" to assess whether this is going to flood the control 
channel or not provide the information in a timely manner.

For example, one could use the receipt of an Acceptable Label Set object 
(and some parsing thereof) as a trigger event.

Cheers,
Adrian

---

From: [email-masked]
Date: Wed, 23 Aug 2006 20:12:49 +0200

hi - 

i am not sure to capture your point - let's say states are self-refreshed 
for some time, if the signaling channel is not up before pre-negotiated 
time - and you didn't fix this timer as being infinite - resources will be 
released when the cleanup elapses, in case one requires larger maintenance 
windows one provides such configuration beforehand => mis-using one 
mechanism and then require another to reconstruct consistent states is the 
first point that needs to be clarified (it is also important to clarify 
that LMP does not "reserve resources" it just mediates data link states so 
if the error needs to be corrected it will any interfere with the entituy 
that is making use of it

what you are trying to achieve is detect mismatch but detect these mismach 
is not a solution to the problem but more importantly what is the trigger 
to the detection itself ? in brief how does one either of these sides 
knows it should start such "verification" process ... was it not at the 
end the reason for possibility of maintaining the "available" link on 
permanent verification state within LMP ?

thanks,
-d.

Snigdho Bardalai <[email-masked]>
23/08/2006 18:14
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     Dan Li <[email-masked]>, ccamp <[email-masked]>, 
MEURIC Julien RD-CORE-LAN <[email-masked]>, 
[email-masked], [email-masked], "Zafar Ali (zali)" 
<[email-masked]>
        Subject:        Re: High level comment on 
draft-li-ccamp-confirm-data-channel-status-00.txt,

Hi Dimitri,

In case an intermediate or egress node initiates the deletion process and
there is a temporary control-plane failure that disallows the delete 
request
from reaching the ingress node, then there is a potential problem.

Even though the intermediate or egress node initiates the force deletion 
process
after the "no-response" timer expires the connection may get re-created 
once
the control-plane recovers, because the ingress may continuously be 
transmitting
Path messages. Even if the Path message contains the RECOVERY object, this
will cause re-creation of the connection (Refer to RFC 3473 Section 
9.5.2).

Regards,
Snigdho

---

From: Dan Li <[email-masked]>
Date: Thu, 24 Aug 2006 14:29:47 +0800

Hi Dimitri,

Please see in-line.

Regards,

Dan

----- Original Message ----- 
From: <[email-masked]>
To: "Dan Li" <[email-masked]>
Cc: "ccamp" <[email-masked]>; "MEURIC Julien RD-CORE-LAN" <[email-masked]>; <[email-masked]>; <[email-masked]>; "Zafar Ali (zali)" <[email-masked]>
Sent: Wednesday, August 23, 2006 8:45 PM
Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt,

> need to come with a complete set of messages for this purpose)

[dan] I agree that the LMP messages (17, 18, 19) can do the channel status
verification with some extensions. My concern is that these messages are
used for the fault management, but the inconsistent data channel status may
be is not a failure, for example it may be configured on purpose. 

> reached that then triggers a tear-down

[dan] In optical transport networks, the control plane failure should not
affect the traffic carried by the transport plane. So usually the cross-connect
in the transport plane will not be removed when there is a failure in the control
plane, that's why I stated the problem described in this I-D is real.

---

From: [email-masked]
Date: Thu, 24 Aug 2006 09:57:17 +0200

hi -

[dan] In optical transport networks, the control plane failure should not
affect the traffic carried by the transport plane. So usually the 
cross-connect
in the transport plane will not be removed when there is a failure in the 
control
plane, that's why I stated the problem described in this I-D is real.

[dimitri] I think this has been worked out (see RFC 3473, and related) 
such as to prevent drawbacks of releasing resources while there is known 
period during which states can be re-build (using neighbors as helpers)

[dimitri] The concern is if parameters are set such as to make behavior 
being equivalent to a hard state protocol the proposal you made is solving 
a corner case from a mis-use of the protocol mechanisms we have at hand

[dimitri] I understand from Adrian's reply that the case we're dealing 
with is due restart/recovery timers that are set such as to support large 
period of CP outage - where one can not rely on cleanup

[dimitri] I can accept this is a consequence of setting existing 
parameters - but my answer to this is "ok but why shall we have LMP 
intervening in this process if the operator wants to wait for very large 
periods" ... this leads to the (partial) conclusion that i can assume 
their can be cases where the data plane itself may introduce an 
inconsistency (would be interesting to have the viewpoint of "optical 
hardware expert" here) but i don't see how we can have cases where the 
control plane if correctly used and configured can be the instigator of 
such cases 

[dimitri] concerning the detection, the issue resulting from this is that 
the "available" side should - per 4204 - start an LMP verification ... 
pointing to 4204 "Therefore, to ensure proper verification of data link 
connectivity, it is required that, until the data links are allocated for 
user traffic, they must be opaque (i.e., lose their transparency).  To 
support various degrees of opaqueness (e.g., examining overhead bytes, 
terminating the IP payload, etc.) and, hence, different mechanisms to 
transport the Test messages, a Verify Transport Mechanism field is 
included in the BeginVerify and BeginVerifyAck messages." which result in 
"when data links are de-allocated" they should re-enter that state ... the 
issue is that the BeginVerify does not exchange DATA LINK but LINK objects 
(there is no flags in the former) hence the only reply you would receive 
is "unwilling to verify" while ideally you should receive "unwilling to 
verify (allocated)" such as the other side can map it with local knowledge 
and detect the mismatch

-d.

24/08/2006 08:29
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     ccamp <[email-masked]>, MEURIC Julien RD-CORE-LAN 
<[email-masked]>, [email-masked], 
[email-masked], "Zafar Ali (zali)" <[email-masked]>
        Subject:        Re: High level comment on 
draft-li-ccamp-confirm-data-channel-status-00.txt,

Hi Dimitri,

Please see in-line.

Regards,

Dan

----- Original Message ----- 
From: <[email-masked]>
To: "Dan Li" <[email-masked]>
Cc: "ccamp" <[email-masked]>; "MEURIC Julien RD-CORE-LAN" 
<[email-masked]>; <[email-masked]>; 
<[email-masked]>; "Zafar Ali (zali)" <[email-masked]>
Sent: Wednesday, August 23, 2006 8:45 PM
Subject: Re: High level comment on 
draft-li-ccamp-confirm-data-channel-status-00.txt,

[dan] I agree that the LMP messages (17, 18, 19) can do the channel status
verification with some extensions. My concern is that these messages are
used for the fault management, but the inconsistent data channel status 
may
be is not a failure, for example it may be configured on purpose. 

[dan] In optical transport networks, the control plane failure should not
affect the traffic carried by the transport plane. So usually the 
cross-connect
in the transport plane will not be removed when there is a failure in the 
control
plane, that's why I stated the problem described in this I-D is real.

---

From: Dan Li <[email-masked]>
Date: Thu, 24 Aug 2006 09:29:01 -0400

Hi Dimitri,

see in line.

-Dan

----- Original Message ----- 
From: <[email-masked]>
To: "Dan Li" <[email-masked]>
Cc: "ccamp" <[email-masked]>; "MEURIC Julien RD-CORE-LAN" 
Sent: Thursday, August 24, 2006 3:57 AM

> period during which states can be re-build (using neighbors as helpers)

[dan] Sorry, maybe I didn't make it clear. What I mean was during the LSP
deletion procedure, if one node just happen to be restarted when it receives 
the
message to release the transport resource. This situation results in the 
inconsistent
data channel status because of the large timer setting. Before the large 
timer
to be expired, we can not use the inconsistent data channel.

[dan] In order to ensure that the traffic carried by the transport plane is 
not
affected due to the control plane failure, we have to set a large timer. But
on the other hand, when we really want to release the transport resource,
we hope the timer is small enough to ensure the resource can be released
as soon as possible when there is a problem on the control plane.

> verify (allocated)" such as the other side can map it with local knowledge

[dan] This solution you have suggested sounds very interesting, I will look 
at it.