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

From: Aniket Desai <[email-masked]>
Date: Thu, 28 Sep 2006 10:32:05 -0400

Hi everyone,

It is perhaps not my forte to comment on very broad level design 
issues. Having said this, I will make use of the voice that has been 
granted to me. I simply want to say again that it is not necessary 
for the MPR solution to be the best fit for OSPF. I also find it 
difficult to understand the claim that MDR solution is complex; which 
it is not. It is actually a very elegant and natural extension design 
of legacy OSPF, 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 means a node determining whether it should be a leader and 
conditionally establishing adjacency relationships with a subset of 
its neighbors. The very concept of someone else signaling to you if 
you should be their caretaker is absent from OSPF. It works great for 
OLSR, but I have doubts if that can work for OSPF. In that case, 
adjacency graph will have no correlation with the forwarding graph, 
and I believe Dr. Ogier has repeatedly stressed this point on this forum.

I believe that the grief resulted from the flooding algorithm; which 
was indeed trying to "over-optimize". But I am sure it can be turned 
into an option. And as far as neighbor scanning goes, there is no 
getting away from it due to retransmissions. Not only that, any 
router must get its adjacent neighbors out of loading state; for 
which, it must scan all of them against each received new LSA anyway. 
So what is the problem? MDR flooding is not scaling from O (n) to O 
(n^2) or something. It is still O (n).

I feel that legacy OSPF by itself is a complex protocol. OSPF is 
complex because it seeks to synchronize a subset of neighbors of an 
interface, and any flooding procedure must account for that; because 
any new received LSA may be forwarded *AND* it may be an important 
piece in synchronizing any neighbor of that interface (section 13 of 
RFC 2328). Why was there an expectation that MANET flooding would be 
less complex than the legacy OSPF flooding? It is not appropriate to 
compare OSPF 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?

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.
My 2 cents. Thanks,

Aniket

P.S. BMDR is a one shot timer backup flooding. When a BMDR receives a 
new LSA, it decides to keep it in some temporary list which may be 
flooded. Then that BMDR examines all its bidirectional neighbors and 
creates an initial list of the neighbors which are not *covered* by 
the sender (or within 1 hop from the sender). Why? Because it makes 
sense to consider only the neighbors on which the sender has no 
control (via retransmission). When neighbors send acks, they are 
systematically taken out of the neighbor list, and if this list is 
empty before the timer expiry, BMDR suppresses the flood. Why do we 
need BMDR? a) What if the adjacency graph is very transient and not 
always connected? Some LSAs may be lost. b) Retransmission timer is too high.

