Subject: Re: [Lsvr] Comments on LSVR with RR peering

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 6 Dec 2018 01:02:32 +0000

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" <[email-masked] on behalf of [email-masked]> 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
    [email-masked]
    https://www.ietf.org/mailman/listinfo/lsvr

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 6 Dec 2018 01:56:49 +0000

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 <[email-masked]> On Behalf Of Acee Lindem (acee)
Sent: Wednesday, December 5, 2018 5:03 PM
To: Eric Rosen <[email-masked]>; [email-masked]
Subject: Re: [Lsvr] Comments on LSVR with RR peering

Hi Eric, 

Thanks,
Acee 

    

    

    

    

    

    

    Did I miss something?

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 6 Dec 2018 02:30:48 +0000

On 12/5/18, 8:56 PM, "Jakob Heitz (jheitz)" <[email-masked]> wrote:

I agree - you wouldn't want to do this. 

Thanks,
Acee
    
    Regards,
    Jakob.
    
    -----Original Message-----
    From: Lsvr <[email-masked]> On Behalf Of Acee Lindem (acee)
    Sent: Wednesday, December 5, 2018 5:03 PM
    To: Eric Rosen <[email-masked]>; [email-masked]
    Subject: Re: [Lsvr] Comments on LSVR with RR peering
    
    Hi Eric, 

    Thanks,
    Acee 

        

        

        

        

        

        

        Did I miss something?