Saku, On Fri, Oct 30, 2015 at 10:47:48PM +0200, Saku Ytti wrote: > On 30 October 2015 at 12:35, Jesper Skriver <[email protected]> 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 _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
