Re: [Ospf-wireless-design] Design team outbrief (draft slides) posted

[Richard Ogier <[e-mail]>]

Henderson, Thomas R wrote:

> 
> 
>
>>This bullet on page 17 of your slides bothers me:
>>
>>>Emmanuel Baccelli stated that MPR flooding offers better properties 
>>>than CDS flooding, with at least as good topology reduction 
>>>capabilities, and better routing stretch performance
>>>
>>
>>Emmanuel may have "stated" such things, but Phil and I 
>>clearly pointed out that some of his statements were 
>>incorrect and based on a lack of understanding of the MDR 
>>approach. Therefore, one may say that your bullet is the 
>>truth, but not the whole truth.  You could add something like:
>>"Phil and Richard pointed out that Emmanuel's statements were 
>>not justified and Emmanuel did not dispute this."  OK, so 
>>this may be biased in the other direction, but I am making a point.
>>
>
>I am trying to represent the range of opinions expressed without passing
>too much judgement on whether claims have been substantiated.
>

Still, I think it would be misleading not to at least point out the fact
that the min-cost LSAs of OSPF-MDR also avoid route stretch, just as 
MPRs do.
This is not passing judgement, but is a simple, clear fact that Phil has
expressed, and which Emmanuel was not aware of.  Or you can say it is
another relevant claim made by Phil and me (without passing judgement).

I have some additional comments on Cisco's simulation results,
and some comments on consensus (below).

In the simulations for Smart Peering, what neighbors were included in
the router-LSAs?  If only adjacent neighbors were included,
then that could explain the lower overhead obtained for Smart Peering,
and would also result in highly suboptimal paths
(much longer than shortest paths).  That is why simulation
results are not very meaningful unless other measures such
as average path length and delivery ratio are also presented.
(The average path length can be obtained from the numbers of UDP
packets sent/forwarded/received, but I did not see those numbers.)

Also, since Cisco is running SPF twice, once for real adjacencies
and once for all acceptable links, I would like to know how
a router knows which non-local links are real adjacencies.
Does the LSA somehow indicate this?  Is a different Link State ID
used for real adjacenies versus non-adjacencies?

Also, I want to point out that other methods for selecting
MDRs are being considered (including MPR pruning as has been
discussed) which might result in fewer MDRs and adjacencies,
especially in sparse networks.

For example, as I suggested to Tom and Phil a few months ago,
the idea of Smart Peering can be used to reduce the number of
adjacencies in OSPF-MDR.  In this modification, another TLV
is defined for Hellos which indicates which neighbors are adjacent,
to provide 2-hop adjacency information.  Adjacencies are still formed
only between (Backup) MDRs and their neighbors, but a new adjacency is
suppressed if the 2-hop adjacency information indicates that an
adjacency path of at most 3 hops exists to the neighbor under
consideration.  I have not yet incorporated this enhancement, because
I was not sure it would be worth the added complexity, and didn't
know that Cisco was working on an enhancement to Smart Peering.
Note, however, that the enhancement to Smart Peering also adds
complexity, since it requires running SPF on two different
topology graphs.

Regarding consensus, it appears to me that we have a deadlock,
since each team has their own solution that they want to win.
One way to break the deadlock is to trust the opinion of the
person that we chose to lead the team because of his fairness
and neutrality.
Or we can continue the race for a few more months (perhaps
with a deadline) and hope it will become more clear which
approach is preferable.  Performance is an important criteria,
but other qualities are also important, such as minimizing
the changes to OSPF and maintaining the same philisophy as OSPF.

Richard



>
>



_______________________________________________
Ospf-wireless-design mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ospf-wireless-design