Re: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, Issue 2

[Richard Ogier <[e-mail]>]

Acee,

Acee Lindem wrote:

> All,
>
> I'm not sure extending the discussion longer will yield a consensus.
> I don't know what other parties who have not joined the discussion 
> will join
> or what new information will move the WG toward a single approach. I may
> be wrong but I believe all the people who are familiar with two 
> approaches
> are subscribed to this list. As I believe it was Joel who stated, 
> there are
> many factors involved with what does or doesn't become a standard.
>
> I also think both of these drafts have received sufficient review and
> scrutiny of the design team to be experimental OSPF WG drafts. There are
> those who may disagree but I could possibly see these being positioned
> as a simple approach (MPRs) and dense topology optimal approach (MDRs).


I really don't believe the MPR approach is simpler than the MDR
approach, assuming that smart peering is used for adjacency
reduction to achieve scalability.  I provided some evidence
in my last post to support this belief (e.g., smart peering
would also have to compute disjoint paths to all neighbors
if biconnected adjacencies are desired).
(We can debate this issue in more detail if you think
it is important to agree on this now.)

Therefore, I don't think it is appropriate to position
the MPR approach as the simple approach.

I think the main difference between the two approaches
is as follows:

- The MDR approach uses a source-independent CDS which
  generalizes the DR.  (For scalability, adjacencies are reduced
  based on the MDRs/BMDRs, similar to the way adjacencies are
  reduced based on the DR/BDR in an OSPF broadcast network.
  However, adjacency reduction is optional.)

- The MPR approach uses source-dependent MPRs.
  (For scalability, adjacencies can be reduced using smart
  peering, which is based on connectivity via synchronized
  adjacencies and is not based on MPRs.)

I think the two approaches have about the same complexity.
Also, I think Boeing's simulation results show that MDRs
perform as well as MPRs even in sparse topologies, so
it would not be appropriate to position MPRs for sparse
and MDRs for dense topologies.

Richard

