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
- [Ospf-manet] Re: Ospf-manet Digest, Vol 11, Issue… Aniket Desai
- Re: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, I… Acee Lindem
- RE: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, I… Stan Ratliff (sratliff)
- Re: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, I… Richard Ogier
- RE: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, I… Joe Macker
- Re: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, I… Joel M. Halpern
- Re: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, I… Acee Lindem
- Re: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, I… Acee Lindem
- Re: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, I… Richard Ogier
- RE: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, I… Stan Ratliff (sratliff)
- Re: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, I… Richard Ogier
- RE: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, I… Stan Ratliff (sratliff)
- Re: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, I… Richard Ogier
- Re: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, I… Joel M. Halpern
- RE: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, I… Henderson, Thomas R
- Re: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, I… Richard Ogier
- RE: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, I… Drake, John E
- Re: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, I… Richard Ogier
- RE: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, I… Drake, John E
- Re: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, I… Richard Ogier
- Re: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, I… Acee Lindem
- Re: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, I… Richard Ogier
- Re: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, I… Acee Lindem
- Re: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, I… Richard Ogier
- RE: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, I… Henderson, Thomas R
- Re: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, I… Philippe Jacquet
- Re: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, I… Richard Ogier