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

Acee Lindem <acee@cisco.com> Tue, 10 October 2006 22:04 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXPhx-0002wL-4E; Tue, 10 Oct 2006 18:04:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXPhw-0002wG-LG for ospf-manet@ietf.org; Tue, 10 Oct 2006 18:04:16 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXPhw-0006pQ-3M for ospf-manet@ietf.org; Tue, 10 Oct 2006 18:04:16 -0400
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 10 Oct 2006 15:04:15 -0700
X-IronPort-AV: i="4.09,291,1157353200"; d="scan'208"; a="45570109:sNHT78931110"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9AM4F8o032647; Tue, 10 Oct 2006 18:04:15 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9AM4FYJ029904; Tue, 10 Oct 2006 18:04:15 -0400 (EDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Oct 2006 18:04:15 -0400
Received: from [10.82.224.123] ([10.82.224.123]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Oct 2006 18:04:14 -0400
Message-ID: <452C18DD.2090006@cisco.com>
Date: Tue, 10 Oct 2006 18:04:13 -0400
From: Acee Lindem <acee@cisco.com>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Richard Ogier <rich.ogier@earthlink.net>
Subject: Re: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, Issue 2
References: <77F357662F8BFA4CA7074B0410171B6D01A2F788@XCH-NW-5V1.nw.nos.boeing.com> <4525F7A1.6030900@earthlink.net> <452685E4.6000806@cisco.com> <452811CD.6010403@earthlink.net>
In-Reply-To: <452811CD.6010403@earthlink.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 Oct 2006 22:04:15.0025 (UTC) FILETIME=[06496A10:01C6ECB8]
DKIM-Signature: a=rsa-sha1; q=dns; l=12530; t=1160517855; x=1161381855; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20<acee@cisco.com> |Subject:Re=3A=20[Ospf-manet]=20Re=3A=20Ospf-manet=20Digest, =20Vol=2011, =20Issue= 202 |To:Richard=20Ogier=20<rich.ogier@earthlink.net>; X=v=3Dcisco.com=3B=20h=3Dd1alR2vT0d1rHILikmkbvIMYDbQ=3D; b=C5VsgeLZISwz9FYorUxmvq0RlhIeuEjL2GV3kUsElFyfCDHTlmUHhKQmtyc+4bgzgnzuHdli j7Mgq49lkChMjY/CGEXyFkaLsE+PoNdYKJ8ThfRv14SXWmLriq9kwfU0;
Authentication-Results: rtp-dkim-1.cisco.com; header.From=acee@cisco.com; dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7
Cc: ospf-manet@ietf.org
X-BeenThere: ospf-manet@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions of OSPFv3 extensions supporting MANET <ospf-manet.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf-manet>, <mailto:ospf-manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf-manet>
List-Post: <mailto:ospf-manet@ietf.org>
List-Help: <mailto:ospf-manet-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf-manet>, <mailto:ospf-manet-request@ietf.org?subject=subscribe>
Errors-To: ospf-manet-bounces@ietf.org

Richard,

Richard Ogier wrote:
> 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).
Well the one implementation didn't require this and I think
that if we were to proceed with this draft, this could be
clarified.

> (We can debate this issue in more detail if you think
> it is important to agree on this now.)
I would rather not put the effort into re-issuing this draft
right now just to clarify this point.
>
> 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.
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.

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:acee@cisco.com] Sent: Monday, October 
>>>>> 02, 2006 10:39 AM
>>>>> Cc: ospf-manet@ietf.org
>>>>> 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
>>>> Ospf-manet@ietf.org
>>>> https://www1.ietf.org/mailman/listinfo/ospf-manet
>>>>
>>>>
>>>
>>
>>
>

_______________________________________________
Ospf-manet mailing list
Ospf-manet@ietf.org
https://www1.ietf.org/mailman/listinfo/ospf-manet