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

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