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

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 28 Mar 2011 10:48:24 -0400

WG chairs and members,

As Acee mentioned below, this optimization is a reasonable, simple and general solution for a valid probem, and is really not conflicting with MANET.

As a result, we would like to request again for WG's acceptance of this work.

Thanks.
Jeffrey, Nischal, Lili. 

> -----Original Message-----
> From: Acee Lindem [mailto:[email-masked]] 
> Sent: Tuesday, February 22, 2011 7:10 PM
> To: Nischal Sheth
> Cc: Alvaro Retana (aretana); Jeffrey (Zhaohui) Zhang; [email-masked]
> Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type
> 
> Speaking as a WG member, I really don't see this hybrid 
> interface optimization as conflicting with the problem space 
> covered by the MANET draft. 
> Thanks,
> Acee 
> On Feb 10, 2011, at 6:29 PM, Nischal Sheth wrote:
> 
> > On 1/6/2011 2:26 PM, Alvaro Retana (aretana) wrote:
> > 
> >> You don't need to implement everything in the rfc to support the
> >> interface functionality.  Most of the work in the rfc is 
> oriented at
> >> reducing the overhead on the wire (Incremental Hellos, 
> Smart Peering) or
> >> at addressing the cases where not all the nodes are 
> visible (Overlapping
> >> Relays).
> >> 
> >> If you don't care about reducing the overhead and can 
> guarantee that all
> >> the nodes are visible, then the interface definition is enough. ;-)
> >> That reduces to taking advantage of the broadcast 
> characteristics for
> >> flooding, but using p2p adjacencies -- which would be a 
> lot easier to
> >> operate because it is clearer what the relationship 
> between the peers
> >> w/the different metrics is.
> >> 
> >> In my mind the problem in your document is already solved.
> >> 
> > 
> > Hi Alvaro,
> > 
> > If one were to use just the interface definition, we would 
> end up with a 
> > full mesh of adjacencies between all routers on the 
> broadcast network.
> > This is less desirable compared to the hybrid interface 
> which requires 
> > adjacencies only to the DR/BDR.
> > 
> > One would need to implement Smart Peering in order to 
> reduce the number 
> > of adjacencies on the MANET interface.  However, doing so 
> would result 
> > in suboptimal routing unless you implement Unsynchronized 
> Adjacencies.
> > Finally, Unsynchronized Adjacencies requires a protocol 
> extension which 
> > is defined only for OSPFv3.
> > 
> > Based on the points above, I don't consider the MANET 
> Interface to be a 
> > true superset of the hybrid interface to solve the problem at hand.
> > 
> > -Nischal
> > 
> 
>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 28 Mar 2011 10:53:05 -0400

Sorry - forgot to emphasize that the proposed optimization only applies to true-broadcast networks (including but not limited to wired networks), and is not intended for true-MANET networks.

Thanks.
Jeffrey

> From: Jeffrey (Zhaohui) Zhang 
> Sent: Monday, March 28, 2011 4:48 PM
> To: Acee Lindem; Abhay Roy (akr)
> Cc: Alvaro Retana (aretana); [email-masked]; Nischal Sheth; Lili Wang
> Subject: RE: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type
> 
> WG chairs and members,
> 
> As Acee mentioned below, this optimization is a reasonable, 
> simple and general solution for a valid probem, and is really 
> not conflicting with MANET.
>

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 28 Mar 2011 11:40:47 -0700

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

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 29 Mar 2011 10:10:14 -0400

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

> From: Henderson, Thomas R [mailto:[email-masked]] 
> Sent: Monday, March 28, 2011 8:41 PM
> To: 'Acee Lindem'; Nischal Sheth; Jeffrey (Zhaohui) Zhang
> Cc: [email-masked]
> 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. 
> 
> 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