draft-aruns-ccamp-rsvp-restart-ext-00

[Nic Neate <Nic.Neate@dataconnection.com>]

Hi,

I've just read your draft-aruns-ccamp-rsvp-restart-ext-00 and it looks good.
In particular, we've been looking at using Restart for Fast Reroute LSPs for
some time and this draft provides everything that is needed (like recovering
the FAST_REROUTE, DETOUR, SENDER_TEMPLATE and ERO objects from the
downstream node when they are not available from upstream).

However, I have a couple of concerns (not related to Fast Reroute).

 - Your draft doesn't tackle, and won't work for, simultaneous restart of
adjacent nodes.  This is a problem that is tackled by
draft-rahman-ccamp-rsvp-restart-extensions, so merging the two drafts in
some way may be the best way to resolve that.  I realize that the Aruns
draft aims to make Restart possible for nodes which cannot retrieve state
from the data plane, and in that case recovering from simultaneous restart
of adjacent nodes isn't easy.  I think including some further extensions for
nodes which can retrieve some state from the data plane would be
appropriate.

 - The back compatibility with RFC 3473 restart looks risky.  Draft Aruns
mandates that restarted nodes don't send Path Refreshes until either the
recovery period expires or a RecoveryPath is received from downstream.  In
the case that the downstream node only supports RFC 3473 restart (and so
doesn't send RecoveryPaths), it may well timeout Path state at the same time
as or very soon after the recovery period expires.  Hence a dangerous timing
window is created.

As a potential solution to both problems I'd suggest that a restarting node
receiving a Path message with a recovery label should always forward it
immediately as well as it can, and include both a recovery label and (for
back compatibility) a suggested label.  Similarly, it should forward
RecoveryPath messages immediately as well as it can.  I'd be happy to
discuss any of this further.

Thanks,

Nic