RE: Crankback [Was: Running out of RSVP-TE bits?]

["Don Fedyk" <dwfedyk@nortelnetworks.com>]

Curtis

Comments inline:

> -----Original Message-----
> From: Curtis Villamizar

<snip> 
> Rarely is the minimal case of much interest compared to cases
> where a feature is exercised heavily.  This is no exception.
> 
> Links occasionally fail, sometimes even routers fail.  ISPs
> have reported (publicly I think, but at least privately) to 
> have more than 1,000 RSVP/TE LSPs through a single node with 
> close to 1,000 on a single link.  The ingress for those 
> failures would be many 10s of routers in either direction.  
> Topologies are meshed but not densely meshed.  This means 
> that these many 10s of ingress are all going to go for the 
> same resource which is now the best after the failure.  
> Setups occur very fast.  Often a large percentage of the LSPs 
> will fail admission.
> 
> This is an interesting case.  It is not mearly hypothetical,
> it is a common real world case.

I agree here. The value of crankback or feedback at the moment these LSPs
fail admission and signal back to the source is the key point.  There is a
race condition for the LSA (or other mechanisms when you get to multiarea).
The value of crankback avoids wasted control cycles either waiting for the
LSAs or (worse) retrying the same failed path. It is not a replacement for
the LSA nor is its scope as wide.  It piggybacks on existing signaling. 
 

<snip>
> 
> I am looking at MPLS as a means to setup very long lived
> connections for the purpose of traffic engineering an ISP 
> network.  These connections are intended to never go down if 
> that were possible.  When the network is quiescent there are 
> few if any setups.  Any setups during quiescent periods would 
> be due to residual optimizations as a result of prior change 
> to the network or change to reservable bandwidth of tunnels 
> that routinely occur (often weekly) as a result of evaluation 
> of prior traffic patterns.  These occasional setups during 
> quiescent periods are spaced far enough appart that it is 
> very rare not to have exact information.  It is only when a 
> major event, such as a link down, occurs that resource 
> contention occurs and then quite massive resource contention 
> occurs over a brief period.  In this case flooding the fact 
> that the resource is exhausted makes good sense.  Again, 
> flooding every change immediately is not at all practical, 
> but amount of change and time based triggers, combined with 
> immediate trigger on resource allocation failure makes sense.

The value of crankback here depends on the impact of the loss of the LSP. If
the LSP going down only means you don't have TE path and shortest path
routing kicks in, in the meantime, crankback only provides a minimal
improvement. 

> 
> I personally believe that MPLS using RSVP/TE was not intended
> for call routing of short lived connections and I have very 
> strong basis in past IETF meetings and mailing list 
> correspondence to support that.

Even long term connections that have no alternative routing when the
connection is down benefit from crankback or feedback. This is the case with
GMPLS. 

> 
> I also think that useless or not, we may end up implementing
> crankback simply because people either think we're solving 
> call routing of short connections, or people mistakenly think 
> crankback to be a good solution for the ISP situation.  
> Hopefully no implementor will think that crankback is a 
> viable substitute for reflooding when a resource allocation fails.

This is not a short lived LSP problem in my view. This is about making the
best call routing decisions without wasting or burning control plane cycles
during the interesting case you mentioned. You should reflood at an
appropriate rate but pushing flooding to a maximum rate _still_ leaves race
conditions between Signaling and LSAs. Crankback or feedback a good way to
address the race conditions for a low cost and allowing flooding at an
optimal interval.  

> Curtis
> 
> 

Cheers,
Don