On Thu, Nov 25, 2021 at 6:46 AM Tim Chown <[email protected]> wrote: > > It’s in 4.4 (routers and L3 switches). Does it need to be in 4.1, Hosts?
I'd like it to be available everywhere. :) fq_codel is already pretty universal in linux hosts. sch_fq is better for a solely tcp-serving workloads where it can apply pacing more directly, but what a "host" is, post kubernetes, post network namespaces, with vms, with tunnels, vpns, with quic, etc, looks a lot more like a router. There's a debate here - with 27 8x10 glossy pictures with circles and arrows and a paragraph on the back of each one - making that point, for a "host" - over here: https://github.com/systemd/systemd/issues/9725#issuecomment-413369212 > > Tim > > > On 25 Nov 2021, at 14:43, Dave Taht <[email protected]> wrote: > > > > yes please. > > > > On Thu, Nov 25, 2021 at 3:36 AM Tim Chown <[email protected]> wrote: > >> > >>> On 23 Nov 2021, at 16:41, Dave Taht <[email protected]> wrote: > >>> > >>> On Tue, Nov 23, 2021 at 8:31 AM Tim Chown <[email protected]> wrote: > >>>> > >>>> Hi Dave, > >>>> > >>>>> On 23 Nov 2021, at 16:09, Dave Taht <[email protected]> wrote: > >>>>> > >>>>> It is perhaps selfish of me to really want active queue management, of > >>>>> some form, as part of specifications for new equipment. > >>>>> > >>>>> https://datatracker.ietf.org/doc/rfc7567/ > >>>> > >>>> I would agree, but this doc is IPv6 requirements, while the RFC is > >>>> generally applicable to v4 or v6? > >>> > >>> It's an and, not an or. > >>> > >>> Additionally useful treatments of the ipv6 flow header, and the > >>> diffserv & ecn bits, the ability to shape or police traffic, would be > >>> nice to have in a document that talks to the properties of switches > >>> and routers. > >> > >> So we could for example in Section 4 in Optional at least add > >> > >> • Active Queue Management support [RFC7567] > >> > >> ? > >> > >> (Where AF and EF are listed for QoS) > >> > >> Tim > >> > >>> > >>>> Tim > >>>>> > >>>>> On Tue, Nov 23, 2021 at 7:38 AM Tim Chown via ipv6-wg > >>>>> <[email protected]> wrote: > >>>>>> > >>>>>> Hi Eric, > >>>>>> > >>>>>> > >>>>>> Many thanks for your comments, we’ve updated the ‘living draft’ at > >>>>>> https://docs.google.com/document/d/10HsfHDOIhUPIvGk9WP0azJiIsMVzQ49RsqWfnbNtceI/edit# > >>>>>> And attached as PDF. > >>>>>> > >>>>>> In-line... > >>>>>> > >>>>>>> On 5 Nov 2021, at 07:52, Eric Vyncke (evyncke) <[email protected]> > >>>>>>> wrote: > >>>>>>> > >>>>>>> Tim*2, Sander, Jan, and Merike, > >>>>>>> > >>>>>>> First of all, thank you for taking the pen to update this document. > >>>>>>> As you kindly asked for comments, here are some > >>>>>>> - page 2: 'fairly recent' won't age well ;-) > >>>>>> > >>>>>> Removed. > >>>>>> > >>>>>>> - page 4: all requirements are limited to performance, but should it > >>>>>>> also include telemetry/monitoring ? Or is it implicit in the list of > >>>>>>> RFC ? > >>>>>> > >>>>>> Agreed - we added mention of capabilities in a couple of places. > >>>>>> > >>>>>>> - page 4: what about systems to handle VMs and containers ? > >>>>>> > >>>>>> Out of scope. > >>>>>> > >>>>>>> - page 4: mobile devices have a *big difference* with normal host > >>>>>>> though as they often have multiple interfaces active at the same time. > >>>>>> > >>>>>> True, but out of scope. The document is about their connectivity to > >>>>>> the enterprise infrastructure. We could note this, but currently do > >>>>>> not. > >>>>>> > >>>>>>> - page 4: should we assume that Wi-Fi access points are 'normal > >>>>>>> layer-2 switches' ? > >>>>>> > >>>>>> Added text to say consider as L2 consumer switch, see Section 3.1. > >>>>>> > >>>>>>> - page 6: I am surprised to see RFC 8415 DHCPv6 client as mandatory… > >>>>>> > >>>>>> Fair comment, as this could be something contentious. The only way we > >>>>>> can think to avoid that is to include the DHCPv6 requirements > >>>>>> conditionally, ie. “IF you need DHCPv6 then…” those requirements are > >>>>>> required. So networks deploying with just RA for address > >>>>>> configuration can avoid that. > >>>>>> > >>>>>>> - page 6: if not mistaken RFC 8200 now includes RFC 5722 and RFC 8021 > >>>>>>> (so no need to add the latter in the requirements) > >>>>>> > >>>>>> Deleted 5722 and 8021. > >>>>>> > >>>>>>> - page 7: same surprise to see all DHCP-related requirements > >>>>>> > >>>>>> Also made into an “If DHCPv6 is needed then” > >>>>>> > >>>>>>> - page 7 and other: nice to list some MIB but I would expect some > >>>>>>> YANG modules as well for enterprise/ISP devices > >>>>>> > >>>>>> RFC8504 covers this in16.2, should we say the same words here, as > >>>>>> optional in each section? > >>>>>> https://datatracker.ietf.org/doc/html/rfc8504#section-16.2 > >>>>>> Thoughts? > >>>>>> > >>>>>>> - page 9: should Jen's RFC 9131 be added as optional ? > >>>>>> > >>>>>> Can do, in which sections? Presumably 4.1 and 4.4? > >>>>>> > >>>>>> Best wishes, > >>>>>> Tim > >>>>>> > >>>>>> > >>>>>> To unsubscribe from this mailing list, get a password reminder, or > >>>>>> change your subscription options, please visit: > >>>>>> https://lists.ripe.net/mailman/listinfo/ipv6-wg > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> I tried to build a better future, a few times: > >>>>> https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org > >>>>> > >>>>> Dave Täht CEO, TekLibre, LLC > >>>> > >>> > >>> > >>> -- > >>> I tried to build a better future, a few times: > >>> https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org > >>> > >>> Dave Täht CEO, TekLibre, LLC > >> > > > > > > -- > > I tried to build a better future, a few times: > > https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org > > > > Dave Täht CEO, TekLibre, LLC > -- I tried to build a better future, a few times: https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org Dave Täht CEO, TekLibre, LLC To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/ipv6-wg
