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

Aniket Desai <adesai@opnet.com> Wed, 04 October 2006 00:11 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUuLy-00025S-MX; Tue, 03 Oct 2006 20:11:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUuLw-000217-7c for ospf-manet@ietf.org; Tue, 03 Oct 2006 20:11:13 -0400
Received: from enterprise58.opnet.com ([192.104.65.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUuLv-0001WZ-AM for ospf-manet@ietf.org; Tue, 03 Oct 2006 20:11:12 -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 k9402wwl026832; Tue, 3 Oct 2006 20:02:58 -0400
Message-Id: <6.2.3.4.2.20061003195545.036d0ee0@mailserver.opnet.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Tue, 03 Oct 2006 20:10:45 -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: <4522F64F.6050802@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> <6.2.3.4.2.20061003134740.036ed308@mailserver.opnet.com> <4522E87D.9000404@earthlink.net> <6.2.3.4.2.20061003185449.036a8d18@mailserver.opnet.com> <4522F64F.6050802@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: 4b66a1e94d7d92973ece9e5da449ff80
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

OSPF does not need any work to make it function as is for MANET 
environment...the point to multipoint interface would do fine. Then, 
what is really the qualifying difference between the 2 proposals?

a) OSPF DR exists only for scalability purpose.
b) OSPF MDR achieves scalability using the same functionality as OSPF DR.
c) OSPF DR is a special case of OSPF MDR. (DR = MDR for a single hop MANET).
d) follows a, b and c: Hence OSPF MDR naturally extends OSPF DR.

Sincerely,

Aniket

At 07:46 PM 10/3/2006, Padma Pillay-Esnault wrote:
>Both
>
>Any extension preserves the capabilities of the underlying base that 
>is being extended or else
>that would be called a new version.
>
>I mentionned OSPF documents and I still don't see natural extensions 
>in those documents and proposed to
>keep the custom as in OSPF so far - after all this is a OSPF draft.
>
>I refuse to spend more time over this - if each word change triggers 
>an email thread - we are far from finished.
>Hence this is my last response on this.
>
>Padma
>
>Aniket Desai wrote:
>
>>Hi everyone,
>>
>>I apologize to Dr. Ogier for letting my position down after getting 
>>influenced from replies by the others on the contrary.
>>
>>I should have simply put the search string "ietf natural extension" 
>>in Google, which is what I did. Guess what? A lot of RFCs use this 
>>term (i did a similar search on IEEE with the same result -- it is 
>>an accepted term in scientific and engineering journals). Hence I 
>>do not feel at all that the OSPF-MDR RFC should abandon one of his 
>>strongholds just because a few people cannot agree with this 
>>obvious use of terminology.
>>Sincerely,
>>
>>Aniket
>>
>>At 06:47 PM 10/3/2006, Richard Ogier wrote:
>>
>>>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


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