On Wed, 20 Jan 2016, Vipin Kumar wrote:
Sure. I dont deny the value of carving out logically/functionally separate components and introducing some new daemons running with those functionalities. However, I think that can be done incrementally as a separate project (after this) as well.
Can it?
To highlight that point, I am attaching some of current patches (which work for default name-space only for now) Please note these are not quite consumable set of patches yet(you can see bunch of Pending items), we will submit those later after handling more corner cases and UT/IT.
This is touching on a concern I have. We have to have wave after wave of VRF patches, that have to touch *lots* of code to extend it to be VRF aware, and we *still* don't actually have any meaningful VRF ability.
On the flip-side, you could write a daemon in a matter of weeks to setup VRFs and launch the right daemons in them, and it'd work - with little churn to existing routing code.
Why should we take the high-churn path - probably for a year or more to come - when there is a simpler, lower-churn, lower-conflict path?
regards, -- Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A Fortune: The hardest thing is to disguise your feelings when you put a lot of relatives on the train for home. _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
