BGP - draft-ietf-idr-bgp-optimal-route-reflection-19
Hello, Does someone has an effort to implement draft-ietf-idr-bgp-optimal-route-reflection-19 for BGP? I see there is a difficulty in 4.1 in IGP metric. As far as I know, most of vendors are currently using IGP approach . How can I get IGP an abstract metric for peer address? I see the need to implement BGP-LS first before. It will allow separation of protocols and more. Having BGP-LS stub code would help in implementation of other features. What is your mind about it? Thanks --- Philip
On Sat, Nov 02, 2019 at 05:41:34PM +0200, Philippe Duke wrote:
Hello,
Does someone has an effort to implement draft-ietf-idr-bgp-optimal-route-reflection-19 for BGP?
I see there is a difficulty in 4.1 in IGP metric. As far as I know, most of vendors are currently using IGP approach .
How can I get IGP an abstract metric for peer address?
I see the need to implement BGP-LS first before. It will allow separation of protocols and more.
Having BGP-LS stub code would help in implementation of other features.
Hello I thought about ORR several weeks ago. The draft is pretty fuzzy about how to get IGP metrics, but it seems it is understood it is done by BGP-LS. I see three possibilities: 1. BGP-LS, that is interesting idea, but plenty of work. Perhaps later. 2. Just make GRE tunnels from routers to RR and run multiple IGP (OSPF) instances on RR, each for every router / GRE tunnel. That would have a higher overhead than (1), but can be done with almost no modifications to current BIRD. 3. Just propagated computed IGP routes (including metrics) from router to RR using BGP, perhaps in separate BGP session to avoid mixing them with 'real' BGP routes. Unfortunately regular BGP does not offer native way to attach IGP metric to a route, but one can use AIGP attribute for that or just abuse some other existing attribute (e.g. LOCAL_PREF) with some filtering code. Both variants (2) and (3) can be easily implemented in BIRD with minimal changes, with configuration similar to multitable RS setup. The only thing that has to be added is filter ability to change table in which BGP next hop (and IGP metric) is recursively resolved. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hello, Ondrej. I think like this is the option for now. Would like to try gain some experience with protocol implementations in spare time if I have one. Tired of my current operational job routine. Just want to know how is the BGP parsing/serialization code is presented in BIRD. Do you have some documentation on library structures (net_addr_*) and BGP? I see a lot of code in one single bgp.c and bgp.h without separation by AF. What guidelines do you have? Thanks 02.11.19 21:40, Ondrej Zajicek пише:
1. BGP-LS, that is interesting idea, but plenty of work. Perhaps later.
-- Philippe Duke Henkuaile
On Tue, Nov 05, 2019 at 08:26:07PM +0200, Philippe Duke wrote:
Hello, Ondrej.
I think like this is the option for now. Would like to try gain some experience with protocol implementations in spare time if I have one.
Tired of my current operational job routine.
Just want to know how is the BGP parsing/serialization code is presented in BIRD.
Do you have some documentation on library structures (net_addr_*) and BGP?
Hello net_addr_* structures are not much documented, but they are mostly straightforward. Just look on some other nettype is handled and copy that. There are some documentation in BGP (comments and generated documentation [*]), but probably not good enough to get full understanding. [*] https://bird.network.cz/?get_doc&f=prog.html&v=20
I see a lot of code in one single bgp.c and bgp.h without separation by AF.
AF-specific code is stored in bgp/packets.c as most of BGP code is AF-independent. Look at bgp_af_table structure. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
participants (2)
-
Ondrej Zajicek -
Philippe Duke