> Fernando Gont <mailto:[email protected]> > 9 June 2013 15:46 > Ray, > > I'd say one should enforce a "each EH can be present at most once". > > ANd, me, I'd limit the EH chain to 1280 octets (at most) -- even that is > kind of irrational: 1280 is the IPv6 minimum MTU... so we'd be allowing > packets that are 100& overhead. > > Cheers, I just wanted to start with one simple example. It can of course be extended.
BTW there is a precedent for publishing recommendations to enable optimised parsing of variable byte-aligned options. http://tools.ietf.org/html/rfc1323#page-7 & Appendix A advises an optimal layout of TCP options to enable fast processing of a commonly recurring pattern by RISC processors. > Ray Hunter <mailto:[email protected]> > 8 June 2013 13:06 >> 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 --------------------------------------------------------------------
