Tom, On Tue, Aug 9, 2016 at 10:27 PM, Tom Herbert <t...@herbertland.com> wrote:
> On Tue, Aug 9, 2016 at 6:54 PM, Alia Atlas <akat...@gmail.com> wrote: > > Joe, > > > > On Tue, Aug 9, 2016 at 9:40 PM, Joe Touch <to...@isi.edu> 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. Regards, Alia
_______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
