Subject: [mpls] Avoiding LDP graceful restart with planned node shutdown.

From: Andy Baker <[email-masked]>
Date: Thu, 7 Oct 2004 10:14:17 +0100

Hi,

In the case where a node is to be permanently disabled in a network in an
orderly manner (planned shutdown), but where normally it advertises to its
LDP peers that it supports graceful restart procedures, it is desirable that
peers do not use graceful restart procedures when they detect that the node
has gone.  This is to prevent the peers continuing to forward data to the
stopped node on the assumption that the node's forwarding state is still
intact.  Such forwarded data will be black-holed until the peer neighbour
reconnect timer expires.

To prevent graceful restart usage under these circumstances requires that
nodes can detect the difference between the planned and unplanned shutdown
of a peer.

While RFC3478 makes no specific comment on how to do so, a possible approach
would be that when a node detects the failure of a peer through receipt of a
Notification (shutdown), the receiving node assumes this is a planned
shutdown of the peer, and disables graceful restart.

In all other cases (TCP socket error, keepalive timeout etc.), the node
assumes unplanned shutdown, and starts its graceful restart neighbour
reconnect / liveness timer for the session.

I'd like to get clarification if this is in fact the intent in the standard?

Thanks,

Andy.

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: "Pradosh Mohapatra" <[email-masked]>
Date: Thu, 7 Oct 2004 19:44:50 -0700

Andy,

>While RFC3478 makes no specific comment on how to do so, a possible
>approach would be that when a node detects the failure of a peer 
>through receipt of a Notification (shutdown), the receiving node 
>assumes this is a planned shutdown of the peer, and disables graceful 
>restart.
>
I think the shutdown notification has a wider meaning; anytime the LSR
chooses to terminate a session, it sends the shutdown msg. e.g. during
Software upgrades, manual process restarts etc. That still means that the 
forwarding state is intact. A better idea is probably to delete the label 
mappings from the peer explicitly during planned shutdown.

Thanks/Pradosh

>[email-masked] https://www1.ietf.org/mailman/listinfo/mpls