> joel jaeggli <mailto:[email protected]> > 8 June 2013 11:12 > On 6/6/13 10:41 PM, Ray Hunter wrote: >>> joel jaeggli <mailto:[email protected]> >>> 6 June 2013 22:19 >>> On 6/6/13 4:09 PM, Fernando Gont wrote: >>>> On 06/06/2013 06:20 PM, Nalini Elkins wrote: >>>>> So, if we are talking about the MTU of the local egress interface, >>>>> then >>>>> since, I believe, the minimum MTU size for IPv6 is 1,280, then all >>>>> devices should be prepared to examine up to 1,280 bytes to get the L4 >>>>> header? >>>> In theory, yes. In practice, it wouldn't make much sense, probably >>>> (most >>>> of the packet containing overhead?). >>> There's a question you can pose to an asic designer... What does it >>> cost at this point to extend the header processing from 53/64/128/256 >>> bytes. bearing in mind also that part of the reason that the space >>> already has increased is due to encapsulation, label-in-label q-in-q >>> so the ipv6 header is not the only thing competing for more room. >>>> Cheers, >> May I suggest some other questions: >> >> Does size matter? > It does because typically the memory associated with the > forwarding/header lookup is very fast and expensive. It never holds > the whole packet currently. This was of course in our draft. Understood.
Do you think hardware based forwarding with parsing of a header up to a single frame at wire speed is realistic in the foreseeable future? [no state required to be maintained across frames, but upper limit = entire header is contained in the 1st frame of a packet, as per draft-ietf-6man-oversized-header-chain-02] >> >> Or is the complexity of the ASIC implementation of a header chain parser >> more heavily influenced by the fact that the header chain is defined as >> a linked list of type-length-value items that can be built up in any >> number of valid combinations, and so has to be traversed and interpreted >> at every individual link? > Traversal is expensive yes. ACK. Can we as an IETF community do anything about that? "Unhindered by any technical knowledge" as they say in Dutch, if we published an *informational* RFC that defined some basic syntax structure to facilitate optimized forwarding in hardware, would this help out with simplifying future designs (less iterative traversal, less transistors, less branch complexity) and get us all more bang for the buck? I was thinking something along the lines of: - The preferred length of a Hop by Hop extension header for optimized forwarding in hardware is always 16 octets long. - the Hop by Hop EH may be present exactly once, or not present, and is always transmitted directly after the IPv6 header (already the case in 2460) - Strict processing in transmission order is not required when performing optimized hardware forwarding, and options may be evaluated in parallel (potentially dubious according to 2460) provided that only the Pad1, PadN, Jumbogram and Router Alert options are present. - the Router Alert option RFC2711 should always be the first option (4 octets) if present if not present it should be replaced with Padn option for 4 octets - the second option should always be the Jumbogram option (rfc2675) (6 octets) if present if not present it should be replaced with Padn option for 6 octets - The remaining 4 octets are currently undefined (reserved for future use) and should be filled with 4 * pad1 (4 octets) [Just trying to help out making sensible trade offs] regards, RayH >> >> What if the most common individual TLV option tokens were standardized >> further? >> >> And the transmission order fixed? >> >> What if the most common individual extension headers were standardized >> further? >> >> And the transmission order fixed? >> >> Would this help make hardware parsing possible/economic? >> >> regards, >> RayH >> > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
