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

[Russ White <ruwhite at CISCO.COM>]

> "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?

"Full state" should probably be changed here. It's actually the full change
state, or rather all the changes occurring since the last SCS change.

> 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.)

If you do this, you don't need the sequence numbers at all. I'm concerned
about this on several fronts, though....

First, if you are losing two out of three hellos on a regular basis, the
link quality is likely to be so low that it's unusable for passing data
traffic. Second, even if you lose two out of three hellos, you must also
always miss the specific hello with a state change. So, the only place I
see advertising all state changes for three hellos as being more efficient
than the incremental hello mechanism outlined in the draft is this: If you
always have a state change in at least one out of every three hello's, and
the hello with the state change information is always lost. While this
seems possible in some short term situations, I find it stretching to think
this would happen so consistently that it's always better to send the state
change information three times.

> 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.)

?? Then how does TBRPF form an adjacency in this situation?

A---B

A sees B, but B doesn't see A. This condition lasts for 90 seconds, long
enough for A to report B, without B seeing A's hello's. Now, B moves
somewhat closer, and starts reporting A in it's hellos. Of course, at this
point, B has no idea A can see it, and thus two way state will never be
reached.

If there's a solution to this, then we could easily adapt it to the
incremental hello solution, as well, just for one-way neighbors, without
using the "advertise three times and drop" rule. You could state that as
soon as A sees its own router id in B's hellos, it begins to advertise in
its hello's until full state is reached. Note you couldn't use the three
anddrop rule in this case, because it's entirely possible the first three
hello's A originates with B's router id before two way state is acheived
could be dropped, thus leaving the two devices forever in one way state,
with no way out.

> 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).

?? The normal OSPF flooding rules are applied here, so you would not get
into a flooding loop.

:-)

Russ

__________________________________
riw at cisco.com CCIE <>< Grace Alone