> On 4.3.2014, at 14.56, Juliusz Chroboczek <[email protected]> > wrote: >> During this morning's session, I mentioned how much I like the HCNP >> protocol, and that I'm looking into abandoning AHCP for a hacked-up >> HCNP. I made the following points this morning: >> >> 0. As far as I'm concerned, this is not "The Homenet Configuration >> Protocol", this is a configuration protocol for unmanaged routers that >> happens to have been designed by the Homenet group. Please keep this >> in mind when you read the following. The thing is how much do we want to speculate to make it suitable for other unknown usecases. I don't really want to overengineer it based upon unknown requirements.
> >> 2. Related to the previous point, is everything MUST, or should some >> parts be made optional? I'd personally like the DNS proxy stuff to be >> made optional. > Agreed. It started as a separate draft and MUST in separate draft was > sensible but now, well.. I’m wondering even about PA stuff, because if you > want to use different algorithm, it should be ok as long as you publish your > delegated/assigned things in a compatible way. I suppose we want to differentiate between transport and payload here. I'm not sure if splitting it up into individual drafts might make sense but definitely - as I also pointed out in the presentation - it wasn't meant to be interpreted in a way that any of the non-protocol related TLVs are mandatory. Though in practice there are some inter-dependencies between payloads atm, e.g. both the fallback-routing and the DNS/SD stuff somewhat reuses prefixes and / or address-information announced by the PA-mechanism. > >> 3. There would appear to be no way to specify "please carve this >> prefix into /64 or shorter" as opposed to "please feel free to grab >> a /128 in this prefix”. > Hmmh. Do you think it’s issue in the hncp-00 or prefix-assignment one? I’m > not exactly sure I want ‘purpose’ bits for delegated prefixes. (see above > also on mandatoriness of prefix-assignment _draft_) I don't know if we really consider a /128-assignment to be a prefix in that sense. I would see this as a special case to aid in meshing and similar so I think maybe adding a special kind of _assigned_ prefix type of some sort might make sense for this from which every (supporting) router should be able to pick a /128 regardless of the link. > >> 4. Do we want the ability to mark an option as mandatory, as in >> "Please don't configure unless you understand the following TLV, and >> intend to act upon it". One the one hand, this makes is easier to >> design compatible extensions to the protocol (by sending two >> configuration blocks, one with a mandatory incompatible option, one >> without the option, and having old routers ignore the block with the >> incompatible option). On the other hand, it adds another failure mode. > I’m slightly concerned about that - from my point of view, ideal way to > extend is to ignore unknown TLVs, and then embed all information that > requires understanding the TLV _within_ that TLV in some way. I'm not sure if that makes sense either. HNCP is a pretty agnostic protocol and -please prove me wrong- I can only really see a point for this for extensions to the actual transport or security logic. This also refers to the discussion if we want mandatory payloads. > >> 5. I don't think the routing protocol should be negotiated by the >> config protocol, since that implies that the routing daemon is started >> by the config daemon. The routing daemon(s) should be started at >> boot, and notice when the config daemon adds IP addresses to >> interfaces. Knowledgeable people appeared to disagree. I would disagree here. I don't see the point in starting the daemons for homenet-interfaces here if they have to wait for HNCP to assign prefixes / addresses anyway. > My preliminary thought is as follows, repurposing the fallback routing - let > me know if this sounds bad: > > Add a no-routing-TLV (zero content) which means that routes towards this node > have to be done without routing protocol (by other HNCP nodes that support > real routing protocol). The no-routing node can also do routes towards other > nodes similarly. (This has underlying assumption that HNCP TLV space covers > all prefixes we care about, which is probably sufficient for packets to flow > although possibly suboptimally.) I wouldn't really do it like that. Even though I agree with the 0-1 or 1 routing protocol agenda I wouldn't really do negative capability announcements. If for some reason you want to make changes or use HNCP for other purposes later this will get ugly. _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
