The MPLS WG Archive

[Curtis Villamizar <curtis@laptoy770.fictitious.org>]

In message <004401c34c79$40fad500$78c2a051@Puppy>, "Adrian Farrel" writes:
> 
> Perhpas 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.  Just using the IGP flooding is far more efficient and
proactively tells ingress that haven't sent LSP paths over the now
overloaded link.

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

Curtis

ps - who cares about ASON?  or ITU for that matter?  :-)