[Lsvr] Comments on LSVR with RR peering

[Eric Rosen <[e-mail]>]

One of the more intriguing aspects of LSVR is the apparent ability to 
pass the link state updates through a route reflector, thereby 
minimizing the flooding load (both send and receive) on the routers.

However, this won't work unless there is a method to ensure that each 
router's BGP session to the RR will not become inoperable due to routing 
changes.

So let's look at the following topology (the ascii art requires a fixed 
with font, of course):


RR--1--A--1--B--1--C--1--D--1--E
              |                 |
              |-----5-----F--1--|

The letters represent routers (RR being the Route Reflector), and the 
numbers are link metrics.

Suppose BC goes down, and consider the following sequence of events:

1. B tells RR (via path B-A-RR) that BC is down.

2. RR tells A (via path RR-A) that BC is down.

3. RR tells F (via path RR-A-B-F) that BC is down.

4. RR tells E (via path RR-A-B-F-E) that BC is down.

Note that at this point, neither C nor D can send traffic to RR:

- Since D doesn't yet know about BC's failure, D will think its path to 
RR is DCBA.

- C does know about the BC failure (since the failure is local), so it 
thinks its path to RR is CDEFBA.

As a result, traffic from C or D to RR will loop between C and D.

Since TCP requires two-way connectivity, this means that RR cannot 
reliably talk BGP to C or D until the loop is broken.

To break the loop, RR has to tell D that BC is down.

But RR can't tell D that BC is down until the loop is broken.

This seems like a deadlock that could result in a long-lasting loop.

Did I miss something?