Standards 101 is either support the standard or revise it. The latter was tried and rejected.
Whatever you do, don’t fail to support it for false reasons. Joe > On Nov 27, 2018, at 2:52 AM, Stewart Bryant <[email protected]> wrote: > > I was simply explaining forwarding engineering 101, which seemed to be being > forgotten in the tread. > > Beyond that I don’t much care on way or the other. > > Stewart > > > >> On 27 Nov 2018, at 10:40, Joe Touch <[email protected]> wrote: >> >> Take that to the standards wg. Don’t stick your head in the sand and try to >> do an end run in ops. And don’t call any of this a security issue that it >> isn’t. >> >> Joe >> >>> On Nov 27, 2018, at 2:17 AM, Stewart Bryant <[email protected]> >>> wrote: >>> >>> >>> >>>> On 27/11/2018 01:47, Joe Touch wrote: >>>> If you can’t handle options, then you’re just lying about the tbps. >>> >>> When the required application performance exceeds the ability of the >>> hardware >>> designers to deliver it economically (or may be at any price) something has >>> to give. >>> At that point either the protocol gets modified, or it goes end of life. >>> >>> - Stewart >>> >>>> Joe >>>> >>>>> On Nov 26, 2018, at 5:18 PM, Nick Hilliard <[email protected]> wrote: >>>>> >>>>> Joe Touch wrote on 26/11/2018 21:59: >>>>>> Rate limiting is quite different from 100% discards. When abuse >>>>>> happens, it's clearly safe to react. >>>>> data plane speeds are measured in terabits/sec. Control plane capacity >>>>> for dealing with punted packets is measured in kilobits. As end user and >>>>> data plane speeds increase, rate-limiting for problematic packets will >>>>> tend towards towards 100% loss. >>>>> >>>>> It doesn't matter if your packet stream is subject to 20% loss, or 100%, >>>>> or 100% for 20% of the time - beyond a certain point, the end user >>>>> experience will languish in an indistinguishable morass of unusability. >>>>> >>>>> Nick >>>>> >>>>> _______________________________________________ >>>>> Tsv-art mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/tsv-art >>> >> _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
