On Oct 6, 2019, at 11:36 PM, Ole Troan <otr...@employees.org> wrote: > 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.
The question I have about this is: if nobody is shipping this, how do we know that the problem is solved? We have zero operational experience for the intended use case. HNCP experts setting it up for themselves or people they know is not the target use case. At present everybody who’se tried seriously to use this stuff has looked at the source code. >>> 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 This makes sense. > - 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 Yes. This is a big problem. > - it does not support the case "permissionless extensions of the network". That seems to contradict your first point—if you want permissionless extension, isn’t that by definition not centralized? >>> 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. Hm, okay, fair point. But I think that we need to say how RA guard works on home networks if we don’t want to have to guess. Possibly this is not 6man work, but it feels relevant to me. >>> 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. If you’re adding this to an RFC 7084 network, there are things that you can do that can work as long as RA guard isn’t present, and that achieve the limited goal of being able to have devices on one network communicate with devices on the other. Indeed, a ULA would work well for this use case. Allocate a single ULA, and then allocate prefixes out of it for the various networks. I think that if you want to add more than one router, HNCP+Babel is a sensible way to do it. But this is only required for leaf-to-leaf communication. A device on the home network will have an RA advertising transit to each leaf prefix, and will either have IPv6 connectivity from RFC 7084, or from another prefix advertised on the link. The problem with per-host routing is that it means I have to implement and deploy per-host routing, which I never want. And as you add leaf networks, the number of routes being propagated starts to snowball. I believe that this can be made to work for use cases I care about, but it’s in no way a “good” solution. The main problem with it is that it means I have to write code to do it. I’d rather not write that code if I don’t have to. > 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). Yeah. That is the exact situation I would most like to avoid, so I don’t want to be walking in that direction. > Because you don't like the mechanisms for automated subnet assignment? ;-) On the contrary, if HNCP were widespread, that’s what I’d be using. HNCP would be my first choice for this. I’d still like that to be the long-term solution. But what can I build into a leaf router _today_ to make this work when the edge router doesn’t run HNCP? :) > 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. BGP? ;) >> 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. Okay. Thanks for the deep engagement on this. I’m not sure we agree on what to do, but it’s very useful to hear what you are thinking about this.
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
