Re: [Ospf-manet] URL for MPR-extension software

[Emmanuel Baccelli <[e-mail]>]

Richard,

We do think that our draft provides a standard way to get topology 
reduction, which is indeed present in none of the other drafts.
We showed during our last presentation at the IETF that topology 
reduction is at least as effective as adjacency reduction, if not more. 
This is the point that was made, based on the results we published.

The comparison of importance between topology reduction and adjacency 
reduction can be explained easily. Basically, without reductions:

- Each time a link comes up: local synchronization between the new 
neighbors has to take place, and new LSAs have to be flooded globally, 
to the whole OSPF area.

- Each time a link goes down: new LSAs have to be flooded globally, to 
the whole OSPF area.

In other words if we call f the frequency at which links come up, we 
have a synchronization rate equal to f and LSA generation rate equal to 
2f. Each synchronization costs N headers therefore f*N overhead rate. 
Each LSA flooding costs M_r*N/M retransmissions, where M is the average 
neighbor size, M_r is the number of retransmissions per neighborhood (in 
general M_r=4-10). Since the LSA contains the identifiers of M neighbor 
nodes, then the LSA overhead rate is 2f*M_r N which is larger than f*N 
(even if one considers the header cost versus identifier cost).

Obviously, the importance of reducing the occurence and the size of LSAs 
flooded globally is as important (if not more) as the task of reducing 
the cost of synchronizations that are done locally.

The solution specified by the MPR-OSPF draft is indeed simple as you 
pointed out, and we showed it works well. It features topology and 
adjacency reduction in a way compliant with traditional OSPF: routing is 
always done over synchronized links. This is not the case with other 
drafts. In particular, the adjacency reduction proposed in the MDR draft 
assumes the use of non synchronized links, which may create loops and 
out of track routing.

Emmanuel




Richard Ogier a écrit :
> Emmanuel Baccelli wrote:
> 
>> Hi Acee,
>> here is a link to the source code http://ndquan.free.fr/gtnets.tar.bz2
>> I must have missed Tom's post in the usual after-IETF email avalanche, 
>> sorry about that ;)
>> Emmanuel
> 
> Emmanuel,
> 
> I looked at your code.  It looks like all you did was modify Cisco's
> Overlapping Relay (OR) code to generate LSAs that include only MPRs
> and MPR selectors.
> 
> So, your GTNetS implementation is essentially just a modification
> or extension of Cisco's OR solution.  In particular, you have not
> implemented adjacency reduction based on MPRs, which is needed
> in order to compare your solution to the MDR and OR/SP
> solutions with adjacency reduction.
> As Boeing has shown, both adjacency reduction and LSA reduction
> are needed to achieve scalability to 100 or more nodes.
> Recall the 100-node example that would have 2384 adjacencies
> without adjacency reduction:
> http://www3.ietf.org/proceedings/05mar/slides/ospf-5/sld17.htm
> 
> When do you plan to release code that implements adjacency
> reduction based on MPRs, as described in your draft?
> 
> Since your GTNetS implementation is simply an extension of
> Cisco's OR implementation, this makes me think that a separate
> draft is not needed, i.e., that Cisco's OR draft and INRIA's
> draft can be combined into a single draft.
> Can you give any reason why this is not possible?
> 
> In any case, INRIA still needs to provide GTNetS code that
> implements their solution (including adjacency reduction)
> so that it can be compared to the other proposals.
> Without such a comparison, it is possible (and I think likely)
> that INRIA's solution will generate more than 10 times as
> much overhead as MDR in a dense 100-node network, possibly
> consuming all the network bandwidth.
> The burden of proof is on INRIA.  Unless they can provide
> evidence that their solution can support networks that are
> roughly as large as those supportable by MDR, then I don't
> think there is justification for accepting their draft as an
> experimental WG document.
> 
> I think we should set a deadline to share current GTNetS code
> before the next IETF meeting.  I plan to release updated GTnetS
> for MDR in mid February.  This will be able to support more
> than 100 nodes, using min-cost LSAs.  I hope that INRIA will also
> release code that includes adjacency reduction.
> 
> Richard
> 
> P.S. Regarding terminology.  The term "topology reduction",
> similar to "topology control", means that the actual network
> topology is limited, i.e., the set of bidirectional neighbors,
> or perhaps the set of adjacent neighbors.
> But if you are only reducing the set of neighbors that are
> advertised in LSAs, you are not reducing the topology, but
> are reducing the *advertised* topology.  Therefore, I prefer to
> call this LSA reduction.  Put another way, "topology reduction"
> is ambiguous because it can refer to the topology defined by
> bidirectional links, or by adjacencies, or by advertised links.
> 
> 
>>
> 
> 

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