Router-Router NHRP

[Joel Halpern <[e-mail]>]

In thinking about the Router-Router problem for NHRP, I have tried to
re-create the looping scenario.  Following th erecreation, I believe that I
can show a restriction on the complexity of the problem.  Given that
restriction, I would like to suggest a line of thinking for resolving it.

          E----------------------------------------------F
          |                                              |
          |  |=================================          |
          |  |                                |          |
        H-+-A-  ATM Fabric (with routers)     |          |
             |                                |          |
             |=====B==========================C          |
                   |                          |          |
                   |                          |          |
                   D                          G----------J
                   |                          |
                   ----------------------------
                                  |
                                  K

The scenario ass hypothesised was that traffic from H was destined for K.  A,
using NHRP, select C as his exit point.  The link from G to the subnet with K
on it then goes down.  Given that B is advertising into the ATM reachability,
A probably gets reachability information from the routing overlay.  It
therefore advertises reachability to E, and hence to F,  J, and G.  So C will
still see a path.  A forwarding loop results.

At the time of the original presentation, it was suggested that by suitable
tuning of the routing protocols, aggregation boundaries, and metrics, the case
could be adjusted so that neither C nor A would see a metric or attribute
change when the G/K communication path went down.

I assert that there must be such a change.
1) The dropping of the G/K path does not change the B/K attributes and
    metrics.
2) A found C because, under the previous routing topology C was the exit that
    routing would have selected
Therefore:
3) If neither A nor C saw a metric change, then the routing inside ATM did not
see a routing change.  Therefore, A would still see C as his best exit.  This
would imply a drastic failure of routing, having nothing to do with ATM.
Nothing we can do will fix such a failure, so we may assume that it will not
occur.  (The routing protocols are designed to prevent it.)

Hence, we may now assume that if A is forwarding traffic for K (or a prefix
including K) to C, and a loop could occur, then A or C will see a topologic
change which affects the prefix.

We then need to determine what behaviors will fix the loop.

1) When A detects a toplogical change affecting K, it must re-check its exit
selection for K.

2) When C detects a topological change affecting K, it must notify A so he can
re-check his exit selection.

(1) is easy to do, and requires no protocol mechanism.
(2) can be done in several ways.  I would like to suggest a mechanism for use
when other information is not being exchanged to cover the case:

A should notify C (in a reliable fashion?) of what addresses/prefixes she is
sending over the cut-through VC to C.
C should notify A (in a reliable fashion?) whenever a topology change (or
attribute change) occurs affecting the route to any destination being cut
through from A to C.
A similar exchange occurs in the reverse direction.

This is much simpler to maintain than a "mini-BGP" adjacency.
I believe that this is sufficient.

Now poke holes folks,
Thank you,
Joel M. Halpern			[e-mail]
Newbridge Networks Inc.

PS Yes this will eventually need to be an ID, but I want to see if the
    approach matches what people want/think will work.