Why Do We Need BGP-LS?
One of my readers sent me this interesting question:
I understand that an SDN controller needs network topology information to build traffic engineering paths with PCE/PCEP… but why would we use BGP-LS to extract the network topology information? Why can’t we run OSPF with controller by simulating a software based OSPF instance in every area to get topology view?
There are several reasons to use BGP-LS:
- It uses BGP and thus TCP transport. It’s trivial to setup a BGP session between an SDN controller and any router in your network (ideally at least two routers per area). Establishing OSPF adjacencies with routers across your network would require building GRE tunnels.
- BGP-LS is a one-way information exchange. The controller can get the topology information, but cannot influence the routing. An OSPF area is a single failure domain – any router participating in an OSPF area can inject any information into the OSPF topology database.
- Corollary: when using BGP-LS, bugs in the SDN controller cannot cannot bring down the network. When an SDN controller running OSPF with your network goes bonkers all bets are off1.
Moving from BGP-LS to PCEP:
Why can’t we use something like fibbing to control traffic paths?
Fibbing always felt like a proof-of-concept to me. It does allow you to steer traffic in an OSPF network assuming all destinations you’re interested in are external routes, but does not introduce virtual circuits like MPLS-TE does2, so it cannot implement scenarios that cannot be implemented with hop-by-hop destination-only packet forwarding (the fish diagram comes to mind).
Desired traffic flow: X-A-B-E-Z and Y-A-C-D-E-Z cannot be implemented with fibbing
For more details:
- Listen to the Fibbing: OSPF-Based Traffic Engineering episode of Software Gone Wild Podcast;
- Watch the PCEP and BGP-LS Deep Dive webinar.
- For a bigger picture, watch the Switching, Routing and Bridging part of How Networks Really Work webinar.
-
That’s also the reason I’m highly recommending running BGP between your data center fabric and virtual appliances. It looked like the VMware NSBU grasped the concept when they made BGP the only routing protocol supported in NSX-T, but of course the sane days didn’t last long… NSX-T 3.1.1 added OSPF support to NSX Edge. ↩︎
-
Virtual circuits are the important bit – it doesn’t matter whether they’re established with RSVP, PCEP, or segment routing label stack pushed into head-end device. ↩︎
Hello Ivan - thanks for giving visibility to this topic.
BGP-LS is great but must be used in the correct context. BGP-LS creates an abstracted view of the IGP but doesn't provide you with the nitty gritty of the IGP, plus it's not as real time as the IGP can be. So, BGP-LS is great for converting topology information but in use-cases where not all of the details need to emerge; So, for example an SDN application that doesn’t have real-time needs. BGP-LS can be good enough too in scenarios where there is no other way of conveying the IGP topology - for example an inter-AS scenario.
So, in my opinion, in a true Route Analytics scenario, IGP is indeed still needed. BGP-LS might be good enough for non-real-time SDN applications.
Regarding the security aspects that you rightly pointing out, well, as always, there are things you can do to mitigate the risk. Having on the management box a per-ospf-process OSPFoGRE Adjacency is one of them and some other kludges such as that of poisoning interface costs on the anchor routers to avoid the management box to be traversed in case of multiple network failures is another one, not to mention that you can manage who can configure what on the management box and so forth.
Cheers/Ciao
Andrea