The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2003-Oct> msg00174



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Fast Reroute MIB Notifications

  • From: "Thomas D. Nadeau" <tnadeau@cisco.com>
  • Date: Thu, 30 Oct 2003 10:17:09 -0500
  • Cc: "'mpls@uu.net'" <mpls@UU.NET>
  • Importance: Normal
  • Organization: Cisco Systems, inc.



>-----Original Message-----
>From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf 
>Of Adrian Farrel
>Sent: Thursday, October 30, 2003 5:47 AM
>To: Nurit Sprecher
>Cc: 'mpls@uu.net'
>Subject: Fast Reroute MIB Notifications
>
>
>Subject line changed and recipients trimmed.
>
>Hi Nurit,
>I think this would be better answered by one of the MPLS MIB authors.
>
>I have a memory that someone was working on FRR extensions to 
>the TE-MIB, but I can't find
>that draft now. Perhaps it was rolled into the MPLS TE MIB?

	Yes, it is called the MPLS-TE-FRR-MIB. It has expired
and I didn't get it in under the deadline. Rest assured,
it will be updated soon after the meeting.

>Your idea seems reasonable to me. That is, when there is a 
>significant change in the
>service provided by an LSP, the operator should receive a 
>Notification and not have to discover the fact by polling.

	The MPLS-TE-FRR-MIB does have a notification whereby
a PLR can indicate that FRR has been engaged.

	--tom



>I'm not sure that the ARHop table tells you what you want to 
>know, anyway. The RRO flags
>are not shown as part of ARHop table in
>http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-mib-13.t
xt. This makes this feature
a candidate for either an FRR extension MIB or the GMPLS MIB.

Cheers,
Adrian


> I have a question on notifications when FRR is activated.
> If an LSP has been established with the 'one-to-one local protection
> desired' and a detour has been established at each PLR --> all hops
along
> the LSP are considered FRR protected.
> Is for example, a problem occurs on one of these detours and the hop
becomes
> to be unprotected, the consequent Resv message will indicate that the
> relevant node is not protected any more and the ARHop table will be
updated
> with the information. However, a management station has no idea of the
> event, unless it keeps polling the ARHop table, which is not a
reasonable
> operation. I think that an appropriate notification/trap should be
sent to
> the management station indicating the protection status has been
changed to
> trigger the management station polling the ARHop table and verifying
which
> node is not protected any more, or which node that has not been
protected is
> now protected.
> Is it possible to add such a kind of trap to the TE MIB?
> Thanks in advance, Nurit.


>