Re: Graceful restart - inter-protocol dependencies

[ibryskin@movaz.com]

David,

I think your view on the RSVP-TE is a bit obsolete. The signaling
subsystem should only react on the *data plane* events (e.g. detected data
plane failures) rather than on the events that happen in routing. Routing
events may at maximum cause the LSP ingress (or more precisely path
computation entity that performed path computation for the LSP) to
re-evaluate the path. Note also that TE paths are computed based on IGP-TE
advertisings rather than on IGP advertisings and a failure of a an IP link
does not necessarily change the latter. This is more obvious in non-packet
switched networks, but is very true in IP networks as well

The bottom line:

a) An intermediate LSR should never attempt to re-route TE LSP based on
IGP events

b) Detected data plane failures should be signaled (via data or control
plane) to the LSP ingress LSR or other LSR(s) responsible for recovery,
and recovery action may (restoration) or may not (protection) result in
the LSP rerouting. The latter may happen even if there were no changes
detected by IGP (in fact, operation is completely orthogonal to what
happens in IP routing)

c) It is perfectly reasonable to implement the RSVP-TE graceful restart
without implementing OSPF graceful restart. Again, the two are not
related.

Igor



> Then we are talking about different protocols.  I'm specifically
> referring to RSVP-TE, as defined by RFC 3209.
>
> I am aware that RSVP-TE's signaling mechanism (even just a PathErr
> message) will probably reach the ingress node long before routing can
> reconverge.  But that's not the question.
>
> The question is, if the node failure is due to a restart, and it has
> implemented RSVP-TE restart (yes, I'm aware that this is a GMPLS
> extnsion), but has not implemented graceful restart for any routing
> protocols, then the originating node won't receive any RSVP-level
> information about the restarting node.  But the IGP will.
>
> We want to prevent the reroute that would normally happen as a result of
> the route change.  Originating nodes can test the LSP using OAM, if
> there is no other choice, but transit nodes don't have that option.
>
> Ultimately, this comes down to my original questions:
>
> 	Does it make any sense to use RSVP graceful restart in a
> 	network where graceful restart is not being used for any
> 	routing protocols?
>
> 	If the answer to the previous question is yes, what can be
> 	done (if anything) to prevent originating and transit nodes
> 	from rerouting LSPs as a result of the route-table change?
>
> -- David
>
> Jing Ruiquan wrote:
>> Hi David,
>>
>> We should specify which version of RSVP we are talking. What I have said
>> is
>> about GMPLS RSVP-TE as used in ASON.
>>
>> When there is a failed link within the network, the ingress node will
>> know
>> the failure by transport plan OAM mechanism such as SDH path layer AIS,
>> or
>> by RSVP-TE Notify message. And usually these mechanisms are faster than
>> routing protocol convergence speed. After the ingress node knows which
>> link
>> or route has failed, it will do the rerouting while excluding the failed
>> link or route.
>>
>> Hope I say it clearly :-)
>>
>> Rick
>>
>> -----Original Message-----
>> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
>> Behalf
>> Of David Charlap
>> Sent: Thursday, September 29, 2005 10:35 PM
>> To: 'IETF MPLS List'; 'IETF CCAMP List'
>> Subject: Re: Graceful restart - inter-protocol dependencies
>>
>> 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] 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
>>
>>
>
>
>