Subject: [Lsvr] Comments on LSVR with RR peering

From: Eric Rosen <[email-masked]>
Date: Tue, 4 Dec 2018 14:17:08 +0000

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?

---

From: Randy Bush <[email-masked]>
Date: Tue, 04 Dec 2018 15:21:46 -0800

apologies, but i am easily confused.

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

are you doing some sort of multi-hop or underlay?  if not, then A told
RR that B told her that B-C was down.

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

did A not know B-C was down already?

randy

---

From: Eric Rosen <[email-masked]>
Date: Wed, 5 Dec 2018 14:42:22 +0000

This example is based on Section 2.3 of lsvr-bgp-spf-03 ("BGP Peering in 
Route-Reflector or Controller Topology"), which states:

    "In this model, BGP speakers peer solely with one or more Route 
Reflectors [RFC4456] or controllers."

Thus when BC goes down, B cannot tell A of this fact, it can only tell 
the Route Reflector, and A can only learn of this fact from the Route 
Reflector.

Perhaps I took the statement in Section 2.3 too literally? ;-)

---

From: Randy Bush <[email-masked]>
Date: Wed, 05 Dec 2018 12:58:51 -0800

i think i see the disconnect

>>> numbers are link metrics.

B, C, D, E, and F may not be clients of RR.  2.2 says you can use
loopbacks.  this does not imply that you can multi-hop peer a la ibgp.
hence, 2.3 does not allow multi-hop.

or i am still confused.

randy

---

From: Eric Rosen <[email-masked]>
Date: Wed, 5 Dec 2018 21:09:06 +0000

Perhaps the authors can clarify what they meant by "BGP speakers peer 
solely with one or more ... controllers".

---

From: Randy Bush <[email-masked]>
Date: Wed, 05 Dec 2018 14:23:50 -0800

>> hence, 2.3 does not allow multi-hop.

perhaps they thought "directly" in the section title of 2.2 would give
us a clue

     2.2. BGP Peering Between Directly Connected Network Nodes

followed by
  
    2.3.  BGP Peering in Route-Reflector or Controller Topology

       In this model, BGP speakers peer solely with one or more Route
       Reflectors [RFC4456] or controllers.  As in the previous model,
       direct connection discovery and liveliness detection for those
       connections are done outside the BGP protocol.   

so would you have them clarify 2.3 with something such as

    as with non-spf bgp route reflection, clients are directly connected
    to the reflector(s)

randy

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 6 Dec 2018 10:19:59 +0000

>      as with non-spf bgp route reflection, clients are directly connected

Presumably in needs to be "directly connected via an alternate physical 
network."

- Stewart

>
> _______________________________________________
> Lsvr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsvr

---

From: Randy Bush <[email-masked]>
Date: Thu, 06 Dec 2018 08:47:29 -0800

> Presumably in needs to be "directly connected via an alternate
> physical network."

alternate to what, exactly?

do not be fooled by the diagram above, which is not a route reflector
cluster.

randy