Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Tom,

Thanks for your comments.

A summary of our offlline discussion to feedback to this list.

> 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

This is outside of OSPF scope, and already going on.

> - overhead reduction techniques such as differential hellos 
> or partial topology reporting. 

This is the true-MANET situation and Alvaro is following up you on that.

Thanks.
Jeffrey

> -----Original Message-----
> From: Henderson, Thomas R [mailto:[e-mail]] 
> Sent: Monday, March 28, 2011 8:41 PM
> To: 'Acee Lindem'; Nischal Sheth; Jeffrey (Zhaohui) Zhang
> Cc: [e-mail]
> Subject: RE: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type
> 
> 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
>