>------------------------------
>
>Message: 6
>Date: Thu, 28 Sep 2006 14:33:18 +0200
>From: Philippe Jacquet <[email-masked]>
>Subject: Re: [Ospf-manet] Re: Ospf-manet Digest, Vol 9, Issue 11
>To: Russ White <[email-masked]>
>Cc: [email-masked]
>Message-ID: <[email-masked]>
>Content-Type: text/plain; charset=us-ascii; format=flowed
>
>Dear Russ and all,
>
>I feel that we should not systematically be against simulations in the
>standardization process. Simulations greatly help understanding complex
>problems. But I don't understand the claim that deploying a wireless OSPF
>might be more complex or more costly than deploying a Manet. 
>Moreover, there is a
>proposal which has hundreds of options (who has understood the BMDR stuff?)
>and most of them really look as if they were taylored for only one set of
>scenarios, in an unrealistic environment. This is definitely not a good way
>to design.
>
>A few years ago, the ospf WG discovered that usual ospf does not fit wireless
>ad hoc networking at all. Not surprising since manet WG has been 
>created exactly for solving this problem
>
>A few set of simulations provided by Boeing proved that a manet-based solution
>can solve the problem in a satisfactory way.  This is good news, but not
>surprising again, since manet WG has accumulated a considerable 
>experience on the
>subject, had expertized a large number of proposal, and is ready to 
>standardize
>two main routing schemes which are satisfactory to every one.
>
>A wireless-OSPF design team was then formed. At this time it was clear that
>the best, most efficient and fastest process was to select a manet 
>solution and to
>let it receive the appropriate "ospfication" in order to receive the WG
>blessing.
>
>At this precise moment things went wrong. For a reason that I will never
>understand a small subset of the design team, wrote a completely new
>draft directly from scratch which has never been deeply 
>experimented, neither in manet nor in ospf. Now we are wasting time 
>because there is no enough qualitative and quantitative feedback on 
>this proposal which is not mature, and worse: nobody is able to 
>understand how to cope with all its options and complexity issues.
>
>Last year a manet based solution has again been proposed for the 
>crucial problem
>of flooding. More robust, less complex, it provides equivalent and even better
>performance. And with the considerable advantage of being mature: it has been
>tested deeply in the past, in a huge number of scenarios, many of them having
>triggered some improvements to the scheme.
>
>The natural consequence should have been again to have taken this manet
>solution and to taylor it for OSPF. But we heard that we should not
>over-optimize and therefore we should push the freak. In my mind this is
>nonsense, since the MPR solution is not an over-optimization. There is no
>intricate options, it has no complexity issue, it just a simple and robust
>solution that have been tested over and over. So why shouldn't it be taken as
>the foundation of the wireless ospf extension?
>
>Instead of this we hear that manet-ospf has nothing to do with manet and that
>we have to solve different problems. I personnaly don't believe 
>this, because a
>pure manet solution showed that the problem can be solved and because a
>manet-based solution is already solving most of the problems.
>
>Of course there remains the option to exclude the word "MANET" from the name
>of the design team, if there is a consensus that it is indeed non related to
>manet extensions.
>
>Best regards,
>Philippe
>
>
>Russ White wrote:
>
> >-----BEGIN PGP SIGNED MESSAGE-----
> >Hash: SHA1
> >
> >
> >
> >
> >>>>>>Such networks are important, as are sparse networks and large
> >>>>>>diameter networks.  (Also, I see that Aniket explained how this
> >>>>>>optimization is important in hybrid networks.)
> >>>>>>
> >>>>>>
> >>Would you suggest that the OSPF WG adopt two proposals, one for each
> >>network situation, and some mechanism to move between the two?
> >>
> >>
> >>
> >>>My point was that the optimization helps performance the most in
> >>>networks with a small diameter.  But it does NOT hurt performance
> >>>in networks with a large diameter.  So this point cannot be used
> >>>to conclude that we need two protcocols.  OSPF-MDR was designed to
> >>>perform well in all scenarios.
> >>>
> >>>
> >
> >So, you believe that there is no requirement for optimization of
> >non-dense protocols, that accepting a solution that only optimizes one
> >problem, "as long as it doesn't harm other problems," is acceptable? Do
> >you have evidence that the other situations are never going to be
> >required or useful?
> >
> >And going back to my original point:
> >
> >It's inappropriate to put something on the standards track that has only
> >been tested in simulations. If there's not enough customer demand to
> >actually drive implementations that can be tested in real networks, then
> >there's not enough drive to move forward with a standards track
> >document, I would think.
> >
> >OTOH, if we really want to base standards track on simulations, then we
> >should go about the work of designing simulation reports to substitute
> >for implementation reports, and we should also ask for simulation
> >results for any other proposed modifications to OSPF. Do you care to
> >make the argument that simulations should always be accepted in lieu of
> >actual implementations?
> >
> >:-)
> >
> >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
> >
> >iD8DBQFFDvdNER27sUhU9OQRArnaAJ9VL/oh/PHoByOlIsAGqKQ+CvesagCfTkzg
> >8ywtkusjYGp/tZ9SjJt/KZg=
> >=GzXk
> >-----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
>
>
>End of Ospf-manet Digest, Vol 10, Issue 8
>*****************************************

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

