You are here: Home > Participate > Join a Discussion > RIPE Forum
RIPE Forum v1.4.1

IPv6 Working Group

Threaded
Collapse

[ipv6-wg] Latest draft for RIPE554-bis

User Image

Tim Chown

2021-11-02 16:04:57 CET

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
User Image

Raymond Jetten

2021-11-03 09:16:28 CET

Hi,

First of all thanks to all who participated in the update of this document !
Its only a few weeks before the RIPE 83 virtual meeting, so I hope most of the discussion will be here on the list before the meeting.
During RIPE 83  we have only a 45 minute slot altogether so we don't have unlimited time there to discuss these.

I hope we have enough consensus to have this published during the meeting, so please show your support, or ask, comment etc already now.

Rgds,

Ray

IPv6 wg co chair



-----Original Message-----
From: ipv6-wg <ipv6-wg-bounces _at_ ripe _dot_ net> On Behalf Of Tim Chown via ipv6-wg
Sent: tiistai 2. marraskuuta 2021 17.05
To: ipv6-wg _at_ ripe _dot_ net
Cc: Sander Steffann <sander _at_ steffann _dot_ nl>; Jan Zorz - Go6 <jan _at_ go6 _dot_ si>; Merike Kaeo <merike _at_ doubleshotsecurity _dot_ com>
Subject: [ipv6-wg] Latest draft for RIPE554-bis

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

User Image

Tim Chown

2021-11-03 10:42:58 CET

Thanks Ray.

I think it’s pretty clear this update is needed; the current 554 is 10 years old, and much of what’s in it has itself been updated with revised specs, and of course many new RFCs have been published since.

What’s really needed is a good look at the RFCs included as mandatory and optional for each class of equipment.
Do these seems sensible?
Are there any gaps?
Have we missed something that’s included for hosts but not (say) routers?
etc.

We’ve had some feedback on that, which has made this new version better - thanks to those who contacted us.

I’d also point out that as explained at the previous RIPE meeting we’ve not expanded the scope of the document, so the classes of equipment are the same (and we folded mobile devices into hosts, so we’re not considering the cellular requirements) and topics such as segment routing are not included.  We felt it important on focusing on getting a bis out, and not delaying that by jumping into new ratholes.  Further documents could follow though.

Tim

> On 3 Nov 2021, at 08:16, Jetten Raymond <raymond.jetten _at_ elisa _dot_ fi> wrote:
> 
> 
> Hi,
> 
> First of all thanks to all who participated in the update of this document !
> Its only a few weeks before the RIPE 83 virtual meeting, so I hope most of the discussion will be here on the list before the meeting.
> During RIPE 83  we have only a 45 minute slot altogether so we don't have unlimited time there to discuss these.
> 
> I hope we have enough consensus to have this published during the meeting, so please show your support, or ask, comment etc already now.
> 
> Rgds,
> 
> Ray
> 
> IPv6 wg co chair
> 
> 
> 
> -----Original Message-----
> From: ipv6-wg <ipv6-wg-bounces _at_ ripe _dot_ net> On Behalf Of Tim Chown via ipv6-wg
> Sent: tiistai 2. marraskuuta 2021 17.05
> To: ipv6-wg _at_ ripe _dot_ net
> Cc: Sander Steffann <sander _at_ steffann _dot_ nl>; Jan Zorz - Go6 <jan _at_ go6 _dot_ si>; Merike Kaeo <merike _at_ doubleshotsecurity _dot_ com>
> Subject: [ipv6-wg] Latest draft for RIPE554-bis
> 
> 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

User Image

Éric Vyncke

2021-11-05 08:52:16 CET

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 _at_ ripe _dot_ net on behalf of ipv6-wg _at_ ripe _dot_ 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

User Image

Tim Chown

2021-11-23 16:38:07 CET

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) <evyncke _at_ cisco _dot_ 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


Dave Taht

2021-11-23 17:09:45 CET

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 _at_ ripe _dot_ net> 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) <evyncke _at_ cisco _dot_ 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

User Image

Tim Chown

2021-11-23 17:31:54 CET

Hi Dave,

> On 23 Nov 2021, at 16:09, Dave Taht <dave.taht _at_ gmail _dot_ 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?

Tim
> 
> On Tue, Nov 23, 2021 at 7:38 AM Tim Chown via ipv6-wg <ipv6-wg _at_ ripe _dot_ net> 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) <evyncke _at_ cisco _dot_ 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

Dave Taht

