On (2012-10-30 14:26 -0400), Pete Lumbis wrote: > under a sub-interface you're now talking about completely rewriting > the sub-interface frame handling and data structure components. I > think there'd be more outrage when previously working sub-interfaces > run into bugs after an upgrade than doing all that development on a > new feature.
If this is what it means then the config must be pretty close to hardware. I would very least expect that parser is ran against the config which then decide what to program and where. If this is the case, then the parser could invoke EVC code-path for subinterface without L3 AFI and classic code-path for subinterface with L3 AFI. Not having to touch classic code path at all, not affecting L3 interfaces at all. It seem simply UI pollution to have two different subinterfaces. If classic subinterfaces are somehow broken, and plan is to add L3 support to EVC down the line and remove subinterfaces completely, that's fine to me also. I just cannot understand need for two, and how other vendors seem to be able to deliver services in single subinterface abstraction model. -- ++ytti _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
