[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Status of draft-ietf-ccamp-alarm-spec-00
vishal - some responses to the mail you were pointing out:
> Hi Lou,
>
> While the document describes well _what_ it is doing, I think it is
> not clear on why this needs to be done, why it is important
> (motivation), what requirements it is satisfying, and how they relate
> to the current WG charter.
> (Note this does not mean that the problem may not be important or
> should not be in the charter.)
as said in section 1
"The extensions defined in this document allow an operator or a
software component to obtain a full list of current alarms associated
with all of the resources used to support an LSP. The extensions
also ensure that this list is kept up-to-date and synchronized with
the real alarm status in the network. Finally, the extensions make
the list available at every node traversed by an LSP."
what else do you see useful as text ?
> Also, in response to your explanation below, it is not really clear
> that alarm reporting is a component of path setup. Seems to me that
> the two are decoupled.
the document doesn't say it a component of the "setup" - procedures are
described in section 3.2.2
> And, the "determing the actual route and other properties" phrase
> mentioned in the CCAMP WG charter I thought is aimed at addressing the
> issue of tunnel tracing (and determing LSP properties therefrom),
> rather than reporting alarms at specific nodes along the path of an
> LSP.
>
> With regard to your question, here is some additional feedback
> on the draft:
>
> -- The following phrase is actually unclear, as I explain below.
>
> also:
>
> The communication of alarms within GMPLS does not imply any
> modification in behavior of processing of alarms, or for the
> communication of alarms outside of GMPLS.
>
> If there is no modification in the behavior of alarm processing, then
> presumably there is already a way to monitor and process them, so how
> (and with what) does this communication help?
because as said in the introduction:
" The extension described in this document defines how the alarm
information associated with a GMPLS label-switched path (LSP) may be
communicated along the path of the LSP. Communication both upstream
and downstream is supported. The value in communicating such alarm
information is that this information is then available at every node
along the LSP for display and diagnostic purposes. "
> (I have seen the few phrases in the document in Section 1, along the
> lines of "there may be a desire to retain an LSP, particularly in
> optical transport networks, and communicate
> alarm information," but these do not say why.)
>
> -- The technique described in this draft relies on existing
> techniques for monitoring and correlating alarms, and appears to
> focus on the communication of this information along an LSP
> path.
> (While it may be argued that the latter is a "monitoring"
> function, I am not sure how strong an argument that is, since
> the monitoring (or most of it) has presumably happened before this
> communication begins.)
see procedure described in section 3.2.2
> -- Also, are there interactions/race conditions between this alarm
> communication with other mechanisms conveying problems along an LSP?
> Some discussion in the doc. would be valuable.
>
> -- The document mentions briefly that the LSP state must
> be retained for the communicated alarm information to be useful.
>
> I think this is an important point, and worth expanding on in the doc.
> I don't think there is any discussion right now of how one might
> ensure that state has not been torn down by the time the alarm
> information is correlated and ready to be communicated upstream
> and downstream.
agreed that as part of the last call process some text concerning the
two above point might be clarifying even if strictly speaking the first
one should be part of an applicability statement document
> -- And, can the document provide some examples of the types of alarms
> it is talking about/referring to? I think this will help a reader
> understand better the why behind this approach.
examples are illustrative anyway, if any they would be included in
appendix, imho such examples would better fit in an applicability
statement document
> -- Finally, I wasn't sure if the issue of enumeration dicussed
> with Tom Petch and Bert in Nov. was solved. (I saw that the draft
> refers to GR833 for Error String enumerations and to the ALARM-MIB
> for the Error Codes field.)
yes, it is.
> So these are my thoughts and feedback to the authors and WG.
> It may be good to hear from some other WG participants who have also
> read the document.
>
> -Vishal
Vishal Sharma wrote:
Adrian,
In discussions on this draft about a month ago, upon request from
the authors, I had provided some specific feedback to them
http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00184.html
Since the document was submitted as "draft-ietf" soon thereafter
without any changes, I don't think these changes/comments have
been addressed in the document thus far.
-Vishal
-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
Behalf Of Adrian Farrel
Sent: Thursday, April 22, 2004 1:57 AM
To: ccamp@ops.ietf.org
Cc: adrian@olddog.co.uk; lberger@movaz.com
Subject: Status of draft-ietf-ccamp-alarm-spec-00
All,
Despite its low revision number, this work is actually quite
mature and has
seen some early implementation.
I would like to get a sense from the working group for whether they think
this draft has been sufficiently developed to be moved to last call.
Hints
- I think it is ready for working group last call (but I'm an author)
- If you don't think it is ready, you MUST say what your issues with the
draft are. "Not discussed enough" is not a real reason.
Thanks,
Adrian
--
Papadimitriou Dimitri
E-mail : dimitri.papadimitriou@alcatel.be
E-mail : dpapadimitriou@psg.com
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone : +32 3 240-8491