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

[Aniket Desai <[e-mail]>]

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
>>>>>>[e-mail]
>>>>>>https://www1.ietf.org/mailman/listinfo/ospf-manet
>>
>>
>>_______________________________________________
>>Ospf-manet mailing list
>>[e-mail]
>>https://www1.ietf.org/mailman/listinfo/ospf-manet
>>
>


_______________________________________________
Ospf-manet mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ospf-manet