On Fri, Apr 14, 2023 at 1:14 PM David Schinazi <dschinazi.ietf@xxxxxxxxx> wrote:
To respond to your comment about "insufficient prior outreach to subject matter experts", you're missing an important bit of context. When RFC 7298 was written, Babel was RFC 6126 and that only supported sending packets over link-local multicast. As you know, there is negligible amount of reordering there, for either Wi-Fi or Ethernet, or even overlays for that matter.
I actually don't know that. If I were designing or implementing something at the network layer, I would probably try to minimize reordering; but I don't actually know what is implemented in real world devices. Which is why I would engage someone with SME in that area if it really mattered to my design.
However, when we rewrote Babel in RFC 8966, we added the ability to also send packets over link-local unicast. This feature did get implemented, and so did HMAC - however no one deployed both simultaneously in production. When that was done, we realized that there was indeed an oversight because unicast and multicast do get significantly reordered on Wi-Fi. The document that you reviewed fixes that oversight. All that to say, we're not completely clueless over here in Babel land. We made a mistake not foreseeing how two separate features interact, but please don't assume incompetence.
My review does not assume incompetence, unless one regards not being an expert in absolutely everything as incompetence (which I don't). I'm suggesting that something like the assumption that queueing behavior is basically FIFO over all packets, or that it wouldn't differ based on destination address, might have been obviously wrong to someone who works in that area, and that the ADs should make sure document authors are engaging the right set of expertise. It's not like this was unforeseeable: it is well known that UDP and IP guarantee nothing about packet delivery ordering, so any assumption about ordering should immediately prompt additional scrutiny.
Back to your first point, yes the document does assume that, when treated independently, link-local unicast and link-local multicast are generally not reordered much in known deployed link layers.
Can you provide a reference for this claim? I don't doubt it's actually true, but a reference to some research actually verifying it would make a fine addition to this document and any future 8967bis.
Maybe making that assumption explicit to help explain why the reordering window is optional sounds like a reasonable enhancement. That way if someone deploys Babel HMAC later over a new future link layer that reorders, they'll know to implement the window.
I was making a more general point there that the design choice, reasonable as it might have been at the time, was not explained anywhere I could find. That kind of context, even if just in an appendix, is helpful to people asking "why?" in the future.
To your other note about adding a protected field, the intent in this doc was to build something backwards compatible - but maybe we should note that to help explain the design choices.
Agreed, thanks.
Kyle
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
