[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 Dimitri,

see in line.

-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: Thursday, August 24, 2006 3:57 AM
Subject: 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)



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



[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
[dan] This solution you have suggested sounds very interesting, I will look at it. 



-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