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

[Richard Ogier <[e-mail]>]

Aniket,

I will avoid using the term "natural" in this message. Instead I will
refer to the properties of MDRs that are similar to those of DRs, and
discuss another benefit of this similarity.  (I already mentioned that
this similarity minimizes the number of changes that must be made to OSPF.)
In general, a good extension will minimize the number of new objects
that are introduced.
Thus, it is better to generalize a DR than to introduce a new object
such as an MPR (which as discussed does not generalize a DR since
it is source dependent).  Another advantage, related to item (c) below
from Aniket, is that an OSPF broadcast network can be treated as a
special case of a MANET, since in both cases the DR/MDR and the
set of adjacencies are the same.  This is described in Section 8.1.2
of the MDR draft.  (I believe that the smart peering solution does
not select the same set of adjacencies since it selects adjacencies
in a more random fashion.)

Padma Pillay-Esnault wrote:

> Any extension preserves the capabilities of the underlying base that 
> is being extended or else
> that would be called a new version.


Right. But we are not talking about preserving the capabilities of the
underlying base.  First, we are not just talking about capabilities.
Second, we want to minimize the changes and the addition of new objects,
concepts, techniques, properties, etc.

Richard

P.S.  Someone pointed out that there is no single "natural" way to
extend a protocol.  That is true, and I never said MDRs is the
only natural way to extend an OSPF broadcast network, or to
generalize DRs.  I said "a natural extension", not "the natural
extension".



Aniket Desai wrote:

> 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
>>>>>>>>> [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
>>
>
>
>



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