Re: [ipv6-wg] Latest draft for RIPE554-bis
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 ;-) - page 4: all requirements are limited to performance, but should it also include telemetry/monitoring ? Or is it implicit in the list of RFC ? - page 4: what about systems to handle VMs and containers ? - page 4: mobile devices have a *big difference* with normal host though as they often have multiple interfaces active at the same time. - page 4: should we assume that Wi-Fi access points are 'normal layer-2 switches' ? - page 6: I am surprised to see RFC 8415 DHCPv6 client as mandatory... - page 6: if not mistaken RFC 8200 now includes RFC 5722 and RFC 8021 (so no need to add the latter in the requirements) - page 7: same surprise to see all DHCP-related requirements - page 7 and other: nice to list some MIB but I would expect some YANG modules as well for enterprise/ISP devices - page 9: should Jen's RFC 9131 be added as optional ? Hope this helps -éric PS: the attached PDF has the same comments in the text. On 02/11/2021, 16:05, "ipv6-wg on behalf of Tim Chown via ipv6-wg" <ipv6-wg-bounces@ripe.net on behalf of ipv6-wg@ripe.net> wrote: Hi, Attached below is the latest draft for RIPE554-bis, the update to Requirements For IPv6 in ICT Equipment. The authors have incorporated feedback received on and off list, and believe the current draft is a candidate to be considered towards publication. We have a slot in the upcoming RIPE meeting to present and discuss the latest changes, but further list feedback would be welcome now. Is it ready to ship? If not, why not? The original version can be found at https://www.ripe.net/publications/docs/ripe-554 Best wishes, Tim
Hi Eric, Many thanks for your comments, we’ve updated the ‘living draft’ at https://docs.google.com/document/d/10HsfHDOIhUPIvGk9WP0azJiIsMVzQ49RsqWfnbNt... And attached as PDF. In-line...
On 5 Nov 2021, at 07:52, Eric Vyncke (evyncke) <evyncke@cisco.com> 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
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/ On Tue, Nov 23, 2021 at 7:38 AM Tim Chown via ipv6-wg <ipv6-wg@ripe.net> wrote:
Hi Eric,
Many thanks for your comments, we’ve updated the ‘living draft’ at https://docs.google.com/document/d/10HsfHDOIhUPIvGk9WP0azJiIsMVzQ49RsqWfnbNt... And attached as PDF.
In-line...
On 5 Nov 2021, at 07:52, Eric Vyncke (evyncke) <evyncke@cisco.com> 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
Hi Dave,
On 23 Nov 2021, at 16:09, Dave Taht <dave.taht@gmail.com> wrote:
It is perhaps selfish of me to really want active queue management, of some form, as part of specifications for new equipment.
I would agree, but this doc is IPv6 requirements, while the RFC is generally applicable to v4 or v6? Tim
On Tue, Nov 23, 2021 at 7:38 AM Tim Chown via ipv6-wg <ipv6-wg@ripe.net> wrote:
Hi Eric,
Many thanks for your comments, we’ve updated the ‘living draft’ at https://docs.google.com/document/d/10HsfHDOIhUPIvGk9WP0azJiIsMVzQ49RsqWfnbNt... And attached as PDF.
In-line...
On 5 Nov 2021, at 07:52, Eric Vyncke (evyncke) <evyncke@cisco.com> 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
On Tue, Nov 23, 2021 at 8:31 AM Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
Hi Dave,
On 23 Nov 2021, at 16:09, Dave Taht <dave.taht@gmail.com> wrote:
It is perhaps selfish of me to really want active queue management, of some form, as part of specifications for new equipment.
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.
Tim
On Tue, Nov 23, 2021 at 7:38 AM Tim Chown via ipv6-wg <ipv6-wg@ripe.net> wrote:
Hi Eric,
Many thanks for your comments, we’ve updated the ‘living draft’ at https://docs.google.com/document/d/10HsfHDOIhUPIvGk9WP0azJiIsMVzQ49RsqWfnbNt... And attached as PDF.
In-line...
On 5 Nov 2021, at 07:52, Eric Vyncke (evyncke) <evyncke@cisco.com> 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
Hi,
On 23 Nov 2021, at 16:41, Dave Taht <dave.taht@gmail.com> wrote:
On Tue, Nov 23, 2021 at 8:31 AM Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
Hi Dave,
On 23 Nov 2021, at 16:09, Dave Taht <dave.taht@gmail.com> wrote:
It is perhaps selfish of me to really want active queue management, of some form, as part of specifications for new equipment.
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.
Fair point, and we do have for example • (QOS) Assured Forwarding [RFC2597] • (QOS) Expedited Forwarding [RFC3246] In section 4.4 for routers and L3 switches. Other views? Tim
Tim
On Tue, Nov 23, 2021 at 7:38 AM Tim Chown via ipv6-wg <ipv6-wg@ripe.net> wrote:
Hi Eric,
Many thanks for your comments, we’ve updated the ‘living draft’ at https://docs.google.com/document/d/10HsfHDOIhUPIvGk9WP0azJiIsMVzQ49RsqWfnbNt... And attached as PDF.
In-line...
On 5 Nov 2021, at 07:52, Eric Vyncke (evyncke) <evyncke@cisco.com> 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
On 23 Nov 2021, at 16:41, Dave Taht <dave.taht@gmail.com> wrote:
On Tue, Nov 23, 2021 at 8:31 AM Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
Hi Dave,
On 23 Nov 2021, at 16:09, Dave Taht <dave.taht@gmail.com> wrote:
It is perhaps selfish of me to really want active queue management, of some form, as part of specifications for new equipment.
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 <ipv6-wg@ripe.net> wrote:
Hi Eric,
Many thanks for your comments, we’ve updated the ‘living draft’ at https://docs.google.com/document/d/10HsfHDOIhUPIvGk9WP0azJiIsMVzQ49RsqWfnbNt... And attached as PDF.
In-line...
On 5 Nov 2021, at 07:52, Eric Vyncke (evyncke) <evyncke@cisco.com> 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
yes please. On Thu, Nov 25, 2021 at 3:36 AM Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
On 23 Nov 2021, at 16:41, Dave Taht <dave.taht@gmail.com> wrote:
On Tue, Nov 23, 2021 at 8:31 AM Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
Hi Dave,
On 23 Nov 2021, at 16:09, Dave Taht <dave.taht@gmail.com> wrote:
It is perhaps selfish of me to really want active queue management, of some form, as part of specifications for new equipment.
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 <ipv6-wg@ripe.net> wrote:
Hi Eric,
Many thanks for your comments, we’ve updated the ‘living draft’ at https://docs.google.com/document/d/10HsfHDOIhUPIvGk9WP0azJiIsMVzQ49RsqWfnbNt... And attached as PDF.
In-line...
On 5 Nov 2021, at 07:52, Eric Vyncke (evyncke) <evyncke@cisco.com> 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
It’s in 4.4 (routers and L3 switches). Does it need to be in 4.1, Hosts? Tim
On 25 Nov 2021, at 14:43, Dave Taht <dave.taht@gmail.com> wrote:
yes please.
On Thu, Nov 25, 2021 at 3:36 AM Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
On 23 Nov 2021, at 16:41, Dave Taht <dave.taht@gmail.com> wrote:
On Tue, Nov 23, 2021 at 8:31 AM Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
Hi Dave,
On 23 Nov 2021, at 16:09, Dave Taht <dave.taht@gmail.com> wrote:
It is perhaps selfish of me to really want active queue management, of some form, as part of specifications for new equipment.
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 <ipv6-wg@ripe.net> wrote:
Hi Eric,
Many thanks for your comments, we’ve updated the ‘living draft’ at https://docs.google.com/document/d/10HsfHDOIhUPIvGk9WP0azJiIsMVzQ49RsqWfnbNt... And attached as PDF.
In-line...
> On 5 Nov 2021, at 07:52, Eric Vyncke (evyncke) <evyncke@cisco.com> 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
On Thu, Nov 25, 2021 at 6:46 AM Tim Chown <Tim.Chown@jisc.ac.uk> 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 <dave.taht@gmail.com> wrote:
yes please.
On Thu, Nov 25, 2021 at 3:36 AM Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
On 23 Nov 2021, at 16:41, Dave Taht <dave.taht@gmail.com> wrote:
On Tue, Nov 23, 2021 at 8:31 AM Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
Hi Dave,
On 23 Nov 2021, at 16:09, Dave Taht <dave.taht@gmail.com> wrote:
It is perhaps selfish of me to really want active queue management, of some form, as part of specifications for new equipment.
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 <ipv6-wg@ripe.net> wrote: > > Hi Eric, > > > Many thanks for your comments, we’ve updated the ‘living draft’ at > https://docs.google.com/document/d/10HsfHDOIhUPIvGk9WP0azJiIsMVzQ49RsqWfnbNt... > And attached as PDF. > > In-line... > >> On 5 Nov 2021, at 07:52, Eric Vyncke (evyncke) <evyncke@cisco.com> 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
OT somewhat and on my beta noir, sorry! I am curious as to what if any, higher end products rfc8290 has appeared in already? It's got to be quite a lot over the past year, particularly on qualcomm and mediatek's wifi chips. I know of preseem and libreQos in middleboxes... a couple I can't talk about unless I find public info on it... https://en.wikipedia.org/wiki/FQ-CoDel Comcast rolled out DOCSIS-pie this year also. Really compelling real-world study across a million boxes here: https://arxiv.org/abs/2107.13968 Very pretty graphs starting pp14. Anyway it's looking like pie and fq_codel are winners (unlike RED). but I'd totally settle for that BCP recommending some form of aqm be available in your document at the two points so far. A deeply philosophical discussion of what constitutes a host could however ensue. On Thu, Nov 25, 2021 at 6:57 AM Dave Taht <dave.taht@gmail.com> wrote:
On Thu, Nov 25, 2021 at 6:46 AM Tim Chown <Tim.Chown@jisc.ac.uk> 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 <dave.taht@gmail.com> wrote:
yes please.
On Thu, Nov 25, 2021 at 3:36 AM Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
On 23 Nov 2021, at 16:41, Dave Taht <dave.taht@gmail.com> wrote:
On Tue, Nov 23, 2021 at 8:31 AM Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
Hi Dave,
> On 23 Nov 2021, at 16:09, Dave Taht <dave.taht@gmail.com> 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 <ipv6-wg@ripe.net> wrote: >> >> Hi Eric, >> >> >> Many thanks for your comments, we’ve updated the ‘living draft’ at >> https://docs.google.com/document/d/10HsfHDOIhUPIvGk9WP0azJiIsMVzQ49RsqWfnbNt... >> And attached as PDF. >> >> In-line... >> >>> On 5 Nov 2021, at 07:52, Eric Vyncke (evyncke) <evyncke@cisco.com> 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
-- 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
Dave Out of curiosity, is it linked to the (controversial) L4S work at the IETF in the TSVWG ? Regards -éric On 25/11/2021, 16:16, "Dave Taht" <dave.taht@gmail.com> wrote: OT somewhat and on my beta noir, sorry! I am curious as to what if any, higher end products rfc8290 has appeared in already? It's got to be quite a lot over the past year, particularly on qualcomm and mediatek's wifi chips. I know of preseem and libreQos in middleboxes... a couple I can't talk about unless I find public info on it... https://en.wikipedia.org/wiki/FQ-CoDel Comcast rolled out DOCSIS-pie this year also. Really compelling real-world study across a million boxes here: https://arxiv.org/abs/2107.13968 Very pretty graphs starting pp14. Anyway it's looking like pie and fq_codel are winners (unlike RED). but I'd totally settle for that BCP recommending some form of aqm be available in your document at the two points so far. A deeply philosophical discussion of what constitutes a host could however ensue. On Thu, Nov 25, 2021 at 6:57 AM Dave Taht <dave.taht@gmail.com> wrote: > > On Thu, Nov 25, 2021 at 6:46 AM Tim Chown <Tim.Chown@jisc.ac.uk> 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 <dave.taht@gmail.com> wrote: > > > > > > yes please. > > > > > > On Thu, Nov 25, 2021 at 3:36 AM Tim Chown <Tim.Chown@jisc.ac.uk> wrote: > > >> > > >>> On 23 Nov 2021, at 16:41, Dave Taht <dave.taht@gmail.com> wrote: > > >>> > > >>> On Tue, Nov 23, 2021 at 8:31 AM Tim Chown <Tim.Chown@jisc.ac.uk> wrote: > > >>>> > > >>>> Hi Dave, > > >>>> > > >>>>> On 23 Nov 2021, at 16:09, Dave Taht <dave.taht@gmail.com> 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 <ipv6-wg@ripe.net> wrote: > > >>>>>> > > >>>>>> Hi Eric, > > >>>>>> > > >>>>>> > > >>>>>> Many thanks for your comments, we’ve updated the ‘living draft’ at > > >>>>>> https://docs.google.com/document/d/10HsfHDOIhUPIvGk9WP0azJiIsMVzQ49RsqWfnbNt... > > >>>>>> And attached as PDF. > > >>>>>> > > >>>>>> In-line... > > >>>>>> > > >>>>>>> On 5 Nov 2021, at 07:52, Eric Vyncke (evyncke) <evyncke@cisco.com> 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 -- 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
On Fri, Nov 26, 2021 at 12:16 AM Eric Vyncke (evyncke) <evyncke@cisco.com> wrote:
Dave
Out of curiosity, is it linked to the (controversial) L4S work at the IETF in the TSVWG ?
If I have any one regret it is turning on RFC3168-style ECN by default in linux (at the 2012 behest of the now L4S side). I would much rather we all move forward on recommending deployments of now-proven technologies using good ole drop, with now well-demonstrated reductions in latency under load of 10-100x across many edge technologies. My position on that debate is very very very nuanced but rooted in (my perceived!) need for backward compatibility with the field deployment (e.g. SCE). I would love operator input here... but on another thread, please! It's very "life of brian"-esq, in that I'd really like all to focus on shipping the tech that demonstrably works, at least pointing out in various RFP oriented standards documents that RFC7567 is ietf-recommended as best current practice ( https://datatracker.ietf.org/group/aqm/documents/ ) and let the market sort it out. My second biggest regret in watching the deployments grow, is not choosing a unique, google-able, identifier for PIE or Cake! My request below is related to the difficulty in finding out what products have shipped a modern AQM or FQ ("SQM") system, and getting data back as to how well they are working. For example, finding riverbed's cake implementation for their branch office routers took some doing. https://support.riverbed.com/bin/support/static/hgc5k5odj0e955sd2uk2qr4ir5/h... DOCSIS-pie is also very very much "out there", but not enabled by anyone except comcast at this point, to my knowledge. On the rfc8290 front... While some are using the name the bufferbloat project chose for the core concepts ("Smart Queue Management") instead of or addition to "QoS", I've documented three of the other trade names in the wikipedia page, but not got around to documenting that the most common name for it in the field being "optimize network for conferencing and gaming" which is what eero and google wifi are using, at least. My assumption, is that in this community believes, overprovisioning was, is, and will remain the principal means for eliminating queuing delay across your networks, and that all the fancy schmancy queueing algos are needed only along the edge and on variable bandwidth wireless technologies. Please feel free to educate me. On another thread? I've got a bit of time off this week to edit wikipedia. And before forking this convo to discuss "the battle of the bit", please put this famous thanksgiving song on in the background: https://www.youtube.com/watch?v=W5_8U4j51lI thx
Regards
-éric
On 25/11/2021, 16:16, "Dave Taht" <dave.taht@gmail.com> wrote:
OT somewhat and on my beta noir, sorry!
I am curious as to what if any, higher end products rfc8290 has appeared in already? It's got to be quite a lot over the past year, particularly on qualcomm and mediatek's wifi chips. I know of preseem and libreQos in middleboxes... a couple I can't talk about unless I find public info on it...
https://en.wikipedia.org/wiki/FQ-CoDel
Comcast rolled out DOCSIS-pie this year also. Really compelling real-world study across a million boxes here:
https://arxiv.org/abs/2107.13968
Very pretty graphs starting pp14.
Anyway it's looking like pie and fq_codel are winners (unlike RED).
but I'd totally settle for that BCP recommending some form of aqm be available in your document at the two points so far. A deeply philosophical discussion of what constitutes a host could however ensue.
On Thu, Nov 25, 2021 at 6:57 AM Dave Taht <dave.taht@gmail.com> wrote: > > On Thu, Nov 25, 2021 at 6:46 AM Tim Chown <Tim.Chown@jisc.ac.uk> 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 <dave.taht@gmail.com> wrote: > > > > > > yes please. > > > > > > On Thu, Nov 25, 2021 at 3:36 AM Tim Chown <Tim.Chown@jisc.ac.uk> wrote: > > >> > > >>> On 23 Nov 2021, at 16:41, Dave Taht <dave.taht@gmail.com> wrote: > > >>> > > >>> On Tue, Nov 23, 2021 at 8:31 AM Tim Chown <Tim.Chown@jisc.ac.uk> wrote: > > >>>> > > >>>> Hi Dave, > > >>>> > > >>>>> On 23 Nov 2021, at 16:09, Dave Taht <dave.taht@gmail.com> 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 <ipv6-wg@ripe.net> wrote: > > >>>>>> > > >>>>>> Hi Eric, > > >>>>>> > > >>>>>> > > >>>>>> Many thanks for your comments, we’ve updated the ‘living draft’ at > > >>>>>> https://docs.google.com/document/d/10HsfHDOIhUPIvGk9WP0azJiIsMVzQ49RsqWfnbNt... > > >>>>>> And attached as PDF. > > >>>>>> > > >>>>>> In-line... > > >>>>>> > > >>>>>>> On 5 Nov 2021, at 07:52, Eric Vyncke (evyncke) <evyncke@cisco.com> 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
-- 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
On 25 Nov 2021, at 14:57, Dave Taht <dave.taht@gmail.com> wrote:
On Thu, Nov 25, 2021 at 6:46 AM Tim Chown <Tim.Chown@jisc.ac.uk> 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. :)
Well, perhaps the first step here is the mention of AQM for L3 switches and routers. It sounds like CPEs too, before hosts. Tim
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 <dave.taht@gmail.com> wrote:
yes please.
On Thu, Nov 25, 2021 at 3:36 AM Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
On 23 Nov 2021, at 16:41, Dave Taht <dave.taht@gmail.com> wrote:
On Tue, Nov 23, 2021 at 8:31 AM Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
Hi Dave,
> On 23 Nov 2021, at 16:09, Dave Taht <dave.taht@gmail.com> 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 <ipv6-wg@ripe.net> wrote: >> >> Hi Eric, >> >> >> Many thanks for your comments, we’ve updated the ‘living draft’ at >> https://docs.google.com/document/d/10HsfHDOIhUPIvGk9WP0azJiIsMVzQ49RsqWfnbNt... >> And attached as PDF. >> >> In-line... >> >>> On 5 Nov 2021, at 07:52, Eric Vyncke (evyncke) <evyncke@cisco.com> 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
on cpe, especially! Better bandwidth for "conferencing and gaming" is an option now found on eero and google's products, but would be better if it could be configured remotely. Broadband forum has published some TR-XXX specs that might be worth referencing, but I don't keep those numbers in my head. Over here is what one user just did by applying sch_cake to his virgin media docsis 1gbit/50mbit service: https://forums.overclockers.co.uk/posts/35236152/ The before is posted a few pages before that.
On 25/11/2021 16:20, Tim Chown wrote:
On 25 Nov 2021, at 14:57, Dave Taht <dave.taht@gmail.com> wrote:
On Thu, Nov 25, 2021 at 6:46 AM Tim Chown <Tim.Chown@jisc.ac.uk> 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. :)
Well, perhaps the first step here is the mention of AQM for L3 switches and routers.
It sounds like CPEs too, before hosts.
I thought that in RIPE554 (and -bis) we are defining IPv6 requrements :) I would suggest to limit this particular discussion in just refreshing RIPE554, reach the consensus, publish it, open a champagne, celebrate and next morning start working on expanded version where we can discuss all the suggestions for new types of "devices" and all this new additions. Cheers, Jan
On 25 Nov 2021, at 20:01, Jan Zorz - Go6 <jan@go6.si> wrote:
On 25/11/2021 16:20, Tim Chown wrote:
On 25 Nov 2021, at 14:57, Dave Taht <dave.taht@gmail.com> wrote:
On Thu, Nov 25, 2021 at 6:46 AM Tim Chown <Tim.Chown@jisc.ac.uk> 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. :)
Well, perhaps the first step here is the mention of AQM for L3 switches and routers.
It sounds like CPEs too, before hosts.
I thought that in RIPE554 (and -bis) we are defining IPv6 requrements :)
I would suggest to limit this particular discussion in just refreshing RIPE554, reach the consensus, publish it, open a champagne, celebrate and next morning start working on expanded version where we can discuss all the suggestions for new types of "devices" and all this new additions.
We do however have QoS requirements in RIPE554, e.g. in 4.4 and 4.5 there is Mandatory support for QoS [RFC2474, RFC3140] and two Optional items (QOS) Assured Forwarding [RFC2597] (QOS) Expedited Forwarding [RFC3246], So adding (QOS) Active Queue Management support [RFC7567] as optional is not a stretch, for 4.4 or for 4.7. That’s what the current snapshot includes. Tim
On 26/11/2021 10:55, Tim Chown via ipv6-wg wrote:
We do however have QoS requirements in RIPE554, e.g. in 4.4 and 4.5 there is Mandatory support for QoS [RFC2474, RFC3140] and two Optional items (QOS) Assured Forwarding [RFC2597] (QOS) Expedited Forwarding [RFC3246], So adding (QOS) Active Queue Management support [RFC7567] as optional is not a stretch, for 4.4 or for 4.7.
So let's make it consistent, but then I would stop adding stuff and save this for next version. Does this make sense? Cheers, Jan
On 26 Nov 2021, at 11:48, Jan Zorz - Go6 <jan@go6.si> wrote:
On 26/11/2021 10:55, Tim Chown via ipv6-wg wrote:
We do however have QoS requirements in RIPE554, e.g. in 4.4 and 4.5 there is Mandatory support for QoS [RFC2474, RFC3140] and two Optional items (QOS) Assured Forwarding [RFC2597] (QOS) Expedited Forwarding [RFC3246], So adding (QOS) Active Queue Management support [RFC7567] as optional is not a stretch, for 4.4 or for 4.7.
So let's make it consistent, but then I would stop adding stuff and save this for next version.
Does this make sense?
Yes, that’s what we agreed to do - the only thing that needs editing is the acknowledgements, unless new issues are raised before the 3rd Dec. Tim
Thank you, Tim, for the return and the updated doc. It is obviously up to the authors to decide what is out of scope or not but strongly suggest to mention explicitly the VM/containers/mobile devices as being out-of-scope in the document. Having multiple interfaces can also impact the enterprise network though -éric From: Tim Chown <Tim.Chown@jisc.ac.uk> Date: Tuesday, 23 November 2021 at 16:38 To: Eric Vyncke <evyncke@cisco.com> Cc: "ipv6-wg@ripe.net" <ipv6-wg@ripe.net>, Sander Steffann <sander@steffann.nl>, Jan Zorz <jan@go6.si>, Merike Kaeo <merike@doubleshotsecurity.com>, Timothy Winters <tim@qacafe.com> Subject: Re: [ipv6-wg] Latest draft for RIPE554-bis Hi Eric, Many thanks for your comments, we’ve updated the ‘living draft’ at https://docs.google.com/document/d/10HsfHDOIhUPIvGk9WP0azJiIsMVzQ49RsqWfnbNtceI/edit#<https://docs.google.com/document/d/10HsfHDOIhUPIvGk9WP0azJiIsMVzQ49RsqWfnbNtceI/edit> And attached as PDF. In-line...
On 5 Nov 2021, at 07:52, Eric Vyncke (evyncke) <evyncke@cisco.com> 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
Hi Éric,
Having multiple interfaces can also impact the enterprise network though
I think this is an important enterprise requirement for any host. Cheers, Sander
On 24 Nov 2021, at 14:57, Sander Steffann <sander@steffann.nl> wrote:
Hi Éric,
Having multiple interfaces can also impact the enterprise network though
I think this is an important enterprise requirement for any host.
True, it’s not mobile device specific. How should we phrase that, and what might be IPv6-specific about it? Tim
Hi Tim, all, I've reviewed the latest version of the document and in general I agree. However, today is unacceptable that a CPE doesn't support IPv6-only + IPv4aaS, so RFC8585 must be a must in this type of document. I think there must be a clear statement on that. Regards, Jordi @jordipalet ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
Hi Jordi, I see you also brought up on the v6ops list. Let's see what the operator community has to say about this topic. I'm not opposed to changing this, but I'm also aware that's CPEs rarely support all the mechanisms listed in that RFC. ~Tim On Wed, Nov 24, 2021 at 11:58 AM JORDI PALET MARTINEZ via ipv6-wg < ipv6-wg@ripe.net> wrote:
Hi Tim, all,
I've reviewed the latest version of the document and in general I agree. However, today is unacceptable that a CPE doesn't support IPv6-only + IPv4aaS, so RFC8585 must be a must in this type of document.
I think there must be a clear statement on that.
Regards, Jordi @jordipalet
********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company
This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
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
Hi Tim, I understand that even if in the IETF we decide not to go for that, as we know that the participation in IETF from operators is not as good as we wish, we as a different community can have a totally different perspective. If we don’t want to have full support of the RFC8585, at least we must mandate the 464XLAT section. The reason is clear: it is the only possible way in mobile, and if you want to support “hybrid CPEs” (those that provide for example a GPON WAN or Ethernet WAN + USB dongle for 3-5G) the easier way is to provide 464XLAT. It is also a matter of subscriber numbers in one technology vs all the others together. Regards, Jordi @jordipalet El 24/11/21 18:26, "ipv6-wg en nombre de Timothy Winters" <ipv6-wg-bounces@ripe.net en nombre de tim@qacafe.com> escribió: Hi Jordi, I see you also brought up on the v6ops list. Let's see what the operator community has to say about this topic. I'm not opposed to changing this, but I'm also aware that's CPEs rarely support all the mechanisms listed in that RFC. ~Tim On Wed, Nov 24, 2021 at 11:58 AM JORDI PALET MARTINEZ via ipv6-wg <ipv6-wg@ripe.net> wrote: Hi Tim, all, I've reviewed the latest version of the document and in general I agree. However, today is unacceptable that a CPE doesn't support IPv6-only + IPv4aaS, so RFC8585 must be a must in this type of document. I think there must be a clear statement on that. Regards, Jordi @jordipalet ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. 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 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 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
Hi Jordi, Most of the testing requests that we have received for wired CPEs lately have been MAP based. We are aware of a couple ISPs considering XLAT464, but I'm not aware of it being used in production. For wireless XLAT464 makes sense, even for fixed wireless. ~Tim On Wed, Nov 24, 2021 at 12:31 PM JORDI PALET MARTINEZ via ipv6-wg < ipv6-wg@ripe.net> wrote:
Hi Tim,
I understand that even if in the IETF we decide not to go for that, as we know that the participation in IETF from operators is not as good as we wish, we as a different community can have a totally different perspective.
If we don’t want to have full support of the RFC8585, at least we must mandate the 464XLAT section. The reason is clear: it is the only possible way in mobile, and if you want to support “hybrid CPEs” (those that provide for example a GPON WAN or Ethernet WAN + USB dongle for 3-5G) the easier way is to provide 464XLAT. It is also a matter of subscriber numbers in one technology vs all the others together.
Regards,
Jordi
@jordipalet
El 24/11/21 18:26, "ipv6-wg en nombre de Timothy Winters" < ipv6-wg-bounces@ripe.net en nombre de tim@qacafe.com> escribió:
Hi Jordi,
I see you also brought up on the v6ops list. Let's see what the operator community has to say about this topic.
I'm not opposed to changing this, but I'm also aware that's CPEs rarely support all the mechanisms listed in that RFC.
~Tim
On Wed, Nov 24, 2021 at 11:58 AM JORDI PALET MARTINEZ via ipv6-wg < ipv6-wg@ripe.net> wrote:
Hi Tim, all,
I've reviewed the latest version of the document and in general I agree. However, today is unacceptable that a CPE doesn't support IPv6-only + IPv4aaS, so RFC8585 must be a must in this type of document.
I think there must be a clear statement on that.
Regards, Jordi @jordipalet
********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company
This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
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
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
********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company
This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
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
On 24 Nov 2021, at 14:57, Sander Steffann <sander@steffann.nl> wrote:
Hi Éric,
Having multiple interfaces can also impact the enterprise network though
I think this is an important enterprise requirement for any host.
I have marked this as a question in the google doc. Tim
I have added a new section 3.2 for what is out of scope. Tim
On 23 Nov 2021, at 17:07, Eric Vyncke (evyncke) <evyncke@cisco.com> wrote:
Thank you, Tim, for the return and the updated doc.
It is obviously up to the authors to decide what is out of scope or not but strongly suggest to mention explicitly the VM/containers/mobile devices as being out-of-scope in the document.
Having multiple interfaces can also impact the enterprise network though
-éric
From: Tim Chown <Tim.Chown@jisc.ac.uk> Date: Tuesday, 23 November 2021 at 16:38 To: Eric Vyncke <evyncke@cisco.com> Cc: "ipv6-wg@ripe.net" <ipv6-wg@ripe.net>, Sander Steffann <sander@steffann.nl>, Jan Zorz <jan@go6.si>, Merike Kaeo <merike@doubleshotsecurity.com>, Timothy Winters <tim@qacafe.com> Subject: Re: [ipv6-wg] Latest draft for RIPE554-bis
Hi Eric,
Many thanks for your comments, we’ve updated the ‘living draft’ at https://docs.google.com/document/d/10HsfHDOIhUPIvGk9WP0azJiIsMVzQ49RsqWfnbNt... And attached as PDF.
In-line...
On 5 Nov 2021, at 07:52, Eric Vyncke (evyncke) <evyncke@cisco.com> 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
participants (7)
-
Dave Taht -
Eric Vyncke (evyncke) -
Jan Zorz - Go6 -
JORDI PALET MARTINEZ -
Sander Steffann -
Tim Chown -
Timothy Winters