Comments on draft-chandra-ospf-manet-ext-01.txt

[Richard Ogier <ogier at EARTHLINK.NET>]

I have some comments and questions for the draft
draft-chandra-ospf-manet-ext-01.txt.
(Unfortunately, I could not make it to the meeting this week.)

I see that the following requirement has been added to 2.3.5:

"The first Hello packet with a particular SCS number MUST contain the
full state associated with that SCS number, and thus MUST NOT set the
'N' bit in the State Check Sequence TLV."

Assuming that the Hello is multicast to all neighbors, does the
"full state" include all neighbors?  Or does it include
only the neighbors that recently changed state?

If the former is the case, then the Hellos are not incremental.
If the latter is the case, then I am not sure exactly
how "full state" is defined for an incremental Hello.

From Section 2.3.6 (Receiving Hellos), I see that the initial
Hello for a new SCS number (with the N bit not set) must
be received correctly by all neighbors, and a neighbor must
send a Hello request if it discovers that it missed the
initial Hello for a given SCS number.
This concerns me, because in a MANET, a node will typically
miss a large percentage of Hellos, and thus will have to
unicast a large number of Hello requests to each neighbor.

It is possible to design the Hello protocol so that it is
OK to miss 2 out of 3 Hellos (for example) without having
to send a Hello request. TBRPF (RFC 3684) does by reporting
each neighbor change in 3 (or k) consecutive Hellos, so that
each neighbor will either learn about the state change,
or will declare the neighbor lost after missing 3 consecutive
Hellos from the neighbor. (To detect this, the Hello sequence
number is incremented with each transmitted Hello.)

Another issue is that, because different nodes can have different
transmission ranges, it is possible for a node to have many 1-way
neighbors that never become 2-way. Unfortunately, your incremental
Hellos will have to report all of these 1-way neighbors forever
in Hellos. In TBRPF, when a 1-way neighbor is discovered, it is
reported in at most 3 Hellos. (The correctness proof for TBRPF
shows that this works, and TBRPF has been throroughly tested.)

I am not trying to promote TBRPF, but am just pointing out some
potential advantages of the TBRPF Hello protocol.
Perhaps simulations should be conducted to compare these two
methods for using incremental Hellos.

I have a few additional quick comments on the draft.

There is a typo in the last bullet of 2.3.4.2:
"I bit" should be "N bit".

In Section 2.4.7 (Flooding and Relay Decisions), the first step
upon receiving an LSA from an adjacent speaker is as follows:

1.   If the node is an active overlapping relay for the adjacent
    speaker, then the router MUST immediately relay any information
    received from the adjacent speaker.

This could cause inifinite looping, since two nodes could be
overlapping relays (MPRs) for each other. I guess you mean either:
(a) the LSA is relayed if it has not already been relayed, or
(b) the LSA is relayed if it has not already been received.
The inefficiency of doing (a) has already been discussed on
this mailing list, as well as the possible incorrectness of
doing (b).

My final comment regards the use of MPRs instead of a CDS
for flooding.  This choice has been discussed, and I think
this is still an open question, but let me know if you have
concluded that MPRs is preferable.
As a review, I will list some advantages of using a CDS:

1. A CDS is simpler and is a more natural generalization of
  a DR, since each CDS node relays all LSAs (independent
  of which neighbor the LSA was received from).

2. Each node can decide whether it is a CDS node based only
  on Hellos and LSAs originated from neighbors, without having
  to compute MPRs, or to add a new TLV to report MPRs. (The DR field
  of a Hello can be used to identify a CDS node instead.)

3. A full adjacency needs to be established only between
  each CDS node and its neighbors.

Regards,
Richard Ogier