>> Using information distributed through the routing protocol, each node >> in the homenet should be able to build a graph of the topology of the >> whole homenet including attributes such as links, nodes, connectivity, >> and (if supported by the protocol in use) link metrics.
> Fine by me. Apart from the use of the word "graph" which could be > overloaded or suggest a preference for link state > protocols. s/graph/consistent view/ ? I've already mentioned before that I'd just remove this whole sentence. The goal of a routing protocol is to provide routes that are useful for forwarding user traffic. Whether it does that by building "a graph", "a consistent view" or through haruspicy is pretty much an implementation detail. >> Routing within the homenet will determine the least cost path across >> the homenet towards the destination address given the source address. > Too explicit IMHO. Multiple problems: inconsistent terminology (cost/metric), assumes the existence of a metric, assumes that the protocol always chooses least metric paths. Just remove this sentence and be done with it. > What is wrong with s/determine the least cost path across the homenet > towards the destination address given the source address /maintain > a loop free forwarding path between any given source address and > destination pair/ Since we're being picky, this might be understood as excluding OSPF and RIP, which may cause transient routing loops. (Exceedingly short-lived in any half-decent implementation of OSFP, granted.) >> Multiple types of physical interfaces must be accounted for in the >> homenet routed topology. > Fine be me. I think I may have already mentioned that I'm really not sure what this sentence means. Does it mean that the routing protocol must be able to automatically distinguish between wired and wireless links? Have different route selection/metric computation strategies depending on the link layer? On either count, only Babel qualifies, which I'm pretty sure is not what is intended. >> but as a guideline a maximum convergence time at most 30 seconds should >> be the target > Way too explicit IMHO. I don't see why a figure of 30 seconds for > convergence time is even given. Heh. If memory serves, RIP(ng) with triggered updates converges in exactly 30 seconds, worst case. (Snipped the part about border discovery, which I'm not competent to comment on.) > It might be worth adding that we do not expect LLN network to act as > transit networks between more traditional areas of the Homenet if you > are going to revise the text anyway. Hmm... I'm pretty certain that people will use degenerate mesh networks for transit once they realise it's a neat way to avoid laying wiring between your home and the shack at the back of the garden. Not sure about LLNs, but I'd be nervous about including such language. -- Juliusz _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
