Subject: RE: Question on Administratively down bit

From: "Zafar Ali \(zali\)" <[email-masked]>
Date: Fri, 21 Oct 2005 07:10:40 -0400

Hi Akira, 

The sequence you mentioned is correct. Also this is my understanding
that when an LSP is in "Admin.A = 1", an optical node may be performing
some power monitoring and adjustment related to the commissioning
process (again, this is a local action by an optical node). From a
router's prospective, I do see a need for router NOT to send any data
traffic on the LSP that is in "Admin.A=1", in addition of suppressing
alarm on the interface in question. I.e., an LSP can ONLY carrying data
traffic when it is back to "Admin.A=0".  

Comments/ additions? 

Thanks

Regards... Zafar 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Akira NAGATA
> Sent: Friday, October 21, 2005 1:52 AM
> To: Adrian Farrel
> Cc: Akira_NAGATA; [email-masked]
> Subject: Re: Question on Administratively down bit
> 
> 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" <[email-masked]> 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" <[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]>
> > >
> > >
> > >
> > >
> > 
> 
> ---
> Akira NAGATA <[email-masked]> Photonic Node 
> Laboratory, Photonics Networking Laboratories, Fujitsu 
> Laboratories Ltd.
> TEL: +81-44-754-2765  FAX: +81-44-754-2741
> 
>

---

From: Akira NAGATA <[email-masked]>
Date: Mon, 31 Oct 2005 16:56:18 +0900

Hi Zafar,

Thank you for your comments.
I'll consider more about this point, based on your comments.

Please let me discuss again at a later date.

best regards,
Akira

On Fri, 21 Oct 2005 07:10:40 -0400

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