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

[Dimitri.Papadimitriou@alcatel.be]

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 <Snigdho.Bardalai@us.fujitsu.com>
23/08/2006 18:14
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     Dan Li <danli@huawei.com>, ccamp <ccamp@ops.ietf.org>, 
MEURIC Julien RD-CORE-LAN <julien.meuric@orange-ft.com>, 
owner-ccamp@ops.ietf.org, xuhuiying@huawei.com, "Zafar Ali (zali)" 
<zali@cisco.com>
        Subject:        Re: High level comment on 
draft-li-ccamp-confirm-data-channel-status-00.txt,


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

Dimitri.Papadimitriou@alcatel.be wrote:

>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 <danli@huawei.com>
>Sent by: owner-ccamp@ops.ietf.org
>23/08/2006 09:55
> 
>        To:     xuhuiying@huawei.com, "Zafar Ali (zali)" 
<zali@cisco.com>, 
>MEURIC Julien RD-CORE-LAN <julien.meuric@orange-ft.com>
>        cc:     ccamp <ccamp@ops.ietf.org>
>        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" <julien.meuric@orange-ft.com>
>To: "Zafar Ali (zali)" <zali@cisco.com>; <xuhuiying@huawei.com>; 
><danli@huawei.com>
>Cc: "ccamp" <ccamp@ops.ietf.org>
>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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] 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 
>
>
>
>
> 
>