Subject: RE: [Ospf-manet] Re: Ospf-manet Digest, Vol 10, Issue 8

From: "Stan Ratliff \(sratliff\)" <[email-masked]>
Date: Thu, 28 Sep 2006 21:31:16 -0400

Richard, 
 
>We should be able to achieve rough
>consensus on a single solution (and I think we already have).

I think the email thread of today (indeed, the extended thread
of the past few months) belies that statement. 

Regards,
Stan

-----Original Message-----
From: Richard Ogier [mailto:[email-masked]] 
Sent: Thursday, September 28, 2006 9:22 PM
To: Russ White
Cc: Aniket Desai; [email-masked]
Subject: Re: [Ospf-manet] Re: Ospf-manet Digest, Vol 10, Issue 8

Russ White wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>>which is tailored specifically for MANET like environment. I feel that
>>OSPF is all about creating a connected/biconnected adjacency graph wih
a
>>few *leaders* that are responsible for maintaining this graph by
>>creating systematic relationships with a subset of their neighbors.
Not
>>only that, but these leaders are also responsible for forwarding LSAs
>>along the adjacencies. This is what MDR draft boils down to.
>>
>
>>>One may choose different algorithms for selecting parents/dependents
and
>>>even the MDRs; but the fact is; the *natural MANET OSPF* extension 
>>>a node determining whether it should be a leader and conditionally
>>>establishing adjacency relationships with a subset of its neighbors.
The
>>>
>
>Actually, DR's are a solution to a specific problem in OSPF, not a
>"natural part of the protocol." You can remove DRs from OSPF, and it
>will still work just fine. On point to point links, there's no such
>thing as "electing a leader," so, again, this isn't a "natural" part of
>OSPF.
>

You are saying that DRs are not a natural part of OSPF.
That is not the point at all.
DRs are an important part of OSPF for supporting broadcast
networks in a scalable manner.
MDRs are a natural way to generalize DRs to support multi-hop
wireless networks.  Note that a single-hop MANET is essentially
a broadcast network, so a MANET can be considered a generalization
of a broadcast network.
http://www3.ietf.org/proceedings/05nov/slides/ospf-3/sld2.htm

>
>
>>MANET flooding to OLSR flooding; because afterall; this is *OSPF*. I
am
>>still unable to understand how using MPR solution would reduce the
>>flooding algorithm to O (1) as has been implied again. I will be
>>extremely happy to study the draft carefully still; if it was
available!
>>I would seriously like to know if I am missing anything?
>>
>
>I'm certain someone on list could provide you with a copy of the draft.
>
>As to the question: I suppose the counter question is simple: It
doesn't
>matter what the "degree" is if it works, and has been shown to work, in
>the real world. At one point, you argue against "overoptimizing," but
at
>the other, you argue that "one is more optimal than the other, so we
>should choose the more optimal."
>
>Which is it? As for "more complex," I consider changing a single timer
>much less complex than changing the entire DR infrastructure. Others
may
>differ in their view, but timer changes have always seemed simpler to
me
>than doing all sorts of elections, etc., and less prone to error and
>failures.
>
>>It is a great thing that there are so many options. I feel that having
>>more options is better than having a few. Finally, I would again like
to
>>know (it may be my lack of knowledge or experience) how and where MPR
>>solution has been tested in OSPF context; and if so; where is the data
>>that compares it against the MDRs.
>>
>
>MDRs haven't ever been implemented, so there's no comparison. The data
>on the performance of MPRs is, unfortunately, not available for public
>dissemination.
>

As has been discussed, MDRs have been implemented in Quagga,
and the same code is used in the GTNetS simulator.
There has been plenty of opportunity to implement MPRs in GTNetS so they
can be evaluated in a fair manner.  That has been the plan all along.
As others have said, simulations are not perfect, but they are helpful
and are preferable to "verbal jousting".
Note that, contrary to Philippe's claims, Boeing has conducted
simulations using a wide variety of scenarios, including both
sparse and dense networks.

I suspect that some people are avoiding implementing their solution
in GTNetS (and resort to verbal jousting) because they are afraid the
simulation results will not favor their solution.  These people
might run their own simulations to make sure the results favor
their solution.  We need to compare the solutions in a
fair manner, as Boeing has been doing with GTNetS.

I think it is better to focus on a single solution, rather than
have two experimental RFCs.  We should be able to achieve rough
consensus on a single solution (and I think we already have).
We will make faster progress if we focus on a single solution.
The MDR draft is not perfect, but is a good starting point,
and as we gain experience with it, we can improve it.

Richard

>
>
>Again, if we have so little information, and no drive to commercially
>implement anything new, then why the drive to push one draft to draft
>standard? I've not yet seen an answer to this question on list.
>
>:-)
>
>Russ
>
>- --
>[email-masked] CCIE <>< Grace Alone
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.2.2 (MingW32)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
>iD8DBQFFHDfoER27sUhU9OQRAuSkAKD5k6Y04V78MTs3go2ChPQH9mWZ1wCgqN7B
>/0PTRhP6Vryw5WXr9jdykLg=
>=tT6r
>-----END PGP SIGNATURE-----
>
>_______________________________________________
>Ospf-manet mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ospf-manet
>
>

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

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