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

From: Nischal Sheth <[email-masked]>
Date: Wed, 9 Feb 2011 12:13:31 -0800

On 1/6/2011 2:05 PM, Jeffrey (Zhaohui) Zhang wrote:

>
> Additionally, while radio network is one example, it is not the only one.
>

Here's a different example that highlights Jeffrey's point above.

If a Service Provider's OSPF is running over a broadcast network that is 
emulated by a VPLS service, it is useful to advertise a different OSPF 
metric for each neighbor on the broadcast network.  This allows you to 
achieve nearest exit routing when transiting the VPLS backbone for 
customers that are dual homed to the SP via BGP.

The metric for each neighbor could be manually configured.  Modeling the 
LAN as a hybrid interface lets you use the DR and DBR for flooding as 
opposed to treating it as p2mp in OSPF and establishing a full mesh of 
adjacencies.

-Nischal

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 9 Feb 2011 15:45:26 -0500

The same equally applies to a real l2-switched (and wired) network (vs. emulated by VPLS), as pointed out earlier by Pete [[email-masked]]:

> There is also a case of multiple ethernet switches connected together serially, with varying propagation delays to the routers that are connected to one of these switches. Imagine different types of transmission technologies in the network but still having ethernet on each end of the links. 

> From the perspective of a router connected to the nearest switch, a router on a far end switch will have higher propagation delay than a router connected to the same (nearest) switch, so having the ability to define a higher OSPF metric to that far end router can become important. 

Jeffrey

> -----Original Message-----
> From: Nischal Sheth [mailto:[email-masked]] 
> Sent: Wednesday, February 09, 2011 3:14 PM
> To: [email-masked]
> Cc: Jeffrey (Zhaohui) Zhang; Alvaro Retana (aretana); Acee Lindem
> Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type
>

---

From: Nischal Sheth <[email-masked]>
Date: Thu, 10 Feb 2011 15:29:09 -0800

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: Acee Lindem <[email-masked]>
Date: Tue, 22 Feb 2011 13:10:08 -0500

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