RE: draft-berger-ccamp-gmpls-alarm-spec to WG status?

["Vishal Sharma" <v.sharma@ieee.org>]

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

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.
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?
(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.)

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

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

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

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


> -----Original Message-----
> From: Lou Berger [mailto:lberger@movaz.com]
> Sent: Sunday, March 07, 2004 5:41 AM
> To: Vishal Sharma
> Cc: Adrian Farrel; ccamp@ops.ietf.org
> Subject: RE: draft-berger-ccamp-gmpls-alarm-spec to WG status?
>
>
> Vishal,
>
> As to fit&charter:  This work extends the path setup portion of common
> control plane protocol defined by the WG, namely GMPLS-RSVP.
> Additionally
> this work matches the work item, note asterisks "Define a
> protocol that can
> determine the actual route and **other properties** of paths set up by
> CCAMP signaling protocols..."  You might also want to check out Hiro
> Ishimatsu's comment  from last November on this topic on the list.
>
> As to the other issues:  In addition to Dimitri's references, the
> document
> already states:
>
>     Some operators may consider alarm information as sensitive.  To
>     support environments where this is the case, implementations SHOULD
>     allow the user to disable the generation of ALARM_SPEC objects.
>
> 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.
>
> What additional clarifications do you think are need in the text?
>
> Lou
>
> At 03:45 PM 3/6/2004 -0500, Vishal Sharma wrote:
>
> >Folks,
> >
> >It would be useful for the draft to state how it fits into the CCAMP
> >WG, and how it relates to the charter.
> >
> >One of my concerns is that exposing alarm information is something
> >that the providers may _not_ want. Moreover, there are already likely
> >to be other methods by which a provider coordinates alarm information
> >through their network (and layers), without having it be communicated
> >explicitly via signaling.
> >
> >Some clarification on these points would be useful. Until such time,
> >I would prefer to hold off on it being brought under the wing of the WG.
> >
> >-Vishal
> >
> > > -----Original Message-----
> > > From: owner-ccamp@ops.ietf.org
> > [<mailto:owner-ccamp@ops.ietf.org>mailto:owner-ccamp@ops.ietf.org]On
> > > Behalf Of Adrian Farrel
> > > Sent: Saturday, March 06, 2004 4:21 AM
> > > To: ccamp@ops.ietf.org
> > > Subject: draft-berger-ccamp-gmpls-alarm-spec to WG status?
> > >
> > >
> > > In Seoul we ran out of time before we could discuss this draft.
> > >
> > > However, the draft is pretty stable, and it is the opinion of the
> > > authors that this should
> > > be brought under the wing of the WG.
> > >
> > > Can you please send your opinions to the list or to the chairs direct.
> > >
> > > Silence (as usual) will be interpreted as you saying nothing.
> > >
> > >
> >
> <http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-alar
> m>http://www.ietf.org/internet-drafts/draft-berger-ccamp-gmpls-alarm
> >
> > > -spec-01.txt
> > >
> > > Thanks,
> > > Adrian
> > >