Subject: RSVP Restart (draft-ietf-mpls-generalized-rsvp-te-04.txt)

From: Gopal Kailad <[email-masked]>
Date: Fri, 21 Sep 2001 09:34:24 -0400

I have some questions/concerns on the restart mechanism as
specified in draft-ietf-mpls-generalized-rsvp-te-04.txt.  I
have listed them below.

If a node that is terminating hierarchical LSPs restarts,
there is an ordering issue during resynchronization, since
the LSPs would depend on other FA-LSPs the interface IDs for
which would have been generated dynamically. So the
mechanism as described will not work, unless this
information is preserved across restarts - in which case we
might as well preserve other information as well, and avoid
resynchronization.

Also, let us consider a node that can preserve state across
restarts, and hence does not need its state to be synced by
its peer.  How will it advertise this in the RESTART_CAP
object?

If a node supports PSC as well as TDM or LSC interfaces, it
might want to advertise different set of parameters in the
RESTART_CAP object for data LSPs as opposed to SONET/WDM
LSPs which form bearer channels in transport networks.
Currently this is not possible.

According to 9.5.1. (procedures for restarting LSR): "When
sending the corresponding outgoing Path message the node
SHOULD include a SUGGESTED_LABEL object with a label value
^^^^^^
matching the outgoing label from the now restored forwarding
entry."

This has a conflict with 9.5.2.  Consider the case where
adjacent nodes B and C restart, and B has another adjacent
node A, and C has another adjacent node D.  B and C will get
resynced by A and D, and during this process, they will
resync. each other. While resyncing each other, they act as
neighbors of a restarting LSR, and hence according to 9.5.2,
MUST include the SUGGESTED_LABEL.

Also according to 9.5.2: "During the recovery period, new
Path state being advertised to the restarted neighbor SHOULD
not include the SUGGESTED_LABEL object in the corresponding
outgoing Path message.  This will prevent the restarting
node from erroneously reusing a saved forwarding entry."

I guess this would mean that if suggested labels are used
during new LSP setup (as they are likely to be while
provisioning lightpaths - to reduce latency), then new LSP
setup will not be allowed during resyncing?

In section 9.3: "When a new Hello message is received from
the neighbor, the LSR must determine if the fault was
limited to the control channel or was a nodal fault.  This
determination is based on the Src_Instance received from the
neighbor.  If the value is different than the value that was
received from the neighbor prior to the fault, then the
neighbor should be treated as if it has restarted.
Otherwise, the the fault was limited control channel."

If two adjacent nodes restart, how can each of them
determine that the other also just restarted?  This would
need that the src_instance received from the neighbor is
preserved across restarts - was that the intent?

Thanks,

Gopal