[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt,
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.
Dan Li <danli@huawei.com>
24/08/2006 08:29
To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
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>
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: <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
>
>
>
>