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.
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 seems pretty pointless since every frame that comes in that sub-interface will just be shoved over the xconnect. 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. On Sat, Oct 27, 2012 at 3:35 AM, Saku Ytti <[email protected]> wrote: > On (2012-10-26 13:50 -0400), Jason Lixfeld wrote: > >> Service instances are Cisco's 2012 way of doing subinterfaces: > > Which is utterly inexcusable, just because you support some new things in > the backend, does not mean you should expose completely new abstraction > model to the frontend. > > What you configure in EVC should be configurable just as well in > subinterface. With the difference that your existing config parsers would > work and your existing SNMP graphing would work etc. > > I'm not even proponent of backward compatibility, if some benefits can be > gained by making things in a new way, I'm all for breaking stuff. But if > there is some benefit at all in EVC, I've not yet seen it, and I'd love to > be corrected. > > -- > ++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/
