Subject: [Ospf-wireless-design] Response to comments on draft-ogier-manet-ospf-extension-03

From: Richard Ogier <[email-masked]>
Date: Thu, 10 Mar 2005 05:58:09 -0800

All,

Tom summarized some concerns about my draft that were voiced at the
OSPF session on Tuesday, which I would like to respond to.
The main concern seems to be that the solution may not be robust
because there are not enough Backup DRs, or because each DR has too
many Dependent Neighbors, or because it may take a long
time for database exchange when a new DR is selected.
I don't think these concerns are valid, but we will find out
with simulations (and I agree with Joe that simulations should
include failure models in addition to mobility). It would also help
if people with these concerns provide specific examples on the
ospf-wireless-design list; that way, we can be sure the concern
is real, and we will have concrete examples that we can discuss.

For now, I will clarify some things that might alleviate any
concerns about robustness.

1. There might be a misunderstanding that data packets can only
   be routed on adjacent (or fully ajacent) edges. This is not
   true in my draft, nor is it true in OSPF (in a broadcast
   network, a non-DR/BDR router can forward a data packet to
   a non-adjacent neighbor, as long as both routers are adjacent
   to the DR - note that the "synchronized neighbor" condition
   in my draft generalizes this condition).
   For example, in the full topology case, LSAs describe the
   full topology even though there are only about 2n adjacencies.

2. A new DR does not have to complete database exchange with its
   neighbors before it can flood LSAs. (This is also true in
   legacy OSPF).

3. If a DR fails, then a BDR will forward the LSA for it, so
   the main concern is what happens if a DR and a nearby DR/BDR fail
   at nearly the same time. The probability of this happening is
   fairly low, but it can happen, so let's see what happens.
   Note that it is possible to select more BDRs for more redundancy,
   or to allow *any* router act as a BDR, but I don't think this
   will be necessary, for the following reason.
   With differential Hellos being sent every 1 or 2 seconds (which
   is quite possible since they are small), if a DR fails, then
   a new DR will select itself within a few Hello intervals, e.g.
   between 3 and 6 seconds.  Since RxmtInterval is typically 5
   seconds, the new DR will probably select itself before the
   LSA would be retransmitted anyway!

I would also like to answer a question regarding what happens
if the 2-hop neighbor information is not consistent.
This is a good question, and I will update my draft to clarify
this. If node i has two neighbors j and k such that j indicates
(in its Hellos) that k is a neighbor, but k indicates that j is
NOT a neighbor, then node i must assume that j and k are NOT
neighbors (i.e., both neighbors must agree that they are
neighbors of each other). This provides faster recovery from
a link failure, since one neighbor may detect the failure
sooner than the other neighbor.  (Also, note that the rule
is different for partial 2-hop neighbor information, since
the absence of a neighbor RID in a partial Hello does not
indicate that the router is not a neighbor.)

Again, if you still have concerns about the CDS solution, please
give specific examples so that we have something concrete to discuss.

Regards,
Richard

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

---

From: Richard Ogier <[email-masked]>
Date: Thu, 10 Mar 2005 20:06:22 -0800

All,

I thought more about a suggestion from Tom that it might be better
to have more BDRs to improve robustness. Actually, if we just go by
RFC 2328, even non-DR/BDRs can retransmit any received new LSA on
any adjacency, although I was trying to avoid this in the last
paragraph of section 7 of my draft:

   To reduce unnecessary retransmissions, a DR_Other router never
   retransmits an LSA that it did not originally transmit as a
   broadcast.  This is done only by DR/BDR routers, and only to (Backup)
   Dependent Neighbors.  However, since it is possible for a DR_Other to
   become a DR or BDR, a DR_Other does put received new LSAs on the link
   state retransmission list for each adjacent neighbor.  If the
   DR_Other router becomes a DR or BDR, then it will retransmit all LSAs
   in the retransmission list for any (Backup) Dependent Neighbor.

This variance from RFC 2328 can be removed if necessary, so that
any non-DR/BDR router that receives a new LSA can retransmit it to
its (two) adjacent neighbors.  I doubt that this will be necessary,
since if a DR fails, a new DR will quickly select itself and
retransmit the LSA.  But we can try it both ways in simulations.

There was apparently a comment that MPR selection converges faster
than CDS-DR selection following failures, because MPRs are based
on more local information than CDS-DRs?  Quite the opposite is true.
Whether a router selects itself as a DR depends ONLY on Hellos that
are sent by neighbors of the router. However, whether a router is
selected as an MPR can depend on Hellos that are sent by 2-hop
neighbors of the router. This is because an MPR does not select
itself, but is selected by one or more of its neighbors, each of which
bases its decision on Hellos (or LSAs) sent by its own neighbors.
This is one of the advantages of a SI-CDS that Tao Lin and I have
mentioned before.  There are several other advantages of a SI-CDS,
including the fact the only *partial* 2-hop neighbor information
is required.

There was also a comment that we should focus on robustness rather
than efficiency. This seems like a trick comment, since it implies
that we cannot achieve both. So I guess the CDS-DR solution should
be disqualified if it is too efficient, even if it is also
robust?  :-)  Seriously, the CDS-DR solution was designed with both
robustness and efficiency as important goals, and we will soon
see if it can acheive those goals.

Richard

---

From: "Joe Macker" <[email-masked]>
Date: Mon, 14 Mar 2005 11:28:50 -0500

> There was also a comment that we should focus on robustness 
> rather than efficiency. This seems like a trick comment, 
> since it implies that we cannot achieve both. So I guess the 
> CDS-DR solution should be disqualified if it is too 
> efficient, even if it is also robust?  :-)  Seriously, the 
> CDS-DR solution was designed with both robustness and 
> efficiency as important goals, and we will soon see if it can 
> acheive those goals.
> 

The comment was meant in good spirit that robustness should be considered
and evaluated ALONG WITH NOT RATHER THAN efficiency and was not overly
directed at your proposal.  These criteria are also not typically
orthogonal,especially when congested traffic scenarios are tested.  It was
not an attack on CDS-DR, but a general point for further evaluation
consideration.  I agree with you that upcoming simulations will address this
more.

Because you weren't at the sit around meeting I think a lot of comments got
misinterpreted.
Many of the discussions were not intended as attacks on CDS-DR but were
mostly general comments on performance issues across algorithms.  Engineers
naturally sit around and ponder such things.  Another idea brought forward
"from some real world experience" was to possibly weight temporal neighbor
quality along with degree in the election process. Issues like that are
pretty much agnostic to the ultimate type of CDS algorithm and are sometimes
very implementation  and scenario specific.

-joe