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

[Dan Li <danli@huawei.com>]

Hi Dimitri,

Please see in-line.

Regards,

Dan

----- Original Message ----- 
From: <Dimitri.Papadimitriou@alcatel.be>
To: "Dan Li" <danli@huawei.com>
Cc: "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>
Sent: Wednesday, August 23, 2006 8:45 PM
Subject: Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt,


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

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


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

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


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