Subject: Re: Proposal for OSPF MANET Extensions Design Points

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 20 Jan 2004 17:11:26 -0800

> -----Original Message-----
> From: Richard Ogier [mailto:[email-masked]]
> Sent: Tuesday, January 20, 2004 4:41 PM
> To: [email-masked]
> Subject: Re: Proposal for OSPF MANET Extensions Design Points
> 
> 
> I agree that a design with fewer changes to OSPF is preferable if
> it results in similar or better performance.
> 
> Based on your positive comments regarding the idea
> (from Section 5 of draft-ogier-manet-ospf-extension-00.txt)
> of dynamically deciding when to suppress ACKs for a particular
> LSA based on how frequently the LSA is being updated
> (using an exponential moving average and hysteresis),
> I assume that you agree that suppressing ACKs in
> this manner is a good way to achieve periodic, unreliable
> flooding of LSAs (whether this is done for all LSAs or only
> for LSAs that are being updated frequently).
> 
> Therefore, this supports my claim that the Link State Flood
> (LSF) message that you introduce in your solution is not
> required.  

"I think it is a promising idea" != "I agree that it is better".
We're presently studying this specific issue more carefully
to understand exactly how and how well it might work.
Are you not doing the same, or have you already convinced
yourself?  Do you intend to prepare a more complete proposal
on how the timers are adjusted?

> In other words, before adding new message types,
> you should try to use existing OSPF mechanisms as much
> as possible.  Your LSF message contains a new "flooding
> sequence number" to detect duplicates, but OSPF already
> detects duplicate LSAs using the LS sequence number.

The LS sequence number is not sufficient to prevent 
multi-hop broadcast messages from recirculating.  They are 
tied to the LSAs.  LSF sequence numbers are tied to the 
originator's IP address.

> 
> In an effort to make some progress, I would like to
> focus on this aspect of your solution (the LSF message)
> and try to reach an agreement on whether or not
> the LSF message is required.
> 
> I can think of two other reasons why the LSF message might
> be needed. One of these is given in Step 2.1 in Section 13.1
> of your draft, where the "default route bit" of the LSF
> is set to indicate a default route (to avoid flooding
> outside LSAs within a stub wireless network).
> However, as we discussed and agreed on the MANET list,
> the same effect can be accomplished by using an OSPF stub area
> as specified in Section 12.4.3.1 of RFC 2328.
> 
> Another possible need for the LSF message is to perform flooding
> via MPRs, since an LSF is forwarded only if it was received from
> an MPR selector. There are two questions:
> 
> 1. Do we want to use MPRs to flood LSAs?
> 2. If the answer is yes, then can MPR flooding of LSAs
>    be done without using the LSF message?
> 
> I am proposing that LSAs be flooding using a connected
> dominating set (CDS) rather than MPRs, because it is simpler
> and closer to OSPF: each CDS node is responsible for
> forwarding all LSAs, whereas each MPR would be reponsible for
> forwarding only a subset of LSAs which must somehow be defined.
> 
I agree that CDS is an alternative to MPRs.  As Philippe pointed
out previously, MPRs are related to CDS.  If CDS provides a cleaner
complete implementation, then I would be for it.  I haven't seen
the complete picture yet, though.

Tom

---

From: Richard Ogier <[email-masked]>
Date: Tue, 20 Jan 2004 21:44:12 -0800

Tom,

Henderson, Thomas R wrote:

>yourself?
I'm glad you are studying this issue.  I have studied it sufficiently to
convince myself
there is no need to introduce a new message type.  Once you convince
yourself that
OSPF will perform periodic, unreliable flooding if ACKs are suppressed,
it is not
difficult to see that LSF messages are not needed (after considering the
other
points in my message) and are not likely to improve performance very much.

I have no reason to consider adding a new message type unless there is
reason to
believe it will improve performance significantly, and I see no reason
why it would
improve performance significantly. Can you give me such a reason?
Since we are trying to minimize changes to OSPF, I guess the burden of
proof is
on the person proposing to change OSPF (assuming that the change is
not really necessary but might improve performance).

>Do you intend to prepare a more complete proposal
Yes, but you are welcome to do this too.  It is fairly straightforward
(based on
exponential moving averages) but there are some alternative design choices.
For example, RFC 2328 (A.3.5) says that retransmitted LSAs are always
unicast
to each neighbor that did not ACK, but in a MANET it is probably better to
multicast retransmitted LSAs to all neighbors if several neighbors did
not ACK.
If we come up with the same design, that would be fine.  Otherwise, it will
be nice to have alternative designs to compare and eventually merge into
a single design.

>tied to the LSAs.  LSF sequence numbers are tied to the
But each LSA contains the LS sequence number *and* the advertising router
(originator). Can you explain or give an example to show that the LS
sequence
number is not sufficient to prevent LSAs from recirculating?  I am
really just talking
about the way OSPF already does flooding, so this should not be a problem.
I guess you are talking about your flooding mechanism using the LSF message,
but my point is that LSF messages are not needed.

Richard

Tom