Router-Router NHRP

["j.garrett" <[e-mail]>]

Joel,

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

Yes.  My assertion with the November 1993 example was that A would not
see the change.  In the discussion after the presentation of the
example others may have suggested that examples may exist for which
neither A nor C would see the change.  I think your observation is
correct (ignoring crazy examples involving static configuration).

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

How will this scale?
How long does this relationship between A and C last?

B could tell A that C is the best next hop to K using off the shelf
routing protocol if A had a way to learn C's ATM address, and B knew
that A could learn C's ATM address (see RFC 1433).
We've not gotten anywhere on the NHRP loop issue in more than a year.
Perhaps it would be useful to look at RFC 1433, identify the
problems with that approach, and see if they may be easier to fix.

John Garrett
AT&T Bell Labs
908 580-4719
[e-mail]