I don't have a problem with the proposal to specify a simpler interface type for the use cases described. It seems preferable for a vendor to be able to say that it fully implements a particular interface type rather than having to say that it implements an interface type but lacking features a,b,c etc.
There are many radio systems that perform routing below IP and provide a full broadcast-based abstraction, but for which the neighbor costs are unequal and it would be nice to be able to represent them that way in OSPF. Moreover, people are now designing radio to router protocols to allow these unequal costs to be dynamic and automatically computed. It might be nice to define broadcast-oriented interface types progressively as follows: 1) existing broadcast interface for equal-cost neighbors 2) the proposed hybrid interface for full mesh broadcast links with unequal neighbor costs 3) correct the DR election and flooding behavior for links that may be partial mesh The above could all be separate interface types, and 2) and 3) could each be supplemented by additional capabilities: - optional radio-to-router control protocol to determine the unequal neighbor costs or router priorities automatically - overhead reduction techniques such as differential hellos or partial topology reporting Tom _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
