On 22 Jun 2011, at 07:18 , Philip Homburg wrote: > In your letter dated Wed, 22 Jun 2011 07:08:43 -0400 you wrote: >> More importantly, the implementation approach I described on the IPv6 >> list is neither complicated nor computationally expensive. In fact, >> supporting the limited set of non-silly-for-ND-packet Extension Headers >> has tiny incremental memory footprint and tiny increase in the >> instruction count. The instruction count increase only applies if >> an actual Extension Header is encountered, btw. The code for a L2 >> device to locate the IPv6 header, read that header, and read into >> the ICMP message to determine that a packet is an ND packet *dwarfs* >> the code to skip past the small set of reasonable Extension Headers >> for ND packets. > > I have to admit I don't know much about the internals of L2 switches. > But my mental model of a 10 Gbit/s ethernet switch is that of an > ASIC/FPGA that does almost all forwarding with the CPU just for management.
I spent most of the last decade building high-performance Ethernet switches. Your mental model is generally the case, but that ASIC/FPGA often already includes IPv4/IPv6 routing capability including some degree of packet parsing capability. (Even the low-cost "consumer electronics" L2 switches now often/commonly use a commodity ASIC that includes at least some L3 capabilities -- although a given product might or might not software-enable those chip features.) Some chips can parse/parse-past any legal combination of IPv4/IPv6 headers at wire-speed. Some can parse past a subset, again at wire-speed, with the most common IPv6 subset being the Routing Header, Destination Options header, and Hop-by-Hop header. I know of at least 2 Ethernet switch vendors that already have sold/deployed ASIC/FPGA-based switches that can parse past IPv6 extension headers (i.e. to read transport-layer header information & provide wire-speed ACLs, to handle an ICMPv6 message, etc.). For the genuine L2-only ASIC/FPGA devices, those without ANY L3 capabilities, any form of Fernando's proposal will require that **all** IPv6 packets, anything with (EtherType=0x86dd) not just all IPv6 ND packets, be sent via the CPU. As you noted later on, this precise situation leads to real challenges in throughput, switch resilience, etc. In such a pure-L2-only case, the big performance hit is parsing INTO the IPv6 packet in the first place. One won't even be able to detect whether a packet is an ND packet until one has parsed inside the ICMPv6 header. Best case, getting that far in is a bunch of CPU instructions for each IPv6 packet. Once one has decided to do that, which might or might not be a wise product-management decision, then parsing past the Dest Opts Header or Hop-by-Hop Header is a tiny incremental hit that applies only to those packets with such headers. Of course, packet reassembly IS expensive. This is why my proposal does NOT disagree with Fernando's proposal to outright ban the IPv6 Fragment Header for IPv6 ND packets. > I've no idea how expensive it would be to parse > extension headers in an ASIC. Good question. I have data. For one implementation I am very familiar with, that Verilog did not significantly increase the gate count, did not make gate layout/place harder, and did not increase the die size. Folks I know who worked on a genetically different ASIC with similar packet parsing capabilities tell me their experience was roughly the same (i.e. gate count increase was minor, no new layout/place issues, and no increase in chip die size). So my answer would be "not very expensive", based on actual experience with this in a commercial product environment. > I think it is a bit ironic that if a L2 device has to parse > all extension headers, that then L2 switching of IPv6 packets > will be more expensive that L3 routing them. For a pure L2-device, without any L3 hardware capabilities, one imagines that the most common product-manaagement decision would be to ignore Fernando's entire spec (and not claim to support it). Again, for a pure L2-device, the expensive part of Fernando's spec is parsing from (EtherType==0x86dd) and start-of-frame to the point where the switch can learn that the packet contains ICMPv6 and that the ICMP Type indicates an ND packet. Parsing past the Dest Opts header & Hop-by-Hop header is a tiny incremental CPU hit (a few assembler instructions) on that basic unavoidable cost. For an L3-capable chip, it often is still possible to use some of the chip's L3 features (e.g. packet parsing) even when the chip is bridging a frame instead of routing a packet. So for the devices using an L3-capable chip, it is not necessarily the case that L2 switching would be more expensive than L3 routing. (Obviously L2 switching with an RA-Guard could be more expensive than L3 routing with RA-Guard for particular chip implementations; I have no doubt that some such chips both exist and are present in some commonly deployed devices.) I do think there is a real question of how deployable Fernando's RA Guard proposal will be *in the near term*. In the longer term, one would hope that the chipset vendors that need to spin a chip would plan for this whenever they do such a spin. (Ultimately, the market will decide whether Fernando's spec deploys, even if the IETF endorses it, as is true with so many notional capabilities.) Cheers, Ran -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
