Re: [IPv6] next steps for draft-ietf-6man-ipv6-over-wireless

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Lorenzo:

The document changed at adoption time so it is not the one that you reviewed anymore.

>  First: it's much too long and has way too much content in it to be a "framework", which is what it calls itself at the moment

Now it is a 4-in-1. It has problem statement (enlarged way beyond wireless), architecture (how things work with registration), framework (which RFCs do what to achieve this architecture), and applicability (to Wi-Fi, though it applies to BLE as well as .11, .15.1 and .15.4 meshes). Each of these has a specific section, respectively 3, 4, 5, and 6. I see why you see it “tries to do too many things”. At least it is structured. f the group agrees with you that there’s too much content for one draft, I can see A) we split in up to 4 drafts and B) we place the problem statement and applicability in appendix. I’m not sure either A or B will help the reader and IESG a lot though. All in 1 has the advantage of consistency. What would you do?

> This document also really needs to decide whether it's defining a framework and changing the standards, or not.

This was clarified in the WG doc with 1) the track (info) and 2) the title (Architecture and Framework). The document is not changing standards. It is recommending to use the existing standards and I-Ds listed in the framework more broadly, that is make the framework available on any stack, and to obviously to build the missing standards if some gaps are found implementing the framework. Note that the framework includes the prefix registration work, and lists draft-collink-v6ops-ent64pd as one of the reasons why it is needed, so the routers know which prefix was delegated to the host and are instructed to route that prefix to that host without proprietary kludge in the DHCP relay.

"All IP Links are abstracted as Point-to-Point" is not the status of today. It is what would happen if the architecture was fully implemented. Typically there would be a router in each AP, doing proxy-ND or SGP on the distribution network (the Ethernet backbone). Note that proxy-ND (called proxy ARP in the spec) is already mandated by IEEE std 802.11. And then each STA would establish a logical IPv6 link to that AP, and register its address so the AP can proxy or redistribute without additional proprietary kludge like ND/DHCP snooping that we have today.

>  Also, please replace "ND classic" with "Neighbor Discovery" everywhere. There is no such thing as "ND classic". There is only ND.

There’s RFC 4861-4862 on the one hand and RFC 6775-8505 on the other. They are all ND. This document needs a term that points on the former group, and one that points of the registration extensions. So the document defines ND-Classic for the purpose of naming the former. The alternate would be to change ND classic to RFC 4861-RFC 4862 throughout. What’s best for the reader?

All the best,

Pascal



From: ipv6 <[e-mail]> On Behalf Of Lorenzo Colitti
Sent: Wednesday, May 31, 2023 5:58 AM
To: Pascal Thubert (pthubert) <pthubert=[e-mail]>
Cc: IPv6 WG ([e-mail]) <[e-mail]>
Subject: Re: [IPv6] next steps for draft-ietf-6man-ipv6-over-wireless

I gave this feedback already at adoption call time, and I think it needs to be addressed before we can talk about publication.

tl;dr: this document is too rambling and vague, and tries to do too many things, to be published in anything like its current form, or even to be productively reviewed by the WG.

First: it's much too long and has way too much content in it to be a "framework", which is what it calls itself at the moment. Last I looked at the draft (before adoption) it was basically a rambling document that covered the history of technologies such as ND, DAD, and various wireless link layers, and discussed some of the design tradeoffs. That may be OK for a history document (assuming we want to publish one), but it's not OK for a framework or for any kind of standard. A standard must have a clear problem statement and must discuss a clear solution. One important reason why it cannot be too long is that in a standard, correctness is paramount, and if the document is too long it's very difficult for WG participants to review it and make it correct. If we want this to be a standard, or lead to the development of standards later on, then it must be short enough to reasonably review.

This document also really needs to decide whether it's defining a framework and changing the standards, or not. To provide just one example: are statements such as "the IPv6 routers that serve a Subnet must form a connected dominating set such that every host in the Subnet is connected to at least one router and the routers are connected to one another directly" normative? If they are, then what does that mean in practice to protocols, implementations, and bits in the wire? We cannot publish an informational draft that vaguely defines a "framework" unless we have actual standards and protocol definitions that explain how things work. The reason we cannot do that is that when we try to encode the framework into actual standards, we may very well find out that the framework *cannot* actually be implemented as is.

Another issue is that the draft presents as facts statements that are vague/handwavy or are merely opinions instead of facts, or sometimes just incorrect. For example, "All IP Links are abstracted as Point-to-Point" might sound good in theory but in practice most existing wifi networks rely on broadcast/multicast and many applications will fall over without it. But again, there are loads of these statements, and while the document remains so long, it's hard to even review all of it.

Also, please replace "ND classic" with "Neighbor Discovery" everywhere. There is no such thing as "ND classic". There is only ND.

On Wed, May 24, 2023 at 3:52 PM Pascal Thubert (pthubert) <pthubert=[e-mail]<mailto:[e-mail]>> wrote:
Dear WG:

We adopted that draft to publish it as informational; it is at the same time a state of the art, a problem statement, and an applicability statement.

The issues are clear and present, see also draft-ietf-v6ops-nd-considerations. We face customer situations where clients are not properly served because ND snooping fails to locate them all with a painful regularity. This impacts all sorts of situations, from wireless to fabrics / EVPN.

Note that This is indeed very related to the SLAAC operation and IPv4 is mostly immune. Meaning that the IPv6 experience is of more broadcasts and less reliability.

In order to progress in solving the issues raised, it makes sense to publish soon and move on. The draft has been progressing as an individual submission for a long time and it is mostly complete, IMHO. So my intent is to ask for WGLC sooner than later. To get there, reviews would be highly appreciated.

Many thanks in advance : )

Pascal
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]<mailto:[e-mail]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------