On 07-Oct-19 11:34, Mark Smith wrote: > Perhaps ANIMA is an alternative? It has seemed to me that home networks might > be just a more specific case of autonomic networks.
...for professionally managed networks. So there would be new work to do, if we wanted to expand the scope. > > For example, they've been defining a Generic Autonomic Signalling Protocol > (GRASP). > > https://tools.ietf.org/wg/anima/ > > Brian Carpenter has been working on an implementation. > > https://github.com/becarpenter/graspy Which is plastered with warnings that it's not fit for real-life usage, as a prototype written in Python. Brian > > On Mon, 7 Oct 2019, 08:41 Ted Lemon, <mel...@fugue.com > <mailto:mel...@fugue.com>> wrote: > > On Oct 6, 2019, at 10:58 AM, Ole Troan <otr...@employees.org > <mailto:otr...@employees.org>> wrote: >> 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 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? > >> 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? > >> 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? > >> 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. > >> 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? > > 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. > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org <mailto:i...@ietf.org> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
