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

[Richard Ogier <[e-mail]>]

Acee Lindem wrote:

> Richard,
>
> Richard Ogier wrote:
>
>> Acee,
>>
>> Acee Lindem wrote: 
>
(snip)

>>
>>
>> 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.
>
> But if you don't considered adjacency reduction (which was
> a point of contention on this list), the ORCA proposal could be
> positioned as being quite a bit simpler.


Either the ORCA proposal or the MDR proposal would be
quite a bit simpler if adjacency reduction is not done.
In this case, one need not run any algorithm to select BMDRs,
but could simply let all non-MDR routers act as BMDRs, similar
to non-active ORs.  I plan to allow any non-MDR router to act
as a BMDR (whether or not adjacency reduction is done),
for people who think this is important for robustness.
But those who want to limit the number of BMDRs to achieve scalability
and avoid too many backup floods need not use this option.
(I think Boeing looked into the question of how the large
number of non-active ORs affects performance.)

So, I think the simple version of the MDR proposal (without
adjacency reduction) can be as simple as the simple version of ORCA.
This "simple version" will be an option within the full MDR proposal.
But maybe there are (perhaps nontechnical) reasons to position
the ORCA proposal as a simple solution without adjacency reduction.

I think we should compare both proposals on an equal basis,
without adjacency reduction and with adjacency reduction,
rather than assume that one is better for full-topology adjacencies
and the other is better for reduced adjacencies.

Richard

>
>
> Thanks,
> Acee
>
>
>> 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