I agree with Markus and Steven on most points, but let me clarify a few aspects.
- First, I think this is really cool if another area wants to use hncp. So I don’t see any reason we couldn’t adapt the documents to allow it. We should be careful *not* to make homenet specifications too complex thought. Having too many abstraction layers may not be desirable. - As Markus said, I think removing some TLV’s from hncp transport layer specifications is not a problem. We can have a specification for hncp-transport, and another for hncp-homenet. I’m a bit more concerned about removing trickle algorithm behavior. We can abstract the TLV layer, but abstracting upper AND lower layer seems too ambitious. Having the network to correctly converge, and efficiently enough, is not an easy requirement. Trickle is lightweight, efficient, proven for this purpose. I think hncp should precisely specify the packets transmission behavior. - The prefix assignment algorithm supports /128. I’m not sure we want Homenet to have such ‘carve it into /128’ option. Homenet doesn’t want to do that. - Homenet-hncp intends to be incremental in terms of TLVs. Other TLVs will come, and, if hncp is widely used in homes, vendor-specific options will come as well. So I think ‘ignore TLVs you don’t know’ is the correct behavior. Nevertheless, I understand hncp could be used for other purposes, in different contexts. But such use should run in different instances. Using a different UDP port, *or* creating a ‘context’ TLV or header value (With defined ‘homenet’ context, ‘ahcp’ context, etc…). Of course, in terms of performances, using a different UDP port is desirable. - Concerning the routing protocol, finally. Although I like the 0,1 option and that negotiating a routing protocol doesn’t disturbs me so much, I think most vendors will only implement the 0 if they can… So, for Homenet, I think we are going to end up with a single RP. I may be dreaming, but I would like to see the hncp-routing (0 RP), because it would avoid a lot of redundancy in propagated information. But for that purpose, we’ll have to prove its design is correct. Then, if we make a hncp-transport document, it will be completely agnostic to this routing stuff. Only hncp-homenet will. Using a different ‘context’ or UDP port, you could just define your own behavior for hncp-ahcp regarding routing. - Thanks for you comments. It’s a very interesting discussion. Le 4 mars 2014 à 14:56, Juliusz Chroboczek <[email protected]> a écrit : > Hi, > > 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. > > 1. The draft seems overspecified at times. Do we really mandate > Trickle, or do we want just an abstract description of flooding > requirements? (Knowledgeable people commented that Trickle is fine.) > > 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. > > 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". > > 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. > > 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. > > (It seems to me that the config protocol should be routing-protocol > agnostic, and merely say "this protocol assumes that a routing > protocol satisfying the following conditions is available". Homenet > should specify what the protocol is, and mandate implementation of The > One Homenet Routing Protocol (OHRP).) > > I'd like RIP to be the OHRP, but I don't have strong opinions on the > subject. > > I also don't care whether Homenet says that routers MUST implement > OHRP, or whether they MUST implement OHRP and MAY implement other > routing protocols. In either case, > > - commercial Homenet router vendors will implement the OHRP and > ignore the MAY protocols; > - the OpenWRT routing overlay will probably install the OHRP by > default, but provide its usual set of optional routing daemons. > > In short, there will be no difference in practice whether Homenet > allows non-Homenet routing protocols or not. > > -- Juliusz > > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
