Hi Ted, >> Are you saying there might be gaps in HNCP? Or things we could do to make it >> more deployable? >> If it's just a matter of running code missing, I'm not sure defining >> anything else new in the IETF would help that problem. > > There are definitely missing features from the protocol that I’d like to add. > But I think the fact that the protocol isn’t deployed on a _single_ > commercially available router, and is not really usable on OpenWRT by a > non-expert, is an indication that there is substantial remaining work to do. > Operations work is not out of scope for IETF; maybe I should have asked this > on v6ops. We have historically said “not our problem,” but I don’t agree > that that’s the right answer. If HNCP had really convincingly solved the > problem, we would not be seeing what we are seeing.
I believe HNCP has solved the technical problem it set out to do. Allow for an automatically configured, arbitrary topology network with multiple exits. The deployment challenge of that is that every router must support HNCP and must support SADR. >> I know why I haven't implemented HNCP on software I work on... and I also >> know that there aren't any very realistic alternatives either. > > Can you say why that is? Quite a few reasons, some which might be not relevant to your case of course. - the pendulum between distributed algorithms and centralized controllers is for the problems I'm working on largely towards the centralized side - it's quite a lot of work. it requires a new routing protocol, it requires a changed forwarding paradigm, and it requires integration with a lot of features - it does not support the case "permissionless extensions of the network". >> RA guard isn't applicable in a RFC7084 context. RFC7078 talks about routing >> and routers. I.e. what happens at the network layer. > > You mean at the “internet layer,” I assume? No, I mean the network layer. RA guard operates as a layer violating feature at the data-link layer. >> If you are talking about what happens at the often integrated bridge CE >> devices have, then sure, they could implement RA Guard. >> But having your additional router sending RAs across the homenet might not >> be a particularly good idea anyway. > > Why not? What would be a better idea? I don’t mean to say that using RAs > in this way is ideal, but what’s the alternative that doesn’t involve the > vast complexity of per-host routing? I don't understand how it would work. Add another router with it's own link. How would you get addresses for that link? Make them up from ULA? And then advertise that in an RA upstream with the MSR option? That would put a lot of responsibility on the hosts of getting things "right". And what if you added two of your routers, or connected them differently? Per-host routing is in itself trivial and likely scales orders of magnitude further than you need. But there are problems with MLSR that are unsolved / not solved to my liking yet there. >> Sounds like you need to set it up as a NAT. > > I really hope you are just making a funny joke here. But it’s not very > funny. What I want is something that’s operationally simple, not something > with lots of moving parts that have to be kept track of. NATs in particular > suck for any UDP-based protocol. for "permissionless extensions of the network" there isn't much else than NAT. Your other likely option is an ND proxy. If you are very sure that nothing else can be added to the network (we don't want to build a spanning tree protocol out of ND). >> I wasn't thinking of doing it exactly like the 6lowpan does it. >> Regardless I don't see why scaling should be problematic, are you planning >> to have millions of rapidly moving hosts on your shared /64 network? > > If you have N devices on a single link on the other side of the router, then > when using either RA or a routing protocol, the amount of information you > need to propagate to get things working is very small: just a prefix and a > router. If you can’t do that, then the amount of information you need to > propagate is at a minimum N units, and possibly K*N, for some not > insignificant factor K. > > To be clear, the reason I’m concerned about this is that I’ve looked at > implementing it on OpenWRT, and it’s at least roughly doubling the complexity > of the work required, even if you can depend on using IPv6. If you have to > use IPv4 on one side, then it’s even more complexity. And it’s utterly > stupid complexity—it adds no value over subnetting. Why add that to the > network? Because you don't like the mechanisms for automated subnet assignment? ;-) And no, I'm not suggesting we should do MLSRv2 as a competitor for HNCP. MLSRv2 would also require an update to every router, and a network operator allowing extensions to the network. > This is why I’m asking people if they have knowledge of what is actually > deployed. I think this is the right place to ask, but if you disagree, I’m > open to suggestions. I do not disagree. I think having that feedback loop from implementation/deployment/operational experience is important. Best regards, Ole _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
