[j-nsp] Limit on interfaces in bundle

[Jesper Skriver]

Saku,

On Fri, Oct 30, 2015 at 10:47:48PM +0200, Saku Ytti wrote:
> On 30 October 2015 at 12:35, Jesper Skriver <jesper at skriver.dk> wrote:
> 
> > That would not be practical to implement for a router, implementations
> > typically have the L2 header cached and the L3 forwarding
> > constructs just point to a rewrite object that contain the
> > appropriate L2 encap for the next-hop selected by L3.
> >
> > What you are proposing means that a single L3 object needs to
> > point to different L2 rewrite objects depending on what L2 encap
> > was on the packet when received.  Many architectures just cannot
> > do that, and for others it would for sure come at a performance
> > penalty.
> 
> I'm surprised by this. Because LSR today could have single interface,
> which egresses native IPv4, IPv6, ARP, or MPLS, depending on ingress.

Right, but those are distinct L3 protocols, a packet with an
ethertype of 0x0800 will have the destination IPv4 address looked
up in an IPv4 prefix table, and the result of that is a rewrite
operation. The rewrite operation may send it as an IPv4 packet and
will link to a next-hop rewrite object that will add a new L2
encap with an ethertype of 0x0800. If the rewrite operation
includes pushing MPLS labels, the rewrite object will add an L2
encap with ethertype 0x8847.

For packets arriving with an ethertype of 0x8847 it will result in
the label value being looked up in the MPLS table, and from there
onwards it is practically the same, the result of the lookup will
point to a L2 rewrite object that contain the appropriate new
ethertype. This may be 0x0800 for disposition to IP or 0x8847 if
adding/swapping labels.

In both cases the ethertype of the new L2 encap is determined at
programming time, and not carried over from the ethertype of the
received L2 encap.

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.

> And I know 7600 offers ethertype in egress rewrite information, so it
> could impose any ethertype as lookup result.

See above, it is static information set a programming time.

> Obviously high-touch platforms like ASR9k, MX, 7750SR, CX600/NE40
> could also do any type of egress ethertype.

Same thing for all the ones I know in detail, and I would be
surprised if any of them were different.

> In the proposed scenario, LSR would not change the ethertype, if it
> came in as MPLS-IP, it would go out as MPLS-IP, ingress LER would
> decide ethertype.
> 
> I'm not surprised that there would be some platforms where this
> limitation exists, but I would have guessed those are very restricted
> L3 switches which already have many limitations, such as not
> supporting control-word etc.

There might be the odd one that cannot set anything it wants in
the ethertype field, but those will be rare - the issue is not
that, it is how to know what to put there.

/Jesper