Subject: RE: [Ospf-manet] URL for MPR-extension software

From: Emmanuel Baccelli <[email-masked]>
Date: Wed, 20 Dec 2006 10:19:03 +0100

Richard,

Adjacency reduction is indeed an interesting approach that is present in 
various ways in the three solutions OR, MPR and MDR. The specificity of 
the MPR solution is that it brings topology reduction too,  in a way 
compliant with the usual "route on adjacencies only". The draft and the 
code we released shows that the MPR solution is simple and valid.

You say you still need to experiment with your code, and we all need to 
experiment with the code. I agree: that is why the three solutions are 
going to experimental status, as decided by the working group. So I 
don't understand where you are getting at?

By the way, regarding adjacency reduction, it must be pointed out that 
contrary to what you claim the available code for the MPR solution is 
compliant with the draft, since adjacency reduction is specified as 
optional.

Regards,

Emmanuel

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

---

From: Richard Ogier <[email-masked]>
Date: Thu, 21 Dec 2006 11:17:49 -0800

Emmanuel,

You are STILL avoiding my main question:
When do you plan to release code that implements adjacency
reduction based on MPRs, as described in your draft?

Emmanuel Baccelli wrote:

> Richard,
>
> Adjacency reduction is indeed an interesting approach that is present 
> in various ways in the three solutions OR, MPR and MDR. The 
> specificity of the MPR solution is that it brings topology reduction 
> too,  in a way compliant with the usual "route on adjacencies only". 
> The draft and the code we released shows that the MPR solution is 
> simple and valid.

Right, but your method for MPR-based adjacency reduction is not competitive
with the other proposals, since it will not scale nearly as well.
This is probably why you are not presenting any results for adjacency
reduction, and did not include adjacency reduction in your code.

>
>
> You say you still need to experiment with your code, and we all need 
> to experiment with the code. I agree: that is why the three solutions 
> are going to experimental status, as decided by the working group. So 
> I don't understand where you are getting at?

I don't think it has been decided that all three solutions are going to
experimental status.  See Acee's post to the OSPF list on 11/13/06
and Tom Henderson's response on 11/14/06.  You need to provide simulation
code (including adjacency reduction) so we can evaluate your proposal to
see if it is competitive with the other proposals.
I don't think it would be fair to give you a "free pass".
(I worked very hard in the last two years to design OSPF-MDR and show
it scales to more than 100 nodes.)

> compliant with the draft, since adjacency reduction is specified as 

As I mentioned, your method for LSA reduction can be applied to the other
proposals, and in fact your GTNetS code simply modified Cisco's OR solution
to use MPR-based LSAs.  Adjacency reduction is an important feature of your
proposal.  The other two drafts have been fully implemented in GTNetS, 
without
omitting any important features.  (Adjacency reduction will also be optional
in OSPF-MDR, so does that mean I don't have to implement it?) If you want to
omit adjacency reduction from your draft, and propose only a method for LSA
reduction, then that might be a possibility.  It would not scale to 
nearly as
many nodes as the other proposals, but as I mentioned, it can be applied to
the other proposals.

Richard

---

From: Richard Ogier <[email-masked]>
Date: Thu, 21 Dec 2006 16:50:08 -0800

A few more points...

> too,  in a way compliant with the usual "route on adjacencies only".

The above statement is misleading or incorrect in a number of ways.
OSPF does not "route on adjacencies only".   You know this since
your draft states:

>    Similarly to the broadcast interface, the next hop in the
>    forwarding table may be a neighbor that is not adjacent.  However,
>    when a data packet is further than its first hop, the MPR selection
>    process guarantees that the next hops in the SPT will be over
>    adjacencies.

Even if the rule is "route on adjacencies except for the first hop",
this is not true for OSPF, since an intermediate hop can also be
over a non-adjacent link.  But each hop is at least indirectly
synchronized in OSPF, which is NOT true for your proposal.  This
is why you need something like the concept of "routable" neighbors,
used by the other proposals.

So, you can't claim that your solution is "compliant with the
usual route on adjacencies only" rule, since OSPF has no such
rule.  OSPF does require that each hop, including the first hop,
be indirectly synchronized, and the concept of "routable neighbors"
is used to achieve this in OSPF-MDR.  But your solution does not guarantee
that the first hop is even indirectly synchronized (e.g., following
the recovery of a network partition), although you could add this
requirement.

Your solution does result in more hops being directly synchronized,
but as a result you lose scalability.

Richard