Subject: Re: [Ospf-wireless-design] Synchronization requirement for including a neighbor in LSA

From: Acee Lindem <[email-masked]>
Date: Fri, 01 Apr 2005 10:50:59 -0500

Hi Richard,
As we discussed offline, can we call your DR/BDR the CDR/BCDR (Connected
Dominating Router/Backup ....)  or MDR/BMDR (Manet Designated 
Router/Backup ...)
as we move forward? The OSPF DR/BDR for a broadcast/NBMA has a very
well defined set of responsibilities and duties in the flooding process. 
IMHO,  the
semantics are different enough that we don't want to overload the terms 
OSPF
DR/BDR.

Also a change allowing non-adjacent neighbors to be advertised is 
somewhat beyond
the initial scope of flooding optimizations. In any case, the protocol 
mechanisms, events,
and state machines need to be very precisely defined in order to be 
evaluated.

Thanks,
Acee

Richard Ogier wrote:

> All,
>
> I want to discuss the definition of a "synchronized" neighbor
> in Section 5 of my draft, and explain why I think this is a
> good requirement for a neighbor to be included in the router LSA.
> This condition is valid for both full-topology and partial-topology
> LSAs, so the discussion below applies to either case.
>
> First, I am assuming that a set of adjacencies has been formed
> that spans the entire network, so that there exists a (suboptimal)
> path from each router to every other router via adjacent edges
> (except temporarily as new adjacencies are formed in response
> to topology changes).
>
> Each router will include, at a minimum, each fully adjacent neighbor
> in its router LSA. This will provide suboptimal routes to each
> reachable router.
>
> The question is, what other neighbors can be included in the router LSA?
>
> Suppose that node i has a non-adjacent, 2-way neighbor j, and that
> the SPF calculation has calculated a route to node j via a fully
> adjacent neighbor k. Then node i can route data packets to neighbor j
> via neighbor k. (Or, neighbor j might not be the final destination,
> but might be an intermedate node to another destination.)
> So, instead of using neighbor k as the next hop, why not take
> a shortcut and forward the data packet directly to neighbor j
> as the next hop?  This is quite reasonable, and is exactly what
> the synchronized neighbor rule says.
>
> Once neighbor j has been declared to be an acceptable next hop
> (to any destination), it can be included in node i's router LSA.
>
> Note that this is a generalization of what is allowed in an OSPF
> broadcast network, which allows a non-DR/BDR i to use another
> non-DR/BDR j as a next hop as long as both are fully adjacent to
> the DR.  In a broadcast network, there is no need for node i
> to include node j in its LSA, since the network LSA originated
> by the DR already implies this information. But when we
> generalize to a multihop network, the only way node i can
> inform other routers that it can forward packets to node j,
> is to include node j in its router LSA.
>
> A possible concern: What if, after declaring node j to be an
> acceptable next hop, there temporarily does not exist a path
> of fully adjacent edges to node j, due to topology changes?
> The above rule does not detect this and does not remove node j
> as an acceptable next hop (unless node j is no longer reachable).
>
> The answer is that the protocol will be robust enough (if designed
> properly) to maintain sufficient database synchronization even
> when topology changes cause old adjacencies to fail and require
> new adjacencies to be formed.
>
> The only case where routers may not be acceptably synchronized
> is when the network partitions, i.e., some destinations become
> temporarily unreachable.  The above rule will detect this,
> since it requires a neighbor to be reachable via a current path
> that has already been determined to be acceptable.
>
> I plan to implement the above method in the next few weeks,
> so we will see how it peforms.
>
> Richard
>
>
>
>
> _______________________________________________
> Ospf-wireless-design mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ospf-wireless-design
>

_______________________________________________
Ospf-wireless-design mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ospf-wireless-design

---

From: Richard Ogier <[email-masked]>
Date: Fri, 01 Apr 2005 08:26:00 -0800

Hi Acee,

Acee Lindem wrote:

> well defined set of responsibilities and duties in the flooding 
> process. IMHO,  the
> semantics are different enough that we don't want to overload the 
> terms OSPF
> DR/BDR. 

OK.  I prefer MDR/BMDR.

> and state machines need to be very precisely defined in order to be 

If the initial scope of flooding optimizations does not
allow non-adjacent neighbors to be advertised, then it may
prevent an efficient solution. I guess the scope can be
changed if it is found to be necessary. But I think the
fact that OSPF already allows a non-adjacent neighbor
to be a next hop (in a broadcast network), and the fact
that this information is implied by the network LSA originated
by the DR, implies that the inclusion of a non-adjacent neighbor
in an LSA is simply a necessary generalization to multi-hop
networks, since a network LSA cannot be used in such networks.

Once the protocol is implemented in GTNetS (in the next
few weeks), it will be precisely defined.

Richard