[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Question on Administratively down bit
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
>
>