On 2 November 2015 at 19:14, Jesper Skriver <jes...@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. -- ++ytti _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
