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.
Tom _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
