On Wed, Jul 22, 2015 at 06:17:20PM +0200, Markus Stenberg wrote: > > On 22.7.2015, at 17.10, Pierre Pfister <[email protected]> wrote: > > > > Just throwing an argument that comes into my mind here. > > > > HNCP advertises configuration. Long-lived things. > > It is likely that DNCP is quite inefficient when it comes to changing > > things all the time. > > Metrics can evolve. Particularly wifi links metrics. So we probably do not > > want to put that in DNCP. > > I am not sure how well e.g. ISIS deals with constantly changing link > metrics either (hello, constant link state db sync). > > So there would have to be some sort of hysteresis and e.g. just orders > of magnitude different metric changes reported in any case.
You're completely right; you have the free choice on when and why to update a particular metric IS-IS, and the right thing to do is not do it every 0.01s. However, you're wrong in implying that the constant link state db sync would be largely different in a distance vector protocol. In a DV protocol, you can: - choose to delay propagating updates that *lower* metric for a prefix - not propagate updates that are not selected In a LS protocol, you can: - send smaller updates when lots of prefixes are on a single router - not propagate updates that you know the peer is aware of, even if that means the peer's path is through you (the latter happens when routing information propagates slowly on a low-metric high-latency path, but quickly on a high-metric low-latency path) Either way when you're changing some metric, you need to start distributing that. Neither LS nor DV have "absolute" immediate advantages. (Which is why lots of large networks run LS IGPs internally, but we're using DV/BGP on the internet at large.) -David _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
