Re: [IPv6] Architectural comments on draft-ietf-6man-ipv6-over-wireless-

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

Hello Ted

My message did not land as intended.
The intent is this:

I have a large building or campus. I want to enter anywhere and obtain an address that I can use throughout the campus without renumbering when I go to the next building/ level/room.

Otoh I want that bonjour always finds the nearest printer and that printer is in the same room as me or in a closeby room. Certainly not anywhere in the campus.

For the latter the admin sets the broadcast domain to be limited to a small area in the building.

For the former your subnet must still be reachable in the room you’re in. So the desired range / coverage of the subnet does not match the physical space covered by the broadcast domain you’re in.

From there you have to choices. 1)  Tunnel selected packets like MIPv6 does to where you entered the building. Or 3) route. Obviously since the use case is a real customer situation we implemented 1) and that’s an awful hack.

The architecture provides a model that allows decoupling the broadcast domain that you link local address will reach from the subnet where your address will be topologically correct and reachable.

Regards,

Pascal

Le 27 juil. 2023 à 13:40, Ted Lemon <[e-mail]> a écrit :


The question that's been making me scratch my head as I listen to this presentation is, "for whom is this proposal a solution to their problem?" Like, not "people with this class of network," but rather "who specifically needs this on their actual physical network?"

I found the mDNS locality argument not at all persuasive. The idea that we would solve an application problem at Layer 3 seems like a terrible idea.
In any case, I have the same impression you do: this is really complicated and it's hard for me to imagine that it's actually going to improve things. Why do we still have giant (multi-thousand-host) broadcast domains? What is the problem that is being solved by making broadcast domains so large?

On Thu, Jul 27, 2023 at 1:30 PM Lorenzo Colitti <lorenzo=[e-mail]<mailto:[e-mail]>> wrote:
I mentioned this v6ops at the mic, but never sent it here, so...

tl;dr - While this architecture may be a slightly better fit for wireless links, it does so at the cost of greater complexity, reduced resilience, reduction in the ability for hosts to autonomously form addresses, and the loss of an abstraction that is useful for application developers. I also don't think that the scalability and power improvements are necessary in most networks.

======

More in detail: while the proposed architecture is a good fit for low power networks (which is where it originates from), I don't think the new architecture is a good trade-off for general purpose networks like 802.11, for several reasons.

First: the draft is very focused on ND, but ND is just one of the protocols that rely on the broadcast link abstraction. It's arguably the _most important_ protocol, because it is required for all other communications, but it's definitely not the only protocol, and it's most certainly not the protocol that sends the most packets or bytes. For example, MDNS is much chattier.

The reason we have a broadcast abstraction over links like 802.11 wifi is that it's a _useful_ abstraction. Developers of applications like MDNS (and many other discovery applications) benefit greatly from a simple abstraction. And even if we change the architecture of ND, the link layer will still need to provide this useful abstraction.

Second: the current architecture has several good properties that the proposed architecture lacks, and I think it's arguably a good trade-off for most general purpose use cases. For example, it is robust to state loss, because any entity that crashes will trivially recover state without needing a complex recovery procedure. And it allows nodes to form their own addresses without requesting them from the network. This is recommended by RFC 7934, which also documents several cases where hosts were able to autonomously add functionality without changing the network at all.

Third: from a network scalability and power perspective, I think the current architecture scales quite well. In terms of traffic, ND is almost never a scaling problem except in extreme cases (e.g., tens of thousands of nodes on a link). And because ND uses multicast, these problems are easily solved using L2 optimizations like multicast snooping and, in the case of 802.11, things like multicast-to-unicast conversion. Even currently-specified things like ND proxying aren't really necessary for this purpose. From a power perspective, ND is a negligible cost for pretty much any general purpose device, and definitely for *anything* the size of a phone or larger.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]<mailto:[e-mail]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------