[j-nsp] Limit on interfaces in bundle

[Jesper Skriver]

On Mon, Nov 02, 2015 at 06:47:06PM +0200, Saku Ytti wrote:
> On 2 November 2015 at 18:09, Jesper Skriver <jesper at skriver.dk> wrote:
> > I am not sayint that it doesn't make sense - I am saying that it
> > doesn't appear practical given the architecture of the average
> > router. What I've described above is how the typical router
> > is implemented.
> >
> > Feel free not to believe me, but I do have some experience in the
> > area.
> 
> I fully believe and expect there are platforms where it would not be
> viable, especially 'l3 switch' type devices which make lot of
> assumptions to reduce cost. But I'd be surprised if high touch devices
> like ezchip, trio, solar (or what ever the huawei chip was called),
> fp3 etc. couldn't do it.
> Naively it feels like classify on ingress NPU, inject the
> classification information on cell headers over fabric, egress NPU
> then produces l2 rewrite information, taking into consideration the
> classification found on cell headers.

Right, on those types of platforms it can be done - assuming there
are spare bits in the meta data that goes with the packet, enough
free instruction space etc - but it will come at a performance impact
as it will require more cycles per packet, unless on the
particular platform there is still headroom for adding more cycles
without affecting the ability to be linerate ...

Which is why I in my original reply said that it would not be
practical. For it to be useful all routers in the path needs to
support it, otherwise as soon as it hits one that doesn't all the
various MPLS sub-types will get mixed together again.
Features which require network wide support are quite hard to get
off the ground.

/Jesper