On Tue, Aug 9, 2016 at 7:41 PM, Alia Atlas <[email protected]> wrote: > Tom, > > On Tue, Aug 9, 2016 at 10:27 PM, Tom Herbert <[email protected]> wrote: >> >> On Tue, Aug 9, 2016 at 6:54 PM, Alia Atlas <[email protected]> wrote: >> > Joe, >> > >> > On Tue, Aug 9, 2016 at 9:40 PM, Joe Touch <[email protected]> wrote: >> >> >> >> >> >> >> >> On 8/9/2016 6:28 PM, Alia Atlas wrote: >> >> > Joe, >> >> > >> >> > In the past 15+ years, I haven't seen this limitation going away. >> >> >> >> If you want to base a limitation on a prediction of future hardware, >> >> then do that. >> >> >> >> But don't simply base it on existing hardware. >> >> >> >> There's zero point to an RFC that is outdated before it is published. >> >> >> >> > It is expensive to pass the whole packet through the packet >> >> > forwarding >> >> > logic. >> >> >> >> No disagreement, but that doesn't necessarily mean that future hardware >> >> will be as shallow into the packet as current hardware either. >> >> >> >> > ... >> >> > >> >> > Given that this is frequently a basic attribute of a system's >> >> > architecture, expecting >> >> > it to change drastically to handle an encapsulation without stunning >> >> > technical advantage >> >> > is rather unlikely. >> >> >> >> But that's exactly what I do expect. Encapsulation is becoming more >> >> prevalent, as is DPI. The deeper things get, the deeper hardware WILL >> >> end up looking into the packet. >> >> >> >> I understand making the system easy to implement in hardware in >> >> general, >> >> but we really need to NOT design protocols that are obsolete even >> >> before >> >> the ink is dry. >> > >> > >> > Hyperbole is great. Recall that we're talking about a choice between 3 >> > protocols >> > where the highest technical advantage is extensibility or ability to be >> > implemented >> > on many common router architectures. >> > >> > There has to be a plausible reason for folks to actually implement >> > whatever >> > encapsulation is done. The IETF needs to be practical in its >> > selections. >> > Running >> > code (or hardware) in this case does matter - not just speculative >> > future >> > hardware. >> > >> We had many discussions in the Encapsulation Design team on the >> particular issue of "HW friendliness" (draft-ietf-rtgwg-dt-encap-01). >> One of the recommendations we came up with is "Keep the encap header >> small. Switches and routers usually only read the first small number >> of bytes into the fast memory for quick processing and easy >> manipulation.". Note that this is pretty vague, we don't specify >> exactly what the small number should be. This was because we could not >> find any consensus among hardware vendors as to what the limit should >> be; some said the limit is 128, some said 256 bytes, still others said >> no limit. This theme was true for most of the hardware guidelines we >> produced. For instance, I asked five different HW experts what they >> thought of variable length headers and got five different answers >> ranging from they're a major problem in hardware to being no problem >> at all. I agree we need to be practical, but neither does it seem like >> we should constrain protocols to the least common denominator of >> current hardware support. > > > Yes, it isn't clear what the limits are because it varies based on vendor > and even particular system. Clearly, some limit is necessary and a concern > for a common standard. Powers of 2 are always popular with hardware > and software designers. > The power of 2 property is a nice simplification, based on that I believe the minimum length of headers we should expect hardware to be able to deal with is 256 bytes. I posted an I-D proposing that in https://tools.ietf.org/html/draft-herbert-int-area-limits-00. Since this limit applies to all protocol layers and options (e.g. IPv6 extension headers) and not just items in nvo3, this might be more of a discussion to have in int-area?
Thanks, Tom _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
