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

From: "Diego Caviglia" <[email-masked]>
Date: Wed, 23 Aug 2006 11:31:23 +0200

Hi Dan,
        first of all I think that the ID addresses a real problem.

Regarding the bits and bytes I prefer to not implemet new messages but just
updateds the existing ones that seems to fit to the problem.

I think that having a timeslot that should be usable that is actually
unusable is a failure from the control plane prespective.

So I think that is correct to use the Fault Management Messages to convey
information about unusable channles.

Regards

Diego

Dan Li <[email-masked]>@ops.ietf.org on 23/08/2006 09.55.49

Sent by:    [email-masked]

To:    [email-masked], "Zafar Ali (zali)" <[email-masked]>, MEURIC
       Julien RD-CORE-LAN <[email-masked]>
cc:    ccamp <[email-masked]>

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" <[email-masked]>
To: "Zafar Ali (zali)" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Cc: "ccamp" <[email-masked]>
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: [email-masked] [mailto:[email-masked]] 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

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 23 Aug 2006 12:49:33 +0100

Hi all,

The problem statement in this draft is clear, and it seems to me that this 
problem might arise in a real network depending on the way the network is 
managed.

It is also clear to me that the current signaling protocols handle this type 
of problem , but that the process is not ideal. That is, LSPs would not 
necessarily fail to set up, but there might be some exchange of PathErr 
messages with Acceptable Label Set objects. Since the problem described in 
the draft is likely to be persistent, this signaling exchange would possibly 
be required on every LSP setup that uses the link in question. Functional, 
but not ideal.

It would be good if you could add a short sub-section to section 2 to 
describe how the existing signaling protocols will handle the problem and 
why you believe that this is not adequate.

Now, in general, we don't develop protocol extensions to optimise for error 
cases, so we have to be careful. If your proposals required continuous 
monitoring of available resources on each link, that would be a step to far. 
But if your proposal reflects a start-of-day cross-check followed 
(optionally) by updates triggered by operator intervention or infrequent 
timers, that is likely to be acceptable.

With regard to the use of existing messages or the definition of new 
messages: there are architectural and implementation choices. Although we 
inevitably need to be driven by the implementations, I am not a fan of 
overloading messages. IMHO the Fault Management messages are currently 
triggered by a perceived fault: they are used to report and isolated faults. 
The new function is used to detect faults, not to report or isolate them.

While I can see Diego's point that the objective is to find faults, the 
messages proposed by Dan do not report faults, they report information. 
Faults are only detected when the correlation between information at the two 
ends of the link is made. I think that if you wanted to go down the route 
suggested by Diego you would probably want to limit the information 
exchanged to only the data channels that are suspect, but I don't see how 
you can report the channels that are not available (because you might not 
know about them!) - it is only by hearing about the channels that your 
partner believes exist that you can deduce problems.

In terms of implementation, it really doesn't seem to be very expensive 
either way. You might want to consider how backward compatibility works with 
the two options. It is pretty clear how to handle a new message type that is 
not supported. What will be the impact of adding new TLVs to existing 
messages?

Cheers,
Adrian
----- Original Message ----- 
From: "Diego Caviglia" <[email-masked]>
To: "Dan Li <danli" <[email-masked]>
Cc: "xuhuiying" <[email-masked]>; "Zafar Ali (zali) <zali" 
<[email-masked]>; "MEURIC Julien RD-CORE-LAN <julien.meuric" 
<[email-masked]>; "ccamp <ccamp" <[email-masked]>
Sent: Wednesday, August 23, 2006 10:31 AM
Subject: Re: High level comment on 
draft-li-ccamp-confirm-data-channel-status-00.txt,