[c-nsp] ME3600x sub-interfaces

[Saku Ytti]

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