RE: RSVP Graceful Restart

[Nurit Sprecher <nurit.sprecher@SeabridgeNetworks.com>]

Hi,
I fully agree that it is satisfactory that the Ingress LER send traps on
protection status changes. But such a trap should be defined.
Thanks, Nurit.


-----Original Message-----
From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org]
Sent: Thursday, October 30, 2003 3:40 PM
To: Nurit Sprecher
Cc: 'Adrian Farrel'; 'mpls@uu.net'; ccamp@ops.ietf.org
Subject: Re: RSVP Graceful Restart 


In message
<C87E5A01714C7840B92CDED9E79329CA0117D0A7@leopard.seabridge.co.il>,
Nurit Sprecher writes:
>
> Hi,
> 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.

The local_protect_available bit should be set by each node and if the
backup fails at a node the bit should be cleared.  The ingress then
knows the primary LSP is not fully protected and can then optionally
set a timer and reroute the primary LSP if for some reason the backup
LSP cannot be reestablished during that time.

Since the TE MIB reports status of the ingress, it might be better for
the ingress to send traps on protection status changes rather than
each midpoint sending status (ie: {is|not} fully-protected, {is|not}
protection-inuse).  If the management station need to know which node
transitioned to not protected or inuse then it can poll the midpoints.

Curtis