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

["Spagnolo, Phillip A" <[e-mail]>]

All,

I guess it is time to bring up the controversial subjects, so we can
eventually reach consensus. :)

I am of the opinion that the core mechanism of source independent
flooding in the MDR approach is more conducive to reducing the number of
adjacency in the OSPF framework (extension of DRs in a broadcast
network).  (B)MDRs provide a nice backbone which enable proficient
flooding, database synchronization with reduced adjacencies, and a range
of LSA fullness options.  The adjacency reduction distinction is
important because the pure flooding optimizations are about the same
(the data suggests this and I think we all agree). 

However, I also see how certain items in each draft are modular and can
be used with either approach (backup relays, diff/increm hellos, 2-hop
neighbor info advertisement, etc.).  

Specifically, I don't see a clear winner on how to do backup/pushback
relaying.  The ORs design requires an ack to be received by each
adjacent neighbor for the flooded LSA while the MDRs design requires an
ack or hearing a flood of the LSA to all covered neighbors.  The result
is that ORs have more backup floods while MDRs have more retransmissions
due to the loss of the first flooded LSA.  If the design team would like
to compare these mechanism, I don't see any reason why the pushback
mechanism is precluded from the MDR approach or the backup mechanism is
precluded from the OR approach.

Phil


> -----Original Message-----
> From: Acee Lindem [mailto:[e-mail]] 
> Sent: Tuesday, August 02, 2005 7:00 AM
> To: Richard Ogier
> Cc: [e-mail]
> Subject: Re: [Ospf-wireless-design] Design Team slides for IETF 63
> 
> 
> Richard Ogier wrote:
> 
> > Tony Przygienda wrote:
> >
> >> Henderson, Thomas R wrote:
> >>
> >>> 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? 
> >>
> >>
> Hi Richard,
> 
> > 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.
> 
> 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.
> 
> >
> > 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.
> 
> 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.
> 
> >
> > 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.
> >>
> >>> 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?
> >>>  
> >>>
> >> 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.)
> 
> 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
> 
> 
> 
> >
> > Richard
> >
> >
> >>
> >>
> >>    --- tony
> >>
> >>
> >>
> >> _______________________________________________
> >> Ospf-wireless-design mailing list
> >> [e-mail]
> >> https://www1.ietf.org/mailman/listinfo/ospf-wireless-design
> >>
> >>
> >
> >
> >
> > _______________________________________________
> > Ospf-wireless-design mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/ospf-wireless-design
> >
> 
> _______________________________________________
> Ospf-wireless-design mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ospf-wireless-design
> 

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