On 19.2.2015, at 16.50, Pierre Pfister <[email protected]> wrote: >>> It's been what, 1.5-2 years since then? We've already noted that HNCP looks >>> awfully close to a link state protocol and duplicates quite a lot of of >>> functionality. >> Right. It is essentially bit more modern take on a link state routing >> protocol. So if you bring it up, I bring up the another argument - why not >> route using it? Cost of doing _that_ is ~100 LoC (+ whatever fancy thing we >> want to do with metrics). > > First of all, because there are differences between assigning a prefix and > using it for routing. > - Assigning a prefix does not mean you are the best router to route toward > it. It may not even mean it is assigned to a link you are directly connected > to. It may also be an excluded prefix. Assigning a prefix just means you > reserve that prefix for some usage. One of this usage happens to be ‘prefix > assignment to a link’, but it may be others.
Well, we can officially add ‘I haz this address on this interface’ TLV if we care about it and then semantics would be exactly same as with e.g. IS-IS. Down to both using link state protocol to transmit the information. > - There is a delay between the assignment and the actual use of a prefix. > This is called ‘Apply Delay’ in the prefix assignment draft. I don’t think > routing based on assigned prefix TLVs is a good idea because you would not > try to handle assigned prefixes collisions correctly. Again, detail. Which can be addressed if we care enough. And at much smaller footprint than second link state database. > Second point is that DNCP is going to transport multiple things. This will > imply churn. As Gert said, I think protocols should do one thing and do it > well. Babel is a loop-avoiding routing protocol. Do we want to put > loop-avoidance mechanism in HNCP ? Of course not. Would HNCP be able to do > routing ? Yes. But would it be able to do it if a buggy node constantly sends > DNCP updates… It is less sure, and depends on the quality of the > implementation. Link state _with_ loops is hard. So I am not sure how this applies. If buggy nodes happen _for anything_, very little is guaranteed. So strawman argument from my point of view. > Last point is that the routing protocol we will agree on will not be the last > we’ll ever come-up with. Some other will be invented. Better ones. DNCP is an > element with a set of requirements. Let’s keep DNCP simple. A routing > protocol has other requirements. And maybe some day we will decide to move to > another routing protocol because we made a mistake or a new better routing > protocol was designed. We need to make sure that this transition will be > possible. And I think having an independent routing protocol running today > will make this transition easier. I thought the whole thing was to aim for bad transition mechanics; we originally proposed ‘voting’ mechanism which was extensible. Also, at some point, Steven suggested ‘fallback as low priority default’ (while running 0-N routing protocols on top of it with disjoint metric spaces). Again, not accepted. ‘One routing protocol’ does not sound like the option that is extensible in any direction. Except by saying that ‘yeah, we have HNCP2’ with zero-interoperability in either direction. Cheers, -Markus _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
