[j-nsp] Limit on interfaces in bundle

[Jesper Skriver]

On Sun, Nov 01, 2015 at 05:06:22PM +0200, Saku Ytti wrote:
> On 1 November 2015 at 12:08, Jesper Skriver <jesper at skriver.dk> wrote:
> 
> > To do what you suggest, one either has to replicate the MPLS
> > table, so that we can handle the same label values for each of the
> > suggested MPLS-IPv4, MPLS-IPv6, MPLS-XX, MPLS-YY, with the only
> > different being that they link to different L2 rewrite objects
> > that set the appropriate ethertype. Or alternatively, one has to
> > carry forward information about the ethertype of the received
> > packet, and use it when sending the outgoing packet.
> >
> > Neither is practical.
> 
> Like 8847, all these would go out with same ethertype it came in.
> Lookup would be exactly the same as 8847, only behavioural difference
> would be, what bits are used for balancing.

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
      }

> Maybe I'm being thick, but I'm having difficulties seeing why this
> would be challenging. But it would be challenging to sell this
> composite ethertype idea, people would resist on premise 'we'll run
> out of ethertype field, if everyone needs to do this composite'.

I doubt that will be the hardest sell, 16 bits for this seems
'plenty', even if MPLS ends up using a handful.

/Jesper