Re: [Lsvr] Comments on LSVR with RR peering

Route reflectors work in traditional BGP, because there is an IGP
that connects the BGP speakers.

I think Eric is pointing out that if you are using the routes
on the controller to connect to the controller, you are on very
fragile ground.

Regards,
Jakob.

-----Original Message-----
From: Lsvr <lsvr-bounces@ietf.org> On Behalf Of Acee Lindem (acee)
Sent: Wednesday, December 5, 2018 5:03 PM
To: Eric Rosen <erosen@juniper.net>; lsvr@ietf.org
Subject: Re: [Lsvr] Comments on LSVR with RR peering

Hi Eric, 

I don't think such a topology would work very well even with traditional BGP. We'll document some reasonable scoping rules on sparse peering in the  LSVR Applicability document. 

Thanks,
Acee 

On 12/4/18, 9:17 AM, "Lsvr on behalf of Eric Rosen" <lsvr-bounces@ietf.org on behalf of erosen@juniper.net> wrote:

    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?

    _______________________________________________
    Lsvr mailing list
    Lsvr@ietf.org
    https://www.ietf.org/mailman/listinfo/lsvr

_______________________________________________
Lsvr mailing list
Lsvr@ietf.org
https://www.ietf.org/mailman/listinfo/lsvr