[c-nsp] ME3600x sub-interfaces

[Pete Lumbis]

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 <saku at ytti.fi> 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  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/