Re: Question on Administratively down bit

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi Akira,

I have been thinking about your question and discussing it with a few
people.

The general consensus is that it is important to have well-defined
mechanisms for the signaling exchange of the Admin Status bits, but that
the actions to take on receipt of some the bits may be dependent on local
policy or on data plane technology.

Thus an implementation may decide that certain alarms should be suppressed
during LSP establishment because it knows them to be "false" alarms
triggered by the process of establishing the LSP. On the other hand, an
implementation may decide that other alarms that are first raised during
LSP establishment represent a different set of circumstances and should be
raised. I would be worried if we tried to list and categorise all such
alarms within the CCAMP working group.

It might be useful to consider whether the behavior of switch under alarm
suppression conditions should be configurable to allow the operator to
select consistent behavior, or whether this is adding too much complexity.

Cheers,
Adrian

----- Original Message ----- 
From: "Akira NAGATA" <nagata.akira@jp.fujitsu.com>
To: <ccamp@ops.ietf.org>
Cc: "Akira_NAGATA" <nagata.akira@jp.fujitsu.com>
Sent: Friday, August 19, 2005 12:13 PM
Subject: Question on Administratively down bit


> Mr. Lou Berger and editors of RFC3471 and RFC3473,
>
> This is my first time to send e-mail to ccamp.
> Thanks in advance.
>
> I'd like to ask one question about the handling of Administratively down
bit
> in GMPLS RSVP-TE's Admin_Status object.
>
> RFC3471 introduces "inhibiting alarm reporting" as an example
application
> of local action to "down" state (that is, A-bit=1) in Section 8.
> But I can't find any other explicit descriptions about this procedure
> in RFC3471 or 3473.
>
> I understand that actions to be taken by each node receiving
Admin_Status
> object shall be based on local policy.
>
> With regard to inhibition of alarm reporting, however, in order to
achieve it
> through end-to-end, I believe that we had better take a unified action
> as a response to A-bit ("down" or "up").
> Operator will expect this feature.
>
> (Here I mean alarm report is not reporting via RSVP messages as
described
> in ID-alarm-spec, but one from NE to external system such as network
> management system.)
>
> Are there any considerations, drafts or RFCs to define it?
>
> Thanks,
> ---
> Akira NAGATA <nagata.akira@jp.fujitsu.com>
>
>
>
>