Thanks for fixing the realmid passing around. My original point about breaking up the patches into separate changes still stands.
I see some whitespace changes in all the patches that don't need to be there. If you must reread the rt_realms file at the drop of a hat, I would prefer the usage of the inotify_XXX system calls, to be called back when it changes instead of rereading a file once a minute. donald On Wed, Jul 1, 2015 at 10:58 AM, Kaloyan Kovachev <[email protected]> wrote: > Hello, > I have updated the patch to include support for IPv6 too and have removed > the floating number of parameters of some functions. > https://github.com/KaloNK/quagga/compare/master...realms > > About caching the rt_realms file: It should be enough if inside > rtnl_rtrealm_initialize we do it once every minute instead of each call? > > > On 2015-06-28 15:17, Kaloyan Kovachev wrote: > >> Hi! >> Sorry for the late replay, I broke my leg, so won't be able to check >> my emails often for while, but will try. >> >> On 2015-06-21 19:23, Paul Jakma wrote: >> Hi Kaloyan, >> >> On Mon, 15 Jun 2015, Kaloyan Kovachev wrote: >> >> Hello devs, >> >> I am using the realms patch from Adrian Ban [1] for several years, but it >> is still missing from Quagga, while it is very useful (not only for me I >> hope). I have ported the patch for the latest version on GitHup and while >> working on it found another small bug, which I have fixed [3] Is there >> something else that needs to be done so they can be included in the >> official source? >> >> It's an interesting patch. I went through it and wrote a longer commit >> message for it. >> >> I think it needs work before we could commit it. >> >> It may be a while until I will be able to do it, but will do my best. >> >> >> 1. On the bgpd side, it's basically an ID that can be set per-peer and >> that can be set in a route-map action, but isn't significant for >> route-selection. >> >> Setting it for a peer - can't you just use the peer ID? Is that >> required? >> >> Further, it looks like the peer->realm only gets used for RSclients? >> Never gets used to set a route realm otherwise? Is that the intention? >> >> The bgp_{export,input}_modifier hunks don't seem right. It's applying >> the realm from the peer->realm regardless of the existing value, and >> it's modifying the global attr. Shouldn't it be modifying the >> rsclient specific attr? >> >> I'm guessing you don't use the "neighbour ... realm ..." form, and only >> use it with route-maps? >> >> >> I do use both (per peer and as route map) and yes it isn't significant >> for route-selection, but route classification and shaping later, >> please see the example below >> >> 2. On the zebra side it seems to only be honoured for IPv4 routes. So it'd >> need to be extended to v6 too, no? >> >> >> Yes, IPv6 and other protocols (not only BGP) can benefit from realms >> support too. >> >> The above need answering/fixing before we can go further I think. Upon >> which, we'd need to think about: >> >> 3. How do we integrate this generally? Is there a general use-case for a >> route-map setable ID in bgpd? >> >> >> Example of use: >> There are several 'edge' routers accepting routes and forwarding them >> to Slave/IGP peers after they are marked with a per-peer realm. >> On each 'edge' router an IMQ qdisc allows shaping and prioritising the >> traffic from each peer in both directions separately by matching on >> it's realm number. >> In addition a community is set inside a route-map, with the peer's >> realm and AS number and also with the type of traffic (International, >> National or Local/City peering) >> When a Slave receives a route, it may set (inside route-map) a realm >> based on the originating peer realm/AS or type of traffic and then >> perform shaping/prioritizing of clients traffic based on that. >> >> In short the realm is used as MARK of the route to pass info to iptables. >> >> Thanks! >> _______________________________________________ >> Quagga-dev mailing list >> [email protected] >> https://lists.quagga.net/mailman/listinfo/quagga-dev >> >> _______________________________________________ >> Quagga-dev mailing list >> [email protected] >> https://lists.quagga.net/mailman/listinfo/quagga-dev >> > > _______________________________________________ > Quagga-dev mailing list > [email protected] > https://lists.quagga.net/mailman/listinfo/quagga-dev >
_______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
