Re: [Lsvr] Comments on LSVR with RR peering

["Acee Lindem (acee)" <[e-mail]>]

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

    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.

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

Thanks,
Acee
    
    Regards,
    Jakob.
    
    -----Original Message-----
    From: Lsvr <[e-mail]> On Behalf Of Acee Lindem (acee)
    Sent: Wednesday, December 5, 2018 5:03 PM
    To: Eric Rosen <[e-mail]>; [e-mail]
    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" <[e-mail] on behalf of [e-mail]> 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
        [e-mail]
        https://www.ietf.org/mailman/listinfo/lsvr
        
    
    _______________________________________________
    Lsvr mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/lsvr