Re: Question on Administratively down bit

[Akira NAGATA <nagata.akira@jp.fujitsu.com>]

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
"Adrian Farrel" <adrian@olddog.co.uk> san wrote:

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

---
Akira NAGATA <nagata.akira@jp.fujitsu.com>
Photonic Node Laboratory, Photonics Networking Laboratories,
Fujitsu Laboratories Ltd.
TEL: +81-44-754-2765  FAX: +81-44-754-2741