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

Richard Ogier <rich.ogier@earthlink.net> Tue, 03 October 2006 22:47 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUt2x-0004mZ-Md; Tue, 03 Oct 2006 18:47:31 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUt2x-0004mU-6U for ospf-manet@ietf.org; Tue, 03 Oct 2006 18:47:31 -0400
Received: from pop-siberian.atl.sa.earthlink.net ([207.69.195.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUt2w-00022F-Q7 for ospf-manet@ietf.org; Tue, 03 Oct 2006 18:47:31 -0400
Received: from dialup-4.243.128.127.dial1.sanfrancisco1.level3.net ([4.243.128.127] helo=earthlink.net) by pop-siberian.atl.sa.earthlink.net with esmtp (Exim 3.36 #1) id 1GUt2t-0002ZD-00; Tue, 03 Oct 2006 18:47:28 -0400
Message-ID: <4522E87D.9000404@earthlink.net>
Date: Tue, 03 Oct 2006 15:47:25 -0700
From: Richard Ogier <rich.ogier@earthlink.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202)
X-Accept-Language: en-us
MIME-Version: 1.0
To: Aniket Desai <adesai@opnet.com>
Subject: Re: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, Issue 7
References: <E1GUmiF-0007fT-K7@megatron.ietf.org> <6.2.3.4.2.20061003120748.036d1e38@mailserver.opnet.com> <452293EF.8000005@cisco.com> <6.2.3.4.2.20061003125842.036e78c8@mailserver.opnet.com> <4522A1A6.1010908@cisco.com> <6.2.3.4.2.20061003134740.036ed308@mailserver.opnet.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 25eb6223a37c19d53ede858176b14339
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

Aniket Desai wrote:

> I understand that usage of such a term in a draft is not a good idea. 
> But to make the discussions as precise as a draft is very daunting, 
> and we will stall if we did not take liberty of the ongoing context 
> and tried to qualify something as a result. As Dr. Ogier has said, 
> from a functional perspective, there are great similarities between a 
> DR and MDR and hence it follows *naturally*. The term is not without a 
> valid context. That said, I think this is stretching too far and I 
> retract from this discussion. I believe that the following sentence 
> would do: "OSPF MDR extends the functionality and capabilities of the 
> OSPF broadcast interface". 


Lots of people, including mathematicians, use the term "natural extension".
(Just do an internet search.)
Of course, the term should not be used without some justification, but
I think we have provided such justification.  It's OK for people to
disagree with our use of the term, but we have a right to continue
using the term if we believe it represents the truth.
To me, a "natural extension" is an extension that uses techniques
and maintains properties that are similar to those of the thing
being extended.  Sure, an MDR is a generalization
of a DR (whereas an MPR is not as discussed), and that helps.
But to be a "natural extension", we want to maintain techniques
and properties of the thing being extended, i.e., an OSPF broadcast
network.  For example, just as each DR Other forms an adjacency
with each DR and Backup DR in an OSPF broadcast network,
each MDR Other forms an adjacency with each MDR and Backup MDR
in a MANET.   Thus, OSPF-MDR achieves adjacency reduction in a
MANET similar to the way OSPF achieves adjacency reduction in
a broadcast network.  This also has other advantages, such as
helping to minimize the changes to OSPF.

Richard

>
>
> Sincerely,
>
> Aniket
>
> At 01:45 PM 10/3/2006, Padma Pillay-Esnault wrote:
>
>> Aniket
>>
>> Aniket Desai wrote:
>>
>>> Hi Padma,
>>>
>>> I know RFC 2119 very well.
>>>
>>> Let me cut and paste some sentences from RFC 3626 from the OLSR draft:
>>>
>>>    The purpose of dividing the functioning of OLSR into a core
>>>    functionality and a set of auxiliary functions is to provide a 
>>> simple
>>>    and easy-to-comprehend protocol
>>>
>>>    Due to its proactive nature, the OLSR protocol has a natural control
>>>    over the flow of its control traffic
>>>
>>> Now if I were to write an MDR draft and if I constructed a sentence as:
>>>
>>>         The purpose of creating this MDR draft is to extend the 
>>> OSPF's broadcast interface in a natural way. Details follow.
>>>
>>> How is it different from what is there in RFC 3626? As long as we 
>>> understand the context in which we are talking, I think this term 
>>> should be acceptable. You are always free to challenge the context.
>>
>> In OSPF drafts you don't see natural, DC is not a natural extension, 
>> nor is NSSA, nor are other features. They are just extensions.
>>
>>> I understand that the fuss was about the reference that MDRs were a 
>>> natural way to extend OSPF for MANET. I agree that it was an 
>>> aggressive overclaim. I am merely advocating putting it in its 
>>> correct context; that is a *natural extension of broadcast DR 
>>> interface*. I think that there should be a qualifying adjective 
>>> before *extension*, because no one else has shown that there is any 
>>> other way to extend a broadcast interface for MANETs. Hence the 
>>> emphasis on natural. Please suggest if you would like to use another 
>>> adjective instead of *natural*.
>>
>> Why is it so important to put this adjective, would removing it 
>> change the meaning of the functionality ?
>> I don't think so.
>> It's presence kind of open the debate - What is natural and what is 
>> not ?
>>
>> Extensions are just extensions and that should suffice.
>> Let's not add superfluous terms.
>>
>> Padma
>>
>>> Sincerely,
>>>
>>> Aniket
>>>
>>> At 12:46 PM 10/3/2006, Padma Pillay-Esnault wrote:
>>>
>>>> Aniket
>>>>
>>>>
>>>> Aniket Desai wrote:
>>>>
>>>>> At 12:01 PM 10/3/2006, you wrote:
>>>>>
>>>>>> For example, that is why Aniket and I have been
>>>>>> explaining why the MDR approach is a "natural extension".
>>>>>> This is a very important point, since once people understand
>>>>>> *why* we claim it is a "natural extension", they will understand
>>>>>> the MDR approach better.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> That is the point I have also made and I corroborate it. It should 
>>>>> be acceptable to use the phrase that "an MDR is a natural 
>>>>> extension of a broadcast DR". MDRs must be discussed in that 
>>>>> context. Otherwise the whole point is lost in unimportant issues. 
>>>>> As far as I understand, this debate is about scalability versus 
>>>>> robustness, and I don't think anyone can claim that other 
>>>>> solutions can achieve better scalability than MDR. The claim is 
>>>>> only that MDRs lose in robustness what they achieve in scalability 
>>>>> (which has to be seen anyway and can be discounted upfront for the 
>>>>> simple reason that MDRs don't force you to use reduced 
>>>>> adjacencies; MDRs give you the reduced adjacencies as a *gift* - 
>>>>> but that is another discussion). The point is that MDRs do achieve 
>>>>> something, which is scalability BECAUSE it naturally extends the 
>>>>> broadcast DR.
>>>>>
>>>>> Thus if no one has any more objection to the usage of this term, I 
>>>>> think it is perfectly legit for Dr. Ogier and others to continue 
>>>>> using it.
>>>>
>>>>
>>>>
>>>> This is a engineering forum and a scientific one. In IETF, we use 
>>>> precise
>>>> language - RFC 2119 for example. IMHO "Natural extension" does not 
>>>> fit in aforementionned category. This term is too foggy, "natural" 
>>>> has too many complex meaning in layman terms it is best avoided. I 
>>>> don't understand why "natural" has to be here, in most drafts 
>>>> "extension" is just sufficient.
>>>>
>>>>
>>>> Padma
>>>>
>>>>
>>>>> Sincerely,
>>>>>
>>>>> Aniket
>>>>>
>>>>> _______________________________________________
>>>>> 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 mailing list
Ospf-manet@ietf.org
https://www1.ietf.org/mailman/listinfo/ospf-manet