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

[Dimitri.Papadimitriou@alcatel.be]

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