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

Aniket Desai <adesai@opnet.com> Tue, 03 October 2006 18:01 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUoZw-00031K-R7; Tue, 03 Oct 2006 14:01:16 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUoZv-0002uc-VL for ospf-manet@ietf.org; Tue, 03 Oct 2006 14:01:16 -0400
Received: from enterprise58.opnet.com ([192.104.65.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUoTU-0003Wk-WD for ospf-manet@ietf.org; Tue, 03 Oct 2006 13:54:39 -0400
Received: from wtn12131.opnet.com (wtn12131.opnet.com [172.16.12.131]) by enterprise58.opnet.com (8.13.6/8.12.10) with ESMTP id k93Hk3Av020741; Tue, 3 Oct 2006 13:46:03 -0400
Message-Id: <6.2.3.4.2.20061003134740.036ed308@mailserver.opnet.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Tue, 03 Oct 2006 13:53:50 -0400
To: Padma Pillay-Esnault <ppe@cisco.com>
From: Aniket Desai <adesai@opnet.com>
Subject: Re: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, Issue 7
In-Reply-To: <4522A1A6.1010908@cisco.com>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-OPNET-MailScanner: Found to be clean
X-MailScanner-From: adesai@opnet.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2
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

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".

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