[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Looking for comments on draft for RSVP Graceful Restart extensions(draft-rahman-ccamp-rsvp-restart-extensions-00.txt)

Reshad Rahman wrote: 

I haven't seen anything wrt ERO change clearly specified in any of
the RFCs.

Unfortunately, it isn't mentioned. The consensus at the time of RFC 3209's development was that make-before-break should be used for any rerouting.

Unfortunately, this ignores corner cases like when the route table changes, causing a loose-hop's next-hop to change. How to process an ERO change seems (to me, anyway) to be related.

What I wrote (quoted below) is what I think makes the most sense. It would be great if this could be codified so that everybody handles this the same way. If some feel that my assumption is wrong, then this is something that should be discussed and codified afterwards.

RSVP, by nature is a soft-state protocol.  Implementations should
expect stuff to change all the time.  When an ERO changes, a node
shouldn't reject the message.  It should use the new ERO to
determine the new next-hop.

If the next hop doesn't change, then the node should leave the LSP
in place and immediately generate a Path refres, so that downstream
neighbors get the new ERO as soon as possible.

If the next hop changes, then it should be treated identically to
what would happen in response to a route change with a loose
ERO-hop or no ERO.

Note that I didn't describe what to do when a route-table change causes an LSP to reroute. There are different approaches to this, but none are ideal. All result in transient problems (LSP flapping, dropped packets, etc.) This is why make-before-break is strongly preferred to changing an ERO in-line.

-- David