Subject: Re: [OSPF] OSPF-MDR options

From: Richard Ogier <[email-masked]>
Date: Thu, 06 Dec 2007 12:05:54 -0800

I just realized an error in my last paragraph.  Here is a corrected 
paragraph:

Thus, the only case in which interoperability is an issue is if some 
routers use adjacency reduction while others do not.  This can be 
handled by adding an option bit for adjacency reduction to the Hello 
TLV, and always forming an adjacency with a neighbor that has selected 
LSAFullness = 0.  I recently thought about adding such a bit, but 
decided to wait for comments.  I will plan to add such a bit in the next 
draft update.

With this option bit, interoperability is achieved even if each router 
chooses LSAFullness and AdjConnectivity independently of the other routers.

Richard

Thomas Clausen wrote:

>
> On Dec 6, 2007, at 2:20 AM, Richard Ogier wrote:
>
>> All,
>>
>> I listened to the audio recording of the meeting, and will
>> respond to the comments by the authors of INRIA's proposal for
>> OSPF-MANET (Emmanuel Baccelli and Thomas Clausen).
>>
>
> Y'know, I am not with INRIA, right? :)

I know, but most of the authors are with INRIA.

>
>> Thomas mentioned that with all the options, OSPF-MDR appears
>> to be multiple protocols, rather than a single protocol.
>> The reason that OSPF-MDR is NOT multiple protocols is because
>> it has a single main (default) configuration, and has several
>> options that require very little additional coding (in addition
>> to the default configuration).
>> In contrast, multiple protocols would have a separate chunk of
>> code for each protocol that is not used by the other protocols.
>
>
> I am not sure that I agree that the number of code-lines to change is  
> a good measure as to what is and is not one protocol, so I'll clarify  
> a bit what I meant.
>
> To me, I consider that (i) compatibility of the information conveyed  
> in signaling, and (ii) compatibility of operation are what determines  
> if two "pieces of code" implement the same or different protocols --  
> or maybe rather, that an protocol specification should contain what  
> is necessary for interoperability.
>
> It seems to me that the OSPF-MDR options -- despite perhaps being  
> implementable in a similar number of code-lines -- do not yield  
> interoperability between two different "pieces of code" with each  
> activating different options. Is this not accurate?

I think I understand what you mean now.  I think you are talking about 
the interoperability of two routers using different options.  (My 
previous interpretation addressed which combinations of parameter values 
are allowed for a given router, which I think was also an issue raised 
at the meeting.)

OSPF handles this by rejecting Hello packets received from neighbors 
that have selected options or parameters that do not match that of the 
receiving interface.  For example, the HelloInterval of a received Hello 
must match that of the receiving interface.

Although ideally all routers should select the same values for 
LSAFullness and AdjConnectivity, OSPF-MDR was carefully designed to 
allow different routers to select different values for these 
parameters.  For example, the last paragraph of Section 2.5 states:

   "The above LSA options are interoperable with each other, because they
   all require the router-LSA to include a minimum set of neighbors, and
   because the construction of the router-LSA (described in Section
   9.2.3) ensures that the router-LSAs originated by different routers
   are consistent."

Also, it is allowable for some routers to choose AdjConnectivity = 1 
(uniconnected adjacencies) while others choose AdjConnectivity = 2 
(biconnected adjacencies).  The only constraint is the following, as 
stated in Section 3.2:

     "AdjConnectivity MUST either be zero for all routers or nonzero (1 
or 2) for all routers."

Thus, the only case in which interoperability is an issue is if some 
routers use adjacency reduction while others do not.  This can be 
handled by adding an option bit for adjacency reduction to the Hello 
TLV, and rejecting Hellos when this bit does not match the receiving 
interface.  I recently thought about adding such a bit, but decided to 
wait for comments.  I will plan to add such a bit in the next draft update.

Richard

> Cheers,
> Thomas

_______________________________________________
OSPF mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ospf