2021-11-23 17:41:04 CET

On Tue, Nov 23, 2021 at 8:31 AM Tim Chown <Tim.Chown _at_ jisc.ac _dot_ uk> wrote:
>
> Hi Dave,
>
> > On 23 Nov 2021, at 16:09, Dave Taht <dave.taht _at_ gmail _dot_ 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.

> Tim
> >
> > On Tue, Nov 23, 2021 at 7:38 AM Tim Chown via ipv6-wg <ipv6-wg _at_ ripe _dot_ net> 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) <evyncke _at_ cisco _dot_ 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

User Image

Tim Chown

2021-11-23 17:46:02 CET

Hi,

> On 23 Nov 2021, at 16:41, Dave Taht <dave.taht _at_ gmail _dot_ com> wrote:
> 
> On Tue, Nov 23, 2021 at 8:31 AM Tim Chown <Tim.Chown _at_ jisc.ac _dot_ uk> wrote:
>> 
>> Hi Dave,
>> 
>>> On 23 Nov 2021, at 16:09, Dave Taht <dave.taht _at_ gmail _dot_ 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.

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 _at_ ripe _dot_ net> 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) <evyncke _at_ cisco _dot_ 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

User Image

Éric Vyncke

2021-11-23 18:07:54 CET

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 _at_ jisc.ac _dot_ uk>
Date: Tuesday, 23 November 2021 at 16:38
To: Eric Vyncke <evyncke _at_ cisco _dot_ com>
Cc: "ipv6-wg _at_ ripe _dot_ net" <ipv6-wg _at_ ripe _dot_ net>, Sander Steffann <sander _at_ steffann _dot_ nl>, Jan Zorz <jan _at_ go6 _dot_ si>, Merike Kaeo <merike _at_ doubleshotsecurity _dot_ com>, Timothy Winters <tim _at_ qacafe _dot_ 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#
And attached as PDF.

In-line...

> On 5 Nov 2021, at 07:52, Eric Vyncke (evyncke) <evyncke _at_ cisco _dot_ 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

User Image

Sander Steffann

2021-11-24 15:57:51 CET

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


User Image

Tim Chown

2021-11-24 16:00:48 CET

> On 24 Nov 2021, at 14:57, Sander Steffann <sander _at_ steffann _dot_ 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

User Image

Jordi Palet Martinez

2021-11-24 17:58:25 CET

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.




Timothy Winters

2021-11-24 18:26:07 CET

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 _at_ ripe _dot_ 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
>

Timothy Winters

2021-11-24 19:11:33 CET

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 _at_ ripe _dot_ 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 _at_ ripe _dot_ net en nombre de tim _at_ qacafe _dot_ 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 _at_ ripe _dot_ 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
>
User Image

Tim Chown

2021-11-25 12:26:33 CET

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 _at_ cisco _dot_ 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 _at_ jisc.ac _dot_ uk>
> Date: Tuesday, 23 November 2021 at 16:38
> To: Eric Vyncke <evyncke _at_ cisco _dot_ com>
> Cc: "ipv6-wg _at_ ripe _dot_ net" <ipv6-wg _at_ ripe _dot_ net>, Sander Steffann <sander _at_ steffann _dot_ nl>, Jan Zorz <jan _at_ go6 _dot_ si>, Merike Kaeo <merike _at_ doubleshotsecurity _dot_ com>, Timothy Winters <tim _at_ qacafe _dot_ 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#
> And attached as PDF.
> 
> In-line...
> 
> > On 5 Nov 2021, at 07:52, Eric Vyncke (evyncke) <evyncke _at_ cisco _dot_ 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

User Image

Tim Chown

2021-11-25 12:29:55 CET

> On 24 Nov 2021, at 14:57, Sander Steffann <sander _at_ steffann _dot_ 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

User Image

Tim Chown

2021-11-25 12:36:28 CET

> On 23 Nov 2021, at 16:41, Dave Taht <dave.taht _at_ gmail _dot_ com> wrote:
> 
> On Tue, Nov 23, 2021 at 8:31 AM Tim Chown <Tim.Chown _at_ jisc.ac _dot_ uk> wrote:
>> 
>> Hi Dave,
>> 
>>> On 23 Nov 2021, at 16:09, Dave Taht <dave.taht _at_ gmail _dot_ 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 _at_ ripe _dot_ net> 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) <evyncke _at_ cisco _dot_ 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

Dave Taht

2021-11-25 15:43:27 CET

yes please.

