The Routing Over Large Clouds Mailing List Archive by date[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Router-Router NHRP
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 jwg@garage.att.com |
|