>
> As I previously stated, the main drawback I see is that future OSPF MANET
> optimizations would be proposed with one or the other as a starting 
> point.
>
> As OSPF WG  co-chair and independent of any company affiliation or
> technology preference, I would like to see us move forward with an
> output from all this work.  Publishing the competing drafts as 
> experimental
> and the OSPF Wireless Design Team output as informational would be
> both accrue the benefit of this work and provide a stable base for
> experimentation by the general networking community.
>
> Russ White has asked to present the dual experimental tact at the
> next OSPF WG meeting in San Diego. Other positions are welcome.
>
> Thanks,
> Acee
>
>
> Richard Ogier wrote:
>
>> Acee,
>>
>> After some more thinking, I would like to update my
>> previous thoughts regarding whether we should proceed
>> with multiple experimental drafts.
>>
>> I agree with Tom that we should avoid having multiple
>> experimental drafts if possible.  But if it can't be
>> avoided, then I am confident that the MDR design will
>> prove to be the best standard for OSPF-MANET, and I will
>> work to improve the MDR draft (with the other authors),
>> and to ensure that a good reference implementation is freely
>> and openly available.  I will also work to help people
>> understand and appreciate the MDR approach.
>>
>> That said, I am not sure we should proceed with multiple
>> experimental drafts at this time.
>> Those of us who prefer the MDR approach have good reasons
>> for preferring it, and I think we can come to a decision in
>> the next few months if we discuss this more fully.  In addition,
>> Boeing has written a paper with simulation results and conclusions
>> that support the MDR approach.  I think it is important for Tom
>> to discuss these results and his reasons for preferring the MDR
>> approach, and for the WG to discuss these reasons and other
>> arguments in much greater depth, before a decision is made.
>>
>> If we can't decide on a single approach in the next few months,
>> then I seriously doubt that we will be able to decide after proceeding
>> with two experimental drafts, except to "let the market decide",
>> which to me is not fair and does not result in the best standard.
>> Also, proceeding with multiple experimental drafts will significantly
>> delay the selection of a single proposal (and prolong the agony)
>> during which the people who are working on the "wrong" draft
>> will be wasting valuable time.
>> So it would be better to decide on a single approach first.
>>
>> The issues you listed below are good feedback, and can/will
>> be resolved in the next few months, whether or not we
>> proceed with two experimental drafts.
>> (If the feedback were given a few months ago, the issues would
>> probably have been resolved by now.)
>>
>> In summary, I think it is better to keep the drafts as individual
>> for now.  We just need to try harder, and we can do so
>> without proceeding with multiple experimental drafts.
>>
>> I also address some of the concerns/issues of the MDR approach
>> listed below.
>>
>> Henderson, Thomas R wrote:
>>
>>> Since you are taking a straw poll...
>>>
>>>> -----Original Message-----
>>>> From: Acee Lindem [mailto:[e-mail]] Sent: Monday, October 02, 
>>>> 2006 10:39 AM
>>>> Cc: [e-mail]
>>>> Subject: Re: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, Issue 2
>>>>
>>>>
>>>> Let me summarize where I think we are  - In Dallas I believe we did 
>>>> have
>>>> a "rough" consensus among those actively participated on the OSPF
>>>> wireless design team that the core OSPF MDR algorithm for flooding
>>>> and adjacency reduction should be the approach that we submit to the
>>>> OSPF/MANET WGs for consideration. This didn't include topology 
>>>> reduction
>>>> or some of the other enhancements that are confusing the discussion 
>>>> today.
>>>> We did vastly under estimate the arguments based on factors other than
>>>> those considered by the design team. These arguments came from
>>>> minority members of the design team including some who heretofore 
>>>> hadn't
>>>> participated as well as other interested individuals. These factors 
>>>> include
>>>> computation complexity, deployment momentum, disagreement with the
>>>> problem statement, and possibly even the reluctance or inability
>>>> to understand the MDR draft. Any others?
>>>>
>>
>> The computational complexity of the MDR draft is O(n^2) where n is
>> the number of neighbors.  This is the same as for MPRs and does not
>> increase the computational complexity of OSPF.
>> The main concern is that the BMDR algorithm is not easy to understand,
>> although it is still O(n^2).  It is based on the Suurballe-Tarjan
>> algorithm for computing disjoint paths, so it is based on a well-known
>> algorithm!  But as stated in the draft, a simpler alternative algorithm
>> can be used for selecting BMDRs.  Or, if uniconnected adjacencies are
>> used, one can simply select all non-MDRs to be BMDRs.
>> So, is this a serious drawback of the MDR approach?  I don't think so.
>>
>> Regarding claims that the MDR draft is difficult to understand,
>> I think this is partly because the MDR draft modifies
>> RFC 2328 (and 2740), which itself is fairly complex.
>> For example, one person told me he had trouble reading
>> Section 8.1 (LSA Forwarding Procedure), which modifies Section 13.3
>> of RFC 2328 and thus is written to parallel the steps of Section 13.3,
>> which supports multiple interfaces.  The person said it would be easier
>> to understand if the procedure is first described for a single 
>> interface.
>> I agree, but that is not how Section 13.3 was written.
>> Also, the MDR draft is a complete spec, and therefore is larger
>> than some other drafts that are not as detailed.
>> In general, it is certainly possible to improve the readability
>> of the MDR draft, and we will work on that.
>>
>>>
>>> Disagreement on qualitative design aspects, disagreement on 
>>> requirements
>>> (principally scenarios of interest), reluctance to rely solely on
>>> simulations for quantitative comparison.
>>>
>>
>> Even if there is disagreement on which scenarios are
>> important, I believe that simulations have shown that
>> the MDR approach performs at least as well as the OR
>> approach in almost all scenarios (possibly with some
>> exceptions for which the MDR solution can be improved).
>> (Hopefully, Tom will soon present his results.)
>> In other words, as Tom has said, there is no evidence
>> that we need multiple solutions to support the different
>> scenarios of interest.  The MDR solution performs well in
>> a wide variety of scenarios, and parameters can be selected
>> to emphasize different objectives, such as robustness
>> versus overhead.
>>
>> Richard
>>
>>>
>>>
>>>> The question is where we go now. Independent of draft status, it 
>>>> doesn't
>>>> look like we'll easily reach an agreement.Going forward with 
>>>> multiple drafts
>>>> is one option but everyone should realize that this will also 
>>>> impact future
>>>> optimizations which will undoubtedly be proposed for the 
>>>> contentious OSPF
>>>> MANET interface type.
>>>>
>>>
>>> I think the past week is evidence that we are nowhere near a consensus.
>>> Although several design team members suggested in Dallas to focus on 
>>> the
>>> MDR framework, I haven't seen any evidence that such a group has
>>> expanded beyond more than perhaps one or two people since that time.
>>> Aside from a few new implementations of the proposals (Aniket's MDR
>>> implementation for OPNET and Kenneth Holter's quagga implementation of
>>> ORs), we also haven't really made any technical progress on any points
>>> of disagreement since then, nor even much discussion on how to try to
>>> resolve these differences, and the debate continues to erode (have we
>>> bottomed out yet?).
>>>
>>> Therefore, despite not wanting to arrive at the state where we have
>>> multiple drafts doing very similar things, I don't see how we can
>>> reasonably proceed otherwise at this point.
>>>
>>> I do want to return to the methodology question.  Why do we need a
>>> methodology (maybe not a formal methodology but some understanding of
>>> how to move forward)?  Well, at the very least, I'd like to understand
>>> how we will make future technical progress, or whether it will just be
>>> based largely on the level of vendor support, as Joel suggested.  If
>>> simulation results are going to be deprecated, we should understand 
>>> that
>>> in advance.  On this point, we should be clear that there has long been
>>> a call from the WG to have experimental results and not just simulation
>>> results (I recall Sue Hares voicing this many meetings ago), but no one
>>> has come forward with these to the IETF.  How do we avoid a similar
>>> debate a few years down the road? I feel that it is important to at 
>>> least discuss a way forward to try to
>>> reach one OSPF MANET extension standard because I haven't seen evidence
>>> yet to support the belief that multiple (of these proposals, at least)
>>> are needed. Tom
>>>
>>> _______________________________________________
>>> Ospf-manet mailing list
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/ospf-manet
>>>
>>>
>>
>
>



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