On Thu, Nov 25, 2021 at 3:36 AM Tim Chown <Tim.Chown _at_ jisc.ac _dot_ uk> wrote:
>
> > On 23 Nov 2021, at 16:41, Dave Taht <dave.taht _at_ gmail _dot_ com> wrote:
> >
> > On Tue, Nov 23, 2021 at 8:31 AM Tim Chown <Tim.Chown _at_ jisc.ac _dot_ uk> wrote:
> >>
> >> Hi Dave,
> >>
> >>> On 23 Nov 2021, at 16:09, Dave Taht <dave.taht _at_ gmail _dot_ 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 _at_ ripe _dot_ net> 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) <evyncke _at_ cisco _dot_ 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

User Image

Tim Chown

2021-11-25 15:46:05 CET

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 _at_ gmail _dot_ com> wrote:
> 
> yes please.
> 
> On Thu, Nov 25, 2021 at 3:36 AM Tim Chown <Tim.Chown _at_ jisc.ac _dot_ uk> wrote:
>> 
>>> On 23 Nov 2021, at 16:41, Dave Taht <dave.taht _at_ gmail _dot_ com> wrote:
>>> 
>>> On Tue, Nov 23, 2021 at 8:31 AM Tim Chown <Tim.Chown _at_ jisc.ac _dot_ uk> wrote:
>>>> 
>>>> Hi Dave,
>>>> 
>>>>> On 23 Nov 2021, at 16:09, Dave Taht <dave.taht _at_ gmail _dot_ 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 _at_ ripe _dot_ net> 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) <evyncke _at_ cisco _dot_ 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

Dave Taht

2021-11-25 15:57:50 CET

On Thu, Nov 25, 2021 at 6:46 AM Tim Chown <Tim.Chown _at_ jisc.ac _dot_ 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 _at_ gmail _dot_ com> wrote:
> >
> > yes please.
> >
> > On Thu, Nov 25, 2021 at 3:36 AM Tim Chown <Tim.Chown _at_ jisc.ac _dot_ uk> wrote:
> >>
> >>> On 23 Nov 2021, at 16:41, Dave Taht <dave.taht _at_ gmail _dot_ com> wrote:
> >>>
> >>> On Tue, Nov 23, 2021 at 8:31 AM Tim Chown <Tim.Chown _at_ jisc.ac _dot_ uk> wrote:
> >>>>
> >>>> Hi Dave,
> >>>>
> >>>>> On 23 Nov 2021, at 16:09, Dave Taht <dave.taht _at_ gmail _dot_ 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 _at_ ripe _dot_ net> 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) <evyncke _at_ cisco _dot_ 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

Dave Taht

2021-11-25 16:16:27 CET

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 _at_ gmail _dot_ com> wrote:
>
> On Thu, Nov 25, 2021 at 6:46 AM Tim Chown <Tim.Chown _at_ jisc.ac _dot_ 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 _at_ gmail _dot_ com> wrote:
> > >
> > > yes please.
> > >
> > > On Thu, Nov 25, 2021 at 3:36 AM Tim Chown <Tim.Chown _at_ jisc.ac _dot_ uk> wrote:
> > >>
> > >>> On 23 Nov 2021, at 16:41, Dave Taht <dave.taht _at_ gmail _dot_ com> wrote:
> > >>>
> > >>> On Tue, Nov 23, 2021 at 8:31 AM Tim Chown <Tim.Chown _at_ jisc.ac _dot_ uk> wrote:
> > >>>>
> > >>>> Hi Dave,
> > >>>>
> > >>>>> On 23 Nov 2021, at 16:09, Dave Taht <dave.taht _at_ gmail _dot_ 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 _at_ ripe _dot_ net> 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) <evyncke _at_ cisco _dot_ 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

User Image

Tim Chown

2021-11-25 16:20:05 CET

> On 25 Nov 2021, at 14:57, Dave Taht <dave.taht _at_ gmail _dot_ com> wrote:
> 
> On Thu, Nov 25, 2021 at 6:46 AM Tim Chown <Tim.Chown _at_ jisc.ac _dot_ 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 _at_ gmail _dot_ com> wrote:
>>> 
>>> yes please.
>>> 
>>> On Thu, Nov 25, 2021 at 3:36 AM Tim Chown <Tim.Chown _at_ jisc.ac _dot_ uk> wrote:
>>>> 
>>>>> On 23 Nov 2021, at 16:41, Dave Taht <dave.taht _at_ gmail _dot_ com> wrote:
>>>>> 
>>>>> On Tue, Nov 23, 2021 at 8:31 AM Tim Chown <Tim.Chown _at_ jisc.ac _dot_ uk> wrote:
>>>>>> 
>>>>>> Hi Dave,
>>>>>> 
>>>>>>> On 23 Nov 2021, at 16:09, Dave Taht <dave.taht _at_ gmail _dot_ 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 _at_ ripe _dot_ net> 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) <evyncke _at_ cisco _dot_ 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