---

From: Aniket Desai <[email-masked]>
Date: Thu, 28 Sep 2006 11:25:42 -0400

I completely agree that simulations cannot replicate reality to the 
last detail (one of the most important things they miss out is power 
drainage over a long period of time; and also somewhat abstracted 
physical layer multifading effects). However when there are 2 
proposals, which are so completely different from each other; it 
should definitely be possible to quantify their relative 
advantages/disadvantages by conducting detailed simulations. I am not 
saying that MDR must be elevated to the draft status, but at the same 
time, one cannot discount the value that simulations can provide. If 
by conducting simulations we find that there are *obvious* reasons to 
prefer A over B, that should be acceptable.

Thanks,

Aniket

---

From: Russ White <[email-masked]>
Date: Thu, 28 Sep 2006 17:00:24 -0400

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

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

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

- --

---

From: Russ White <[email-masked]>
Date: Thu, 28 Sep 2006 17:03:21 -0400

> I completely agree that simulations cannot replicate reality to the last
> detail (one of the most important things they miss out is power drainage
> over a long period of time; and also somewhat abstracted physical layer
> multifading effects). However when there are 2 proposals, which are so
> completely different from each other; it should definitely be possible
> to quantify their relative advantages/disadvantages by conducting
> detailed simulations. I am not saying that MDR must be elevated to the
> draft status, but at the same time, one cannot discount the value that
> simulations can provide. If by conducting simulations we find that there
> are *obvious* reasons to prefer A over B, that should be acceptable.

Sorry to disagree, but a simulation can tell you if something will work,
or not, given the simulation covers all possible network situations, but
the simulation can tell you little about real world performance.
Otherwise, people wouldn't like to bother building real networks to
test, just build a simulation, right?

Can you show me a series of tests showing simulations always mimic real
world behavior in all cases?

:-)

Russ

- --

---

From: Richard Ogier <[email-masked]>
Date: Thu, 28 Sep 2006 18:22:23 -0700

>thing as "electing a leader," so, again, this isn't a "natural" part of

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

>on the performance of MPRs is, unfortunately, not available for public

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

>iD8DBQFFHDfoER27sUhU9OQRAuSkAKD5k6Y04V78MTs3go2ChPQH9mWZ1wCgqN7B
>/0PTRhP6Vryw5WXr9jdykLg=
>=tT6r

---

From: Russ White <[email-masked]>
Date: Thu, 28 Sep 2006 21:38:09 -0400

> a broadcast network, so a MANET can be considered a generalization

You've made a logical leap that isn't warranted.

1. DR's support broadcast networks.
2. Single hop MANETs are essentially broadcast networks.
3. Therefore, MDR's are just an extension of DR's for the multihop case.

Since 2 says "single hop," 3 doesn't follow.

Second point: 2 isn't necessarily true. Thus, the entire concept of
"extending DR's" isn't necessarily the right one, anyway.

>> fair manner, as Boeing has been doing with GTNetS.

The only way to compare the solutions in a fair manner is in the real
world, not a simulator.

>> and as we gain experience with it, we can improve it.

What experience will we gain when there are no requirements for a
commercial implementation (beyond what's already been done) at this
time? Or do you know of a vendor that's just about to implement MDR's,
and ship it into a customer base? I certainly don't know of any; if you
do, please share it with the rest of us.

So, again--why should we push something into draft standard based on
simulation results, and with no commercial drive to implement anything
further than what's been implemented? So far, everyone has avoided that
question. We all want to talk about whether the simulation results show
x or y, or how we'll make faster progress, or how the design team said x
or y, etc, etc. No-one seems to want to talk about what the rush is to
go to a draft standard....

What you're saying is: "Let's go to draft standard, and let the draft
sit for three years, until someone implements it, then we can fix
whatever we find wrong with it, and create something else new if we find
it doesn't work in the real world the way we expect it to." That's
sounds an awful lot like an experimental draft to me, not a draft standard.

:-)

