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

Acee Lindem <acee@cisco.com> Mon, 02 October 2006 20:49 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUUjK-0000nw-GK; Mon, 02 Oct 2006 16:49:38 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUUjJ-0000nr-GX for ospf-manet@ietf.org; Mon, 02 Oct 2006 16:49:37 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUUjI-0006fS-5R for ospf-manet@ietf.org; Mon, 02 Oct 2006 16:49:37 -0400
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 02 Oct 2006 13:49:36 -0700
X-IronPort-AV: i="4.09,245,1157353200"; d="scan'208"; a="44547465:sNHT58352176"
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k92KnZol007954; Mon, 2 Oct 2006 16:49:35 -0400
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k92KnYuc000722; Mon, 2 Oct 2006 16:49:35 -0400 (EDT)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 16:49:33 -0400
Received: from [10.82.224.123] ([10.82.224.123]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 16:49:32 -0400
Message-ID: <45217B5B.5030802@cisco.com>
Date: Mon, 02 Oct 2006 16:49:31 -0400
From: Acee Lindem <acee@cisco.com>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Joe Macker <joseph.macker@nrl.navy.mil>
Subject: Re: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, Issue 2
References: <012601c6e65e$6a820ce0$165cfa84@SEXTANT>
In-Reply-To: <012601c6e65e$6a820ce0$165cfa84@SEXTANT>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 02 Oct 2006 20:49:32.0576 (UTC) FILETIME=[433BFA00:01C6E664]
DKIM-Signature: a=rsa-sha1; q=dns; l=4178; t=1159822175; x=1160686175; c=relaxed/simple; s=rtpdkim2001; 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:Joe=20Macker=20<joseph.macker@nrl.navy.mil>; X=v=3Dcisco.com=3B=20h=3Dd1alR2vT0d1rHILikmkbvIMYDbQ=3D; b=xF3oVej7u0Dif7K25H6Wuwpzxbi9Jso95R3uvmTpGoC/D13V0i5bhG/MtyzCDBa2xbVLBwNc nmo+bqeGdUNQdGyMEWxaSIQMJJ4HfRDaprEDVQj5aP5Rr1ZbkM1MDQ9f;
Authentication-Results: rtp-dkim-2.cisco.com; header.From=acee@cisco.com; dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 34d35111647d654d033d58d318c0d21a
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

Hi Joe, et al,

I guess I still need to try and objectively enumerate the alternatives:

   1. Continue as we are today trying to reach consensus on this list.
   2. Move forward with both implemented drafts as experimental. We need
       to come up with terminolgy to avoid confusion. For example, we 
probably
       need to call one an OSPF MANET Overlapping Relay interface and the
      other as an OSPF MANET Designated Router.
   3. Enlist some outside reviewers to try and get to #1. I say "try" since
       given the august cast we had on the design team, I don't see that 
members
       of another, e.g., the routing directorate, would have more of a 
mandate
       than the design team.
   4. Shelve the problem indefinitely and focus the OSPF/MANET WGs on
       other problems.

Any other alternatives?

For any alternative other than #4, I'd add that we should also publish 
the work
of the design team as an informational draft.

Thanks,
Acee

Joe Macker wrote:
>> -----Original Message-----
>> From: Acee Lindem [mailto:acee@cisco.com] 
>> Sent: Monday, October 02, 2006 1:39 PM
>> 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?
>>     
>
> I think its good to have this historically correct and thanks for writing
> some of the timeline summary. I can't help but remember that overoptimizing
> was a non-goal agreed to by the initial wireless design team members, ADs,
> and chairs.  The reasoning behind this was that we really proposed this
> effort in the hopes of a consensus design within an open protocol framework.
> Early on the adjacency reduction was shown to be a first order design
> effect.  I think this was a big step forward in understanding the design
> space.  My reading was a basic open framework MANET interface+optimized
> flooding+adjacency reduction method could then be agreed upon as a core spec
> and further alternate optimizations could follow
>
> I personally never underestimated the argument potential and this is why I
> believe upfront we agreed to not overoptimize this design effort and to
> scope the early goals of the design team to improve consensus probability. I
> am certainly disappointed with what occurred from the "rough consensus"
> decision point forward.  There will always be multiple valid ways to solve
> particular problems.  So we can continue to do multiple proposals and pay
> the related cost.  The original proposal was not to create another MANET WG
> scenario but to have a consensus framework for OSPF extension improving
> mobile wireless performance.
>
> -Joe
>
>   
>> 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.
>>
>> Thanks,
>> Acee
>>
>> _______________________________________________
>> 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