Subject: RE: [Ospf-wireless-design] Design Team slides for IETF 63

From: "Joe Macker" <[email-masked]>
Date: Mon, 1 Aug 2005 15:06:56 -0400

Good work Tom:
 
Because there is a strong relationship with the manet WG there are other
possibilities for adapting portions of this work as well.

I think this design team made significant technical progress and I want to
congratulate everyone.

-Joe

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Henderson,
Thomas R
Sent: Friday, July 29, 2005 5:23 PM
To: [email-masked]
Subject: [Ospf-wireless-design] Design Team slides for IETF 63

All,
The design team is not meeting in Paris, due to lack of a quorum.  Acee
Lindem agreed to present the attached slides at the OSPF and MANET WG
meetings.  Any comments?

Currently, we have two fairly mature proposals for how to do OSPF MANET
extensions, and one public implementation of each.  As for next steps, you
will see a statement in the charts that we have not yet achieved consensus.
Acee indicated his preference to let the design team run for one more cycle,
possibly augmented by discussion on the regular MANET and OSPF WG lists.
Are there comments on this proposed approach?

Next week, we'll release the next version of our technical report and
software, internally to the design team, while we in parallel obtain
approval to circulate it more broadly.  I will try to create a smaller
document that (for now) summarizes the key simulation results and discussion
we have conducted here at Boeing.

Tom

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

---

From: Richard Ogier <[email-masked]>
Date: Mon, 01 Aug 2005 23:15:16 -0700

Tony Przygienda wrote:

> Henderson, Thomas R wrote:
>
>> All,
So, we currently have only one solution that scales to 100 nodes (and 
probably
to 300 nodes). So I wonder why the slides say the design team is
"struggling" to reach consensus on a single approach.
First of all, the design team needs to carefully read the proposals and
simulation results, and comment on them.  I am eager to answer questions
regarding my draft.  Suggestions for enhancements are also welcome.

Regarding the "Smart Peering" draft by Roy et al. Is the plan to allow
time for this new idea (which by the way is closely related to my
definition of a "routable" neighbor) to be developed into a fine tuned
implementation?  If this idea can be demonstrated in a short time, then
it might be worth considering.  But we have already delayed the decision
by several months, so I think we need to avoid dragging on indefinitely.

We need people to read and understand both proposals (including the
"Smart Peering"), and to discuss them here.  For example, I could discuss
why the MDR approach is more attractive than the Smart Peering approach
because adjacencies are aligned with (Backup) MDRs, just as adjacencies
are aligned with the (Backup) DR in OSPF.
In other words, the MDR approach is a more natural extension of OSPF.
We could also compare the performance, depending on how long it would take
to get Smart Peering to perform well.

To avoid further delays, until there is some evidence that Smart Peering
results in a solution that is as efficient and scalable as the MDR approach,
I would like to focus on improving the MDR draft. To that end, I welcome
your comments, suggestions, and questions.

One more comment below.

>>
>>  
>>
> From my meta-feeling and observation of proposals/discussion 
> frequency, methodology
> used, I think you are at the point where you should open your results 
> to a wider forum.
>
>> extensions, and one public implementation of each.  As for next steps,
>> you will see a statement in the charts that we have not yet achieved
>> consensus.  Acee indicated his preference to let the design team run for
>> one more cycle, possibly augmented by discussion on the regular MANET
>> and OSPF WG lists.  Are there comments on this proposed approach?
>>  
>>
> Again, I think you should release the software to a wider audience and 
> let people run their
> scenarios and provide you with results. This should give you  a good 
> indication what the
> consensus on the two proposals or a variation thereof should be beside 
> purely technical
> points that you seem have shaken out roughly and do seem to have a 
> struggle merging
> (again, from my understanding so far the two have different strengths 
> depending
> on the scenario assumed).  Then, IMHO you will be able to progress to 
> spec-stage work.

I don't think a major merging of the solutions would be appropriate or
beneficial, and it would cause further delay.  From page 10 of Tom's
presentation, both drafts perform comparably when full adjacencies are used
(which only allows scalability to about 50 nodes), but the MDR approach 
(which
uses partial adjacencies) scales to well over 100 nodes.
So I am not sure there is a scenario in which the overlapping relay
(OR) approach performs better.  However, I am open to incorporating
ideas from the other drafts into the MDR draft, as appropriate.  (In fact,
the MDR draft already incorporates the LLS and multicast ACK techniques that
were first used in the OR draft.)

Richard

>    --- tony

---

From: Acee Lindem <[email-masked]>
Date: Tue, 02 Aug 2005 10:00:20 -0400

>>> Lindem agreed to present the attached slides at the OSPF and MANET WG
Hi Richard,

> regarding my draft.  Suggestions for enhancements are also welcome.

The draft revision containing the technical details of your proposal 
just made the
IETF meeting cut-off (July 18th).  Hence, it is premature to say that 
reached
consensus. As Tom states in his slides, Boeing will soon make the full
report and GTNetS implementation available for evaluation.

> by several months, so I think we need to avoid dragging on indefinitely.

I see the fact that the proposals have similar components to be a good 
thing.
I read your draft on the plane and there are other similarities. For 
example,
the MPR approach uses Ack caching while the MDR proposal utilizes
a persistent per neighbor Ack list. Again, the more similar the 
proposals the
closer we are toward consensus.

>> Again, I think you should release the software to a wider audience 
>> and let people run their
>> consensus on the two proposals or a variation thereof should be 
>> beside purely technical
> (which only allows scalability to about 50 nodes), but the MDR 
> approach (which

In reaching consensus we may come up with a solution that contains  the best
elements of  both proposals. I hope that when you say you are willing to
modify your draft you are open to this option.

Thanks,
Acee