On (2014-09-02 06:56 +0200), Mark Tinka wrote: > This is one of those polarizing questions where you'll get > an equal share of answers from both sides of the bench.
I think main reason is, because it appears scary, and I subscribe to that notion myself. When I try to explain it to myself in technical terms, I'm drawing up short. In smart implementation, there should be insignificant DRAM use increase due to few bytes of RT and RD, none of these should affect HW resource use in anyway. Infact JunOS and IOS should not have implied 'Default' VRF, it should be configured VRF like any other VRF. Because it simplifies the code-base, when you do not create VRF-aware and VRF-unaware features. Infact if you look at FIB/HW, there global table is already just another VRF, as these structures lend poorly to exceptions. It's only the control-plane code, which due to legacy reasons contain duplicate code for exact same stuff, causing annoying feature parity problems amongst others. I think the main benefit would be obviously the ease of adding Internet access to other VRFs. -- ++ytti _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp