I'm sure it had more to do with creating a configuration that follows MEF standards than anything else, but even if they did shove it all 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.
On Sun, Oct 28, 2012 at 4:43 AM, Saku Ytti <[email protected]> wrote: > On (2012-10-27 16:43 -0400), Pete Lumbis wrote: > >> The biggest benefit you'll see with service instances over sub >> interfaces is scalability. By abstracting out the 802.1q tag from the >> forwarding action we don't necessarily have to burn platform resources >> to make things happen. > > Yes, it works differently in the backend, but why must this be exposed to > frontend? When configuration has no need to burn 802.1q tag, don't burn > resources, do it intelligently in software, without user interaction. > >> For example, say you have 100 xconnects (L2VPN circuits) on a single >> trunk interface. Traditionally you'd have to configure 100 sub >> interfaces (or SVIs) which burns 100 VLANs on that platform. This >> >> if you have this same deployment with service instances you are merely >> matching the tag on that port. You have 100 service instances >> processing 100 802.1q tags (just like before) but now you haven't >> burned any global VLAN resources. > > Right. And there is no technical reason, why when committing subinterface > config with xconnect, it couldn't work exactly like it works today in EVC. > Transparently, without user-interaction. > So my question really is, what kinda benefits we do have in this double > logical interface config structure? Is there something I can configure in > both styles and might need to configure in both styles for single box for > different requirement? As far as I know, no, I either need EVC or > subinterface, which to mean translates single-behavioural need for UI. > > Seems not that hard 'do I have L3 AFI' yes -> create global VLAN. 'do I > have L3 AFI' no -> handle locally. > > -- > ++ytti > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
