[j-nsp] Limit on interfaces in bundle

Saku Ytti saku at ytti.fi
Mon Nov 2 18:22:49 EST 2015

On 2 November 2015 at 19:14, Jesper Skriver <jesper at skriver.dk> wrote:
> 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.

I'm not sure it would change anything from status quo, except make the
duck type explicit type.

Devices which today do MPLS payload duck typing, will have this
classification information on egress NPU, as they are doing ECMP
decision. Same network today can have other LSR devices in the path,
which don't do duck typing, and will not ECMP the flow. This does not
cause problems, assuming there isn't capacity problem.
So I don't immediately see, how come this isn't entirely local decision.


More information about the juniper-nsp mailing list