[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Question on Administratively down bit
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
"Zafar Ali (zali)" <zali@cisco.com> san wrote:
> 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: owner-ccamp@ops.ietf.org
> > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Akira NAGATA
> > Sent: Friday, October 21, 2005 1:52 AM
> > To: Adrian Farrel
> > Cc: Akira_NAGATA; ccamp@ops.ietf.org
> > 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" <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
> >
> >
---
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