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

From: "Don Fedyk" <[email-masked]>
Date: Wed, 23 Jul 2003 09:37:05 -0400

Adrian

Two points in support of your arguments:

Crankback and our related draft feedback have proven with running code in
many systems to improve the response to failures. 

Historically both systems started by relying on the solely on IGP and then
improving the situation where the IGP cannot/should not keep up with the
rapid changes in bandwidth (not connectivity) that happen with a
redistribution of paths. 

Cheers,
Don

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]] 
> Sent: Tuesday, July 22, 2003 7:44 AM
> To: [email-masked]
> Cc: [email-masked]'; [email-masked]
> Subject: Crankback [Was: Running out of RSVP-TE bits?]
> 
> 
> Curtis,
> 
> I think you have possibly missed the chief use of crankback 
> and focused on a side use.
> 
> The principal use is to handle LSP setup failures. When these 
> happen they tend to happen one at a time (that is not a whole 
> bunch of impacted LSPs that were using a link that has 
> failed). Crankback allows nodes on the LSP to attempt to 
> re-direct the LSP setup attempt without failing it back to 
> the ingress, and allows the collection of more detailed 
> failure information to aid the re-direction process.
> 
> In a nutshell, crankback targets rapid re-direction of LSP 
> setup attempts without waiting for IGP convergence. That 
> crankback can also be used for handling failed LSPs is an 
> 'interesting' additional feature.
> 
> Note that in no case does crankback increase the error 
> reporting message flow. It simply adds a little information 
> to error messages already used in RSVP-TE or GMPLS. In fact, 
> if crankback is in use and intermediate nodes are enabled as 
> crankback repair points, crankback can reduce the error 
> reporting message flows since they don't have to go all the 
> way to the ingress nodes.
> 
> > > Perhaps you could summarize some of the problems crankback will 
> > > cause. It would be good to get comments on these problems 
> from the 
> > > ITU-T members who have made this an ASON requirement.
> >
> > After a link fails zero to a large number of admission failures may 
> > occur on a few links that are considered desireable alternates (by 
> > multiple LSP ingress, each acting independently).  Crankback will 
> > provide individual signals to each ingress, probably for 
> each LSP that 
> > failed.
> 
> Well now: the number of signals is not a function of 
> crankback. It is an existing function of RSVP-TE error 
> reporting. Crankback simply adds information to the error 
> reporting so that the error may be repaired. It also 
> recognizes that non-ingress nodes may wish to repair errors.
> 
> > Just using the IGP flooding is far more efficient and proactively 
> > tells ingress that haven't sent LSP paths over the now overloaded 
> > link.
> 
> Efficiency is in the eye of the beholder on this issue. The 
> debate over flooding or signaling errors will probably go on 
> for a while (see Richard Rabbat's work in ccamp on the need 
> for a flooding mechanism for fail-over to a protection LSP 
> that may be carrying extra traffic). The efficiency surely 
> depends on the number of LSPs and the number of nodes/links 
> in the network.
> 
> To repeat: the crankback draft doesn't make any assumptions 
> about the efficiency, it simply uses existing mechanisms. In 
> fact, there is a significant issue with the use of a flooding 
> mechanism. Viz. the ingress may not be able to tell from a 
> description of the faulted resource which LSPs were impacted 
> - suppose a component link fails, or even an individual 
> laser. (You might as well say that soft pre-emption should be 
> reported through
> flooding!)
> 
> > Of course if you write specs before trying things you often 
> get things 
> > wrong, particularly where the dynamics of a protocol are concerned. 
> > That's where the running code thing comes in.
> 
> I agree with you whole-heartedly. It is so important to have 
> running code. Not sure why you bring it up in this context. 
> Are you trying to imply something?
> 
> > I think testing in an
> > environment where lots of LSP from many ingress traverse a 
> link that 
> > fails and all route to one or two links that become 
> overloaded should 
> > be a prerequisite for crankback, with improvement demonstrated.
> 
> As in my preamble, this is not what crankback is about.
> 
> >
> > Curtis
> >
> > ps - who cares about ASON?  or ITU for that matter?  :-)
> 
> Cheers,
> Adrian
> 
> 
>

---

From: "Don Fedyk" <[email-masked]>
Date: Wed, 23 Jul 2003 22:01:40 -0400

Curtis

Comments inline:

> 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.  

Cheers,
Don