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

Hello Lorenzo 
> 
> 
> 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.
> 

This is one tool in a tool set. The one thing that this draft does not intend to be is a one fits all. It is an administrative decision to split the broadcast domain and when that decision is made then this architecture is cleaner than bunches of tunnels aka MIP.

 Note that it is heavily deployed on wires today in EVPN and LISP -based solutions. So we are mostly recognizing after the fact that it exists, and providing an architecture as a context for it.

 Doing that we realize that snooping protocols is a non-deterministic hack so the framework provides a proactive way to fix it.

About the use of “reduce”. Whether there is a reduction and the extent of the loss is also dependent on the use case and I’d leave ths cost  / benefit to the admin’s appreciation.

> ======
> 
> 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.
> 

Too many cases around to be that general.

 In my book delegating prefixes to the host is totally part of the architecture, at least when the prefix is longer than 64. 

Whether the host gets /128s or /96s or what else does not make a difference. It’s just a route in the SGP. And the host knows that it can (ask the router to) inject that route (using ND prefix registration)  because its prefix fits in the one in a PIO. This is the sense of my question yesterday at 6MAN. Mobility/DNA requires that you know if the delegated prefix is still usable in the new location.

> 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 architecture allows for scopes. From link local which is what discovery protocols for physical objects will use to admin scope which is what the admin decides is the domain where an address / prefix is topologically correct and reachable.

The key word for the large domain is mobility. Forming new addresses on the go creates hiccups in the active conversations. Not nice but survivable. It’s a lot worse for delegated prefixes if you need to flash-renumber the devices inside the device. We are not good at that. This was the sense of my words at v6ops.

 Very chatty broadcast protocols hopefully fall into the fist category. We have measured 300+ ND broadcast messages at a large conference during the keynote. Saying that mDNS is worse, well, depends.

 ND in rfc 4861 requires the scope of the subnet vs hopefully most services one is looking for that are either on link or proxied. This difference of scope is what makes the difference and the reason to focus on ND.

The keyword here is sustainability. Apart from storms, broadcasts over a large domain mean wasting energy and (as Nick points out) spectrum. When you think that those broadcast are intended for 0 (DAD) or 1 (lookup) target, it feels more planet friendly to leave the door open with the AC on.

> 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.

It’s still there. Use it wisely is the ask. Part of that is for protocol developers to design with more sustainability in mind (when shall we have a sustainability section in our specs) 

Another is for net admin to design their broadcast domains and service deployment with energy in mind as well. Here we are giving them new degrees of liberty to achieve that.

> 
> 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.

True. It’s probably still ideal for home.

In the case of EVPN or LISP you are a decade too late. This complexity is already there, as the routers build all those tables already. The architecture just provides a context for what is heavily deployed in corp and campus networks.

In EVPN, the 6LBR is replicated in all PEs and synchronized by BGP (acting as SGP). In LISP it is centralized in the MSMR, which itself is implemented in a distributed and redundant fashion. With RFC 8929, the 6LBR is distributed between the 6BBRs (think WiFi APs) each of which is authoritative for proxying its registered addresses. In IoT LLNs, the SGP of choice is RPL

But snooping ND is undeterministic. That’s what the framework in this document rea adds to the existing picture.

> 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.
> 

RFC 8505 /8928 are still autoconf. It just establishes a contract that guarantees to the host that the addresses will be served. When that cannot happen then at least the host gets to know. Part of the contract is SAVI that ND lacks completely. With the registration, impersonation and scanning DOS are prevented natively.

> Third: from a network scalability and power perspective, I think the current architecture scales quite well. In terms of traffic, ND is

Traffic is not different. Mobility and efficiency are.

> almost never a scaling problem except in extreme cases (e.g., tens of thousands of nodes on a link).

The rule of a thumb in OT (after lotta  displeasing experience) is 100 nodes per subnet. After that they claim that their operations (think control network) get unreliable. This is IPv4 so you should really read 100 addresses per subnet. Source: ODVA.

> And because ND uses multicast, these problems are easily solved using L2 optimizations like multicast snooping and, in

I have 10+ years of experience that tell you that it does not work reliably. Add to that that the host behavior is largely unpredictable. Some old implementations will send NA(O) to anl hosts right after DAD. Newer will not. Even newer (GRAND) will send it to all routers. So sometimes the first NA is a response to a lookup which is way too late and impacts the flow. 

 Of all 3, GRAND is the best for the infrastructure . But it’s one shot, not redone after mobility, and it’s not a contract with a lifetime etc. So even if widely available it would still be largely inadequate.

> the case of 802.11, things like multicast-to-unicast conversion.

Much needed, done by the ARP proxy based on the prior knowledge of all addresses that must be deterministic . This is exactly why WiFi has an association and the association is  exactly what RFC 8505 mimics at L3. Same cause and effects.

> Even currently-specified things like ND proxying aren't really necessary for this purpose.

So you say. IEEE std 802.11 mandates it. 

> 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.

See Nick’s answer. This can be correct at home but a huge misconception in a large corporate/ conf / stadium / campus networks.

My memory is that JJ B introduced /64 to the host in stadiums for that reason. I may be wrong.  In my book it full makes sense as a topical short term solution like for the duration of a game. Generalized you get IPv4 with 8 bytes addresses.

All the best,

Pascal 

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------