Subject: Re: Graceful restart - inter-protocol dependencies

From: David Charlap <[email-masked]>
Date: Thu, 29 Sep 2005 10:34:39 -0400

But RSVP doesn't work this way.  It is a soft-state protocol.

If the route table changes such that the next-hop interface changes, 
RSVP is supposed to reroute the connection accordingly.

This probably won't happen if the next-hop is a strict-hop in an ERO, 
but it can easily happen if the next-hop is loose or if the LSP is 
signaled without an ERO (meaning routing is consulted to determine the 
next-hop to the egress node.)

If there is a paragraph in an RFC that says RSVP-TE should ignore all 
route-table changes once an LSP comes up, I missed it.

-- David

Jing Ruiquan wrote:
> I think only the  originating node should do the rerouting with RSVP-TE .At
> the same time, all the nodes will converge their IGP routing data base.
> 
> Rick
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of David Charlap
> Sent: Thursday, September 29, 2005 2:37 AM
> To: IETF MPLS List; IETF CCAMP List
> Subject: Graceful restart - inter-protocol dependencies
> 
> Is there any point to implementing RSVP-TE's graceful restart without also
> implementing graceful restart for routing protocols?
> 
> On the one hand, RSVP doesn't require routing to recover LSPs.  It knows the
> next-hop interface, because of the preserved data-plane connection. 
>   Whatever other information it may need, the switch can either preserve
> this information or recover it from a neighbor using the RecoveryPath object
> (draft-ietf-ccamp-rsvo-restart-ext-03).
> 
> On the other hand, nodes more than one hop upstream of the failure will
> detect the loss of routing-connectivity to the failed node if IGP graceful
> restart is not also implemented.  They may reroute the LSP away from the
> failed node, or tear it down altogether, even though the data plane is still
> active and RSVP graceful restart is recovering the control-plane state.
> 
> An originating node may consider the destination unreachable, as a result of
> losing the routes even though the data-plane for the LSP is still up (which
> can be confirmed via OAM.)
> 
> A transit node, when processing an loose ERO-hop, may choose to reroute or
> fail the LSP if its local topology information says that the failed (and
> restarting) node is not available.  It might even choose to do this for an
> established LSP, as a result of Path refresh processing.
> 
> My questions are:
> 
> 1: Does this mean it's pointless to use RSVP graceful restart without
>     also using IGP graceful restart (for whatever IGP is active).
> 
> 2: Is IGP graceful restart sufficient to prevent this problem?  For
>     instance, OSPF's restart procedure requires all preserved state to
>     be thrown away if a topology change is detected.
> 
> 3: An originating node can use OAM to validate the data plane of an
>     LSP, and choose to ignore what routing tells it about the
>     destination's reachability.  But what about transit nodes?  As far
>     as I know, MPLS doesn't support segment-OAM, and it would be
>     prohibitive for every transit node to run its own OAM streams
>     to detect self-to-end connectivity.
> 
> 4: Are there other solutions to this problem?
> 
> One possible solution might be route-pinning, but RSVP doesn't have a
> built-in mechanism for this.  The usual workaround (signal the LSP,
> requesting route-recording, then turn the RRO into an ERO for subsequent
> refreshes) can work, but are there situations where even this would be
> insufficient to prevent a transit node from rerouting/tearing the connection
> in this particular situation (where RSVP is doing a graceful restart but the
> IGP is not)?
> 
> -- David

---

From: Ashok Narayanan <[email-masked]>
Date: Thu, 29 Sep 2005 10:50:35 -0400

Strict EROs are used in the vast majority of MPLS/TE deployments. Even
Loose ERO hops tend to get expanded into strict EROs (e.g at ASBRs);
and extensions such as PCE are all designed to move path calculation
to a single point rather than doing it hop-by-hop. The problem with
hop-by-hop routing is that you can only have LSPs track the best IP
route, rather than the best "engineered" route through the network.

However, the problem you've described is an interesting one for
regular IPv4 RSVP (for QoS), though not necessarily for MPLS/TE.

-Ashok

-- 

--- Asok the Intern ----------------------------------------
Ashok Narayanan
IOS Network Protocols, Cisco Systems
1414 Mass Ave, Boxborough MA 01719
Ph: 978-936-1608.  Fax: 978-936-2218 (Attn: Ashok Narayanan)

---

From: David Charlap <[email-masked]>
Date: Thu, 29 Sep 2005 14:00:49 -0400

When processing a loose hop, or even a strict hop with an address that 
is not an interface-neighbor address, RSVP relies on the route table to 
determine the next-hop interface (and possibly also the next-hop address.)

How is it right to ignore route changes after this?  If the route table 
changes such that the selected next-hop interface is no longer the best 
(or is no longer valid), should RSVP ignore this?  It seems to me like 
this could end up blackholing traffic in a way that will not be 
detectable without OAM.

The last I heard, network operators were not required to run OAM on 
every LSP.  Has this changed?

-- David

Alia Atlas wrote:
> David,
> 
> In ref to RSVP-TE, a part of the question is who notices the routing 
> change and does
> the reroute.  In general, the idea of make-before-break and control by 
> the ingress apply.
> 
> For a midpoint, a change to an LSP would be triggered by either the RSVP 
> PATH
> message changing or by the selected next-hop interface no longer being 
> available. 
> Theoretically, a midpoint LSR could register for route changes to the 
> specified next-hop,
> but to what purpose?? Once the midpoint LSR has determined the next-hop 
> interface, I'd
> expect that to be treated as a strict hop, inside the LSR at least.
> 
> Alia
> 
> 
> On 9/29/05, *David Charlap* <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>      > From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>]
>     On Behalf
>      > Of David Charlap