Subject: Re: Question on Administratively down bit

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 19 Oct 2005 14:57:35 +0100

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" <[email-masked]>
To: <[email-masked]>
Cc: "Akira_NAGATA" <[email-masked]>
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 <[email-masked]>
>
>
>
>

---

From: Akira NAGATA <[email-masked]>
Date: Fri, 21 Oct 2005 14:51:33 +0900

Hi Adrian,

Thank you for your discussing this issue.

I understand that a hardware behavior triggered by AdminStatus bit 
will differ from one vendor to another.

Alarm inhibition is just an example of application by A-bit,
RFC3471 or 3473 can not achieve interoperability on the hardware behavior
itself triggered by A-bit in multi-vendor network. Is it right?
In a fact, I think it cannot be helped.

I believe, however, RFC3471 or 3473 shall achieve interoperability
on AdminStatus bit including A-bit from the perspective of message
handling, at least.

RFC3473 has no explicit clarification of handling A-bit or T-bit, 
where it has an explicit description of handling the pair of D and R-bit
(in Section 7.2).
In order to achieve interoperability at message level,
more explicit description will be needed for A-bit or T-bit
like the case of D+R-bit.

How do you think about this point?

According to my understanding using examples from D+R-bit in Sec 7.2.1,
Path/Resv sequence for alarm report inhibition by A-bit (i.e.
degradation
of established LSP) can be shown as following:

          Path (A=1, R=1)
ingress  -------------------> egress
node      Resv (A=1, R=0)     node
         <------------------

Similarly, Path/Resv sequence for enabling alarm report by A-bit
(i.e. activation of degradated LSP) can be shown as following:

          Path (A=0, R=1)
ingress  -------------------> egress
node      Resv (A=0, R=0)     node
         <------------------

Would you mind letting me know if something wrong?

best regards,
Akira

On Wed, 19 Oct 2005 14:57:35 +0100

---
Akira NAGATA <[email-masked]>
Photonic Node Laboratory, Photonics Networking Laboratories,
Fujitsu Laboratories Ltd.
TEL: +81-44-754-2765  FAX: +81-44-754-2741