Russ

P.S. IMHO, the reason you have "rough consensus" is that most of the
people who disagree with this conclusion have been shouted down long
enough they no longer care what the IETF does in this area. This entire
argument has driven good technical people out of the process, because
they are tired of being pushed aside. That's flat wrong.

- --

---

From: Richard Ogier <[email-masked]>
Date: Thu, 28 Sep 2006 19:53:02 -0700

>Since 2 says "single hop," 3 doesn't follow.

I didn't say "Therefore".  I was not providing a proof!
My main point was that you said DRs are not a natural part of OSPF,
and I was simply pointing out what Aniket and I mean when we say
MDRs are a natural extension of DRs.  This is something that most
people see once they understand MDRs well.  If you want a proof that
MDRs generalize DRs, this results from the fact that the MDR selection
algorithm and DR election algorithm select the same routers as DR/MDR
and Backup DR/MDR when applied to a single-hop MANET, and the resulting
set of adjacencies is the same in both cases.

Richard

>do, please share it with the rest of us.
I know of military

>iD8DBQFFHHkBER27sUhU9OQRAnB+AKCfam6kooucurk0iZ5VATK6U4JxNgCg8kmJ
>PqY+yRY/vWrsPKqogcH7TqA=
>=UX5F

---

From: Philippe Jacquet <[email-masked]>
Date: Fri, 29 Sep 2006 11:51:00 +0200

Dear Aniket,

I thought I already gave a proof of the fact that in OSPF-MPR, LSA 
retransmission cost is O(1). Complexity issue is also important since 
autonomous systems may have limited processing power. It makes also a 
point if  an old well proved algorithm appears to be less costly and 
more performant than a new more intricate algorithm.

The proof is not really MPR related, it is just a consequence of 
multicast LSA retransmissions that I explained before. That way you 
don't need to browse your neighborhood to check who has acked and who 
has not, you simply need a counter.

I understand that you sugested Dr Ogier to include this feature in MDR 
(as another option?). If you think twice you will realise that the 
multicast LSA retransmission has also deeper consequences: it allows to 
make completely independent the flooding forwarding graph and the 
adjacency graph. You could have an MDR adjacency graph over the MPR 
flooding. 

Of course there will remain the problem of links advertizement and how 
to advertize links that are non synchronized, thing we don't do in 
OSPF-MPR, but this is at an another level of the protocol.

Best regards,
Philippe

Aniket Desai wrote:

> getting away from it due to retransmissions. Not only that, any router 
> must get its adjacent neighbors out of loading state; for which, it 
> must scan all of them against each received new LSA anyway. So what is 
> the problem? MDR flooding is not scaling from O (n) to O (n^2) or 
> something. It is still O (n).
>

---

From: Russ White <[email-masked]>
Date: Fri, 29 Sep 2006 08:45:55 -0400

>> set of adjacencies is the same in both cases.

Essentially, the language in use ("MDR's are a 'natural' extension of
OSPF") is biased, implying all the other proposals are not. Let's drop
calling anything a "natural" extension to OSPF, since it doesn't really
provide real meaning.

> do, please share it with the rest of us.

Which branch, unit, or project? Which SI?

Again, I know of no effort ot produce a commercial implementation beyond
what has already been implemented, so I don't see a rush to produce a
draft standard. I see a lot of reasons to go experimental, though.

:-)

Russ

- --

---

From: Richard Ogier <[email-masked]>
Date: Fri, 29 Sep 2006 10:24:53 -0700

Philippe Jacquet wrote:

> (as another option?).

Yes, although I first suggested it on 9/18/2006 as

> 4. Ack the first reception of an LSA, and ack any LSA received in an LSU
> that contains the router in the Ack list.  Retransmitted LSAs are 
> multicast. 

