The MPLS WG Archive

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

In message <3ACBD64D.FF5CFBCA@sandburst.com>, Eric Gray writes:
> 
> > If you have A-B-D-E and A-C-D-E and A-W-X-Y-Z-E and B just went down,
> > a topology change at D-E (D-E went down) may make the path A-B-C a
> > poor choice.  C may have decided that the best path is by way of A
> > since D-E is unavailable and is dutifully trying to inform B of the
> > situation with a Label Withdraw, who will take note of it and inform A
> > in due time after its finished rebooting.
> 
> Since you didn't draw a picture, I'll try to unscramble this
> alphabet soup.
> 
> My guess is the picture is supposed to look like this:
> 
>         B
>        /|\
>       / | \
>  --- A  |  D --- E ---
>      |\ | /      |
>      | \|/       |
>      |  C        Z
>      |           |
>      W --- X --- Y
> 
> Is that the case?


My description was off.  Should be:

  If you have A-B-D-E and A-C-D-E and A-W-X-Y-Z-E and B just went
  down, a topology change at D-E (D-E went down) may make the path
  A-B-D a poor choice.  D may have decided that the best path is by
      ^                 ^
  way of A since D-E is unavailable and is dutifully trying to inform
  B of the situation with a Label Withdraw, who will take note of it
  and inform A in due time after its finished rebooting.

Note the two places where C is changed to D above.  This is the same
picture you have without the B-C link.

I answered my own question.

In RFC3036 "A.1.7. Detect Change in FEC Next Hop" the "Received Label
Mapping" event generated in NH.12 and Note 2 cover this case as long
as the next hop changed.

If we look at a similar example where C were not there and there was a
B-E link (or B-...-E path) that was higher cost than B-D-E, then A
would not see a next hop change.

If we want to prevent a persistent loop, the very minimum would be for
A to reject consideration of any FEC through B for which the next hop
from B has changed because B has not reflected the change.  There is
no such procedure in draft-ietf-mpls-ldp-ft-01.txt.

A simpler approach was taken in the OSPF WG.  Adjacencies to the
router that was down were declared down (the IGP Grace timer was
prematurely expired) when there was a change in the topology.

By virtue of the IGP Grace timer expiring LDP would see a next hop
change so this case too is covered as long as the IGP prematurely
expires its Grace timer.

This would mean that LDP does not also have to prematurely expires its
timer, though it would seem that there would be no difference in
behaviour since all traffic is already diverted away by virtue of all
IGP next hops being changed to go elsewhere.

It would only be if the IGP did not expire its Grace timer that there
would be a problem in LDP (and the IGP and therefore things like IBGP
would be even worse off, so the IGP would clearly need to do
something).

Whether the LDP timer is prematurely expired does not effect whether
LDP routes are diverted away from the downed router.  If the timer is
prematurely expired, it just changes the behavior during recovery,
only impacting how soon FEC are sent through that router again.

Either keeping the text as is or recommending prematurely expiring the
timer both seem to be fine options.  Since it is already last call and
there is no urgency I can see good reason not to make this change.
Thanks for the time taken for this discussion.

Curtis