[j-nsp] Limit on interfaces in bundle

[Jesper Skriver]

On Mon, Nov 02, 2015 at 03:04:22PM +0000, Adam Vitkovsky wrote:
> > Saku,
> >
> > The point is that the incoming ethertype is only used to determine how to
> > interprete the header (IPv4, IPv6, MPLS etc) and to select what L3 table to
> > lookup in. After that it is gone, and never used again.
> >
> > The L3 lookup result in a rewrite operation, which will impose a new L2 encap
> > with associated ethertype on the packet. This ethertype is statically
> > programmed into this rewrite object, and is completely independent of the
> > ethertype of the received packet.
> >
> > So to do what you suggest, there are two options
> >
> > 1) Keep all the logic as today, but for different received
> >    ethertypes point to different L3 tables, that result in
> >    different rewrite objects that ensure the outgoing packets
> >    have the different ethertypes requested.  This require that you
> >    replicate the MPLS table for each of your ethertypes.
> >
> > 2) Change the logic such that the incoming ethertype is
> >    remembered, and on egress do not use a static ethertype, but
> >    instead do something like
> >       if ( input ethertype is one of the MPLS ones &&
> >            output ethertype is 'mpls' &&
> >            no operation performed changed the nature of the payload ) {
> >          output_ethertype = input_ethertype
> >       }
> >
> 
> I don't see any problem with adjusting rewrite objects dynamically based on the ingress properties (like during QOS).
> It only depends on what is defined as rewrite object (I guess those are the bits(fields) that should be constant).
> But I would argue that the only piece that will always be constant is the source MAC address.

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.

/Jesper