An LSA option bit can be used to indicate which LSAs are retransmitted,
and the neighbors that should Ack the LSA can be listed at the end of
the LSU packet.  It looks like you are assuming that *every* adjacent
neighbor must Ack *every* LSA, which is simpler but results in more
Ack overhead.  In any case, as you say, the choice to multicast
retransmitted LSAs is independent of whether you use MDRs or MPRs.
We can experiment with this technique and possibly include it in
a future version of the MDR draft.

> If you think twice you will realise that the multicast LSA 
> retransmission has also deeper consequences: it allows to make 
> completely independent the flooding forwarding graph and the adjacency 
> graph. You could have an MDR adjacency graph over the MPR flooding.

As previously discussed, making the flooding relays independent of the
adjacency graph could affect performance. (Also, using both MDRs and MPRs
would add complexity.) But this could be done whether or not retransmitted
LSAs are multicast.

Richard

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Fri, 29 Sep 2006 10:42:24 -0700

Richard Ogier wrote:

>> I understand that you sugested Dr Ogier to include this feature in 
>> MDR (as another option?).
>
>
>
>                                                         ^^^^^^^^^

Richard, it seems that the MDR draft is in perpetual change each time 
absorbing yet another optimization when
someone finds yet another "flaw".

To me this shows how much this is an experimental draft and it doesn't 
make sense to me to rush this into a
standard.

As far as rough concensus - I don't see one - in the light of extensive 
email threads and discussions in
various working groups.

Simulations are not real world implementations and  I thought that 
standards are about
real world implementations. My conclusion is - experimental drafts is 
the way to go.

Padma

>> completely independent the flooding forwarding graph and the 
>> Of course there will remain the problem of links advertizement and 
>> how to advertize links that are non synchronized, thing we don't do 
>> in OSPF-MPR, but this is at an another level of the protocol.
>>
>> Best regards,
>> Philippe
>>
>>
>> Aniket Desai wrote:
>>
>>>
>>> which, it must scan all of them against each received new LSA 
>>> anyway. So what is the problem? MDR flooding is not scaling from O 
>>> (n) to O (n^2) or something. It is still O (n).
>>>

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Fri, 29 Sep 2006 12:09:02 -0700

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

Russ,
I can't really hold my tongue any longer.  IMO, this experience has
illustrated some of the worst aspects of IETF:
i) WG and ADs agreed to form a design team to find a consensus technical
approach
ii) design team tried to set up a level playing field for evaluation
iii) a consensus (not 100%, but many of the people deeply involved in
the discussion) emerged on a basic framework for a design, after a lot
of deliberation and technical work.  
iv) people who disagreed with the outcome have not been "shouted down",
rather they have been encouraged to produce independently verifiable
technical evidence that counters the consensus and what is out there in
public for review, but they have so far refrained from doing so,
preferring instead to undermine the process, including ad hominem
attacks and pleas of victimization.

It is really somewhat pathetic that you will sit there and reject
out-of-hand the work that has been done in full public view, while
asking everyone to "trust you on it" that you have all of this good
experimental experience with your approach, but you unfortunately cannot
share any of it or submit it for independent verification.   How can you
claim that technical people are driven out of the process when you won't
even participate technically?  Yet we are supposed to hold up progress
after years of deliberation because e.g. (as one objector put it to me
privately) "it just doesn't seem like the right design to me, but I
can't put my finger on exactly what makes me uncomfortable".  How long
are we supposed to wait around?

I've been sitting back on this debate for a while now because it is not
clear to me whether it is worth my time any more; if there will be a
decision based on technology reasons, I'd be happy to participate
further, but if the decision is that one vendor has implemented their
approach and they don't see any reason to switch and will just make sure
that the outcome will eventually bless it as the standard, why bother?

