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