Dave Taht

2021-11-25 17:03:17 CET

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.

User Image

Jan Zorz

2021-11-25 21:01:22 CET

On 25/11/2021 16:20, Tim Chown wrote:
>> On 25 Nov 2021, at 14:57, Dave Taht <dave.taht _at_ gmail _dot_ com> wrote:
>>
>> On Thu, Nov 25, 2021 at 6:46 AM Tim Chown <Tim.Chown _at_ jisc.ac _dot_ 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


User Image

Éric Vyncke

2021-11-26 09:16:36 CET

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 _at_ gmail _dot_ 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 _at_ gmail _dot_ com> wrote:
    >
    > On Thu, Nov 25, 2021 at 6:46 AM Tim Chown <Tim.Chown _at_ jisc.ac _dot_ 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 _at_ gmail _dot_ com> wrote:
    > > >
    > > > yes please.
    > > >
    > > > On Thu, Nov 25, 2021 at 3:36 AM Tim Chown <Tim.Chown _at_ jisc.ac _dot_ uk> wrote:
    > > >>
    > > >>> On 23 Nov 2021, at 16:41, Dave Taht <dave.taht _at_ gmail _dot_ com> wrote:
    > > >>>
    > > >>> On Tue, Nov 23, 2021 at 8:31 AM Tim Chown <Tim.Chown _at_ jisc.ac _dot_ uk> wrote:
    > > >>>>
    > > >>>> Hi Dave,
    > > >>>>
    > > >>>>> On 23 Nov 2021, at 16:09, Dave Taht <dave.taht _at_ gmail _dot_ 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 _at_ ripe _dot_ net> 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) <evyncke _at_ cisco _dot_ 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

User Image

Tim Chown

2021-11-26 10:55:25 CET

> On 25 Nov 2021, at 20:01, Jan Zorz - Go6 <jan _at_ go6 _dot_ si> wrote:
> 
> On 25/11/2021 16:20, Tim Chown wrote:
>>> On 25 Nov 2021, at 14:57, Dave Taht <dave.taht _at_ gmail _dot_ com> wrote:
>>> 
>>> On Thu, Nov 25, 2021 at 6:46 AM Tim Chown <Tim.Chown _at_ jisc.ac _dot_ 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
User Image

Jan Zorz

2021-11-26 12:48:48 CET

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



User Image

Tim Chown

2021-11-26 12:58:22 CET

> On 26 Nov 2021, at 11:48, Jan Zorz - Go6 <jan _at_ go6 _dot_ 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

Dave Taht

2021-11-26 15:46:32 CET

On Fri, Nov 26, 2021 at 12:16 AM Eric Vyncke (evyncke)
<evyncke _at_ cisco _dot_ 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/html/7h0cpt4lqflt1k1pfdpth18at9/sc_ug_html/index.html#page/sc_ug%2Fqos.html%23

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 _at_ gmail _dot_ 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 _at_ gmail _dot_ com> wrote:
>     >
>     > On Thu, Nov 25, 2021 at 6:46 AM Tim Chown <Tim.Chown _at_ jisc.ac _dot_ 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 _at_ gmail _dot_ com> wrote:
>     > > >
>     > > > yes please.
>     > > >
>     > > > On Thu, Nov 25, 2021 at 3:36 AM Tim Chown <Tim.Chown _at_ jisc.ac _dot_ uk> wrote:
>     > > >>
>     > > >>> On 23 Nov 2021, at 16:41, Dave Taht <dave.taht _at_ gmail _dot_ com> wrote:
>     > > >>>
>     > > >>> On Tue, Nov 23, 2021 at 8:31 AM Tim Chown <Tim.Chown _at_ jisc.ac _dot_ uk> wrote:
>     > > >>>>
>     > > >>>> Hi Dave,
>     > > >>>>
>     > > >>>>> On 23 Nov 2021, at 16:09, Dave Taht <dave.taht _at_ gmail _dot_ 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 _at_ ripe _dot_ net> 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) <evyncke _at_ cisco _dot_ 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