As to your question on why we are trying to make a decision now, it is
because we were explicitly asked to do so by the AD (Bill) who I believe
went to the mike in Dallas and told the WG to stop spinning with
multiple approaches and that "if you do not make a choice, we will, even
if we have to flip a coin."  So maybe you should take your protests to
the leadership.

Tom

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Fri, 29 Sep 2006 13:58:27 -0700

Philippe, response below:

> From: Philippe Jacquet [mailto:[email-masked]] 
> Sent: Friday, September 29, 2006 2:51 AM
> To: Aniket Desai
> Cc: [email-masked]
<snip>
> adjacency graph. You could have an MDR adjacency graph over the MPR 

I agree that one can have an MDR adjacency graph over the MPR flooding.
The converse is not as practical, I hope you would agree. The question
is then why would you need to have separate MPR flooding if you have
already the MDRs there for another purpose?   Is it worth having two
when one will suffice?  In a nutshell, that is why I have favored the
MDR design approach, because it seems to me that the delta between MPR
and MDR flooding performance is not going to be significant, while the
delta between MPR and MDR adjacency graph is significant because of the
MPR/selector asymmetry.

Tom

---

From: Aniket Desai <[email-masked]>
Date: Fri, 29 Sep 2006 17:02:59 -0400

Hi,

Multicasting retransmitted LSAs is not a "flaw" in MDR draft. It is a 
modular function that; if anything; can benefit any OSPF 
implementation (even the wired one). Whether it is an MDR or an MPR 
solution; they all can use the same. I think the criterion for 
distinguishing the solutions is set to flooding and adjacencies (or 
maybe only flooding). Retransmissions are secondary as they all can 
use the same scheme.

Sincerely,

Aniket

At 01:42 PM 9/29/2006, Padma Pillay-Esnault wrote:
>>>retransmission cost is O(1). Complexity issue is also important 
>>>since autonomous systems may have limited processing power. It 
>>>makes also a point if  an old well proved algorithm appears to be 
>>>less costly and more performant than a new more intricate algorithm.
>>>
>>>multicast LSA retransmissions that I explained before. That way 
>>>you don't need to browse your neighborhood to check who has acked 
>>>and who has not, you simply need a counter.
>>>
>Richard, it seems that the MDR draft is in perpetual change each 
>time absorbing yet another optimization when
>To me this shows how much this is an experimental draft and it 
>doesn't make sense to me to rush this into a
>standard.
>
>As far as rough concensus - I don't see one - in the light of 
>extensive email threads and discussions in
>various working groups.
>
>real world implementations. My conclusion is - experimental drafts 
>is the way to go.
>
>Padma
>
>>>adjacency graph. You could have an MDR adjacency graph over the MPR flooding.
>>
>>
>>
>>>how to advertize links that are non synchronized, thing we don't 
>>>do in OSPF-MPR, but this is at an another level of the protocol.
>>>
>>>Best regards,
>>>Philippe
>>>
>>>
>>>Aniket Desai wrote:
>>>
>>>>
>>>>I believe that the grief resulted from the flooding algorithm; 
>>>>which was indeed trying to "over-optimize". But I am sure it can 
>>>>be turned into an option. And as far as neighbor scanning goes, 
>>>>there is no getting away from it due to retransmissions. Not only 
>>>>that, any router must get its adjacent neighbors out of loading 
>>>>state; for which, it must scan all of them against each received 
>>>>new LSA anyway. So what is the problem? MDR flooding is not 
>>>>scaling from O (n) to O (n^2) or something. It is still O (n).
>>>>
>>>>complex because it seeks to synchronize a subset of neighbors of 
>>>>an interface, and any flooding procedure must account for that; 
>>>>because any new received LSA may be forwarded *AND* it may be an 
>>>>important piece in synchronizing any neighbor of that interface 
>>>>(section 13 of RFC 2328). Why was there an expectation that MANET 
>>>>flooding would be less complex than the legacy OSPF flooding? It 
>>>>is not appropriate to compare OSPF 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?
>>>
>>>