Subject: [OSPF] OSPF-MDR options

From: "Spagnolo, Phillip A" <[email-masked]>
Date: Tue, 4 Dec 2007 08:25:31 -0800

All,

I listened to the discussion during the meeting yesterday, and I was
surprised at how Thomas and Emmanuel were trying to cast OSPF-MDR as
having too many options.  I strongly disagree that it has too many
options.

MANETs are not for one size fits all protocols.  The environments in
which they run require flexibility.  The protocol needs to be able to be
configured to match the operational environment.  OSPF-MDR provides
options to configure your MANET for varying environments.  I have found
the options very useful for testing.

---Adjacency graph options---
List goes from most overhead efficient adjacency set to most robust to
link failure
1. AdjConnectivity=1 (maintain a uniconnected MDR backbone)
2. AdjConnectivity=2 (maintain a biconnected MDR backbone)
3. AdjConnectivity=0 (maintain a completely connected MDR backbone) same
as ptmp

---Network graph options---
1. LSAFullness=0 (only advertise adjacencies) "most overhead efficient"
2. LSAFullness=1 (advertise links to have one mincost routing path)
3. LSAFullness=2 (advertise links to have two mincost routing paths)
4. LSAFullness=3 (advertise all routable links on MDRs)
5. LSAFullness=4 (advertise all routable links) "most available routing
paths"

Is this complicated?   I don't think so.  It is flexible for the MANET
environment.

Thomas and Emmanuel, I would agree with your comments that we might need
more explanation on when to configure which options.  That would be no
problem to add before the experimental RFCs are published.  Would you
like to see something like a tutorial?

I say we move forward as planned with three experimental RFCs.

Sincerely,
Phil

Phillip A. Spagnolo
M&CT Network Technology
Boeing Phantom Works
425-373-2810
[email-masked]

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

---

From: "Thomas, Matthew R" <[email-masked]>
Date: Tue, 4 Dec 2007 19:06:18 -0000

not this Thomas (just for clarity)... I Like it
 
Matthew R Thomas

________________________________

From: Spagnolo, Phillip A [mailto:[email-masked]]
Sent: Tue 04/12/2007 16:25
To: [email-masked]
Subject: [OSPF] OSPF-MDR options

All,

---Network graph options---

Sincerely,
Phil

Phillip A. Spagnolo
M&CT Network Technology
Boeing Phantom Works
425-373-2810

---

From: Richard Ogier <[email-masked]>
Date: Wed, 05 Dec 2007 17:20:16 -0800

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).

I will mainly respond to the comments that there may be too
many options, and that it is not clear which options are
preferred and which are compatible with each other.
I may not have fully understood all of the comments/questions,
so feel free to ask questions.
Phil already summarized the main options, so this will
complement his message.

First, I agree that clearer guidance could be provided
for choosing among the different options (although I think
such guidance can be found interspersed throughout the
draft), so we will work on providing this.

As Phil mentioned, these options provide a good deal of
flexibility, and I consider this to be one of the advantages
over INRIA's proposal.  It may very well be that some of these
options will be dropped if OSPF-MDR becomes standards track,
but since the intended status is Experimental, I think it would
be good to experiment with the different options before
eliminating any.

For example, one can use either partial-topology LSAs or
full-topology LSAs, either with or without adjacency reduction.
The only restriction is that LSAFullness = 0 (minimal LSAs)
cannot be used with AdjConnectivity = 0 (no adjacency reduction),
since this would result in empty LSAs, and this is mentioned
in Section 9.2.1.

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.

The main default configuration is AdjConnectivity = 1 and
LSAFullness = 1 (with the other default parameter values).
This is the most scalable configuration that provides
shortest-path routing.  One example of an optional configuration
is to instead use LSAFullness = 4, which simply includes all
routable neighbors in the router-LSA, to provide full-topology LSAs.
Similarly, one can use AdjConnectivity = 0 so that each router
becomes adjacent with each neighbor.

One might argue that the LSAFullness = 0 option (minimal LSAs)
should be omitted, since it does not provide shortest-path
routing.  However, implementing this option requires almost
no additional code once the default configuration is implemented,
i.e., it essentially comes for free.  It's advantage is that
it achieves a significant reduction in overhead and therefore
may allow scalability to larger networks.
Therefore, I think it makes sense to keep this option, at least
for the Experimental draft.

Richard

---

From: Richard Ogier <[email-masked]>
Date: Thu, 06 Dec 2007 11:42:17 -0800

Thomas Clausen wrote:

On Dec 6, 2007, at 2:20 AM, Richard Ogier wrote:

All,

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

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

---

From: Philippe Jacquet <[email-masked]>
Date: Fri, 07 Dec 2007 15:13:07 +0100

All,

I didn't listen to the audio recording of the meeting, therefore I don't 
know how the question of options came out from the discussion. I will 
just only give my general feeling.

I feel there are two kinds of options in network protocol engineering: 
the upward options and the downward options.

The upward options are when they add functions to the protocol that can 
be used by the user. For example the kind of metric used, the 
auto-configuration protocols, etc. The aims of the protocol are changed 
by upward options.

The downward options are when the aims of the protocol are not changed 
but the conditions of use (the lower layers) change. For example if the 
protocol is used on wireless, on electric wires, or on gas.

According to the current discussion it may look that the MDR options 
might be more downward options than upward options. In this case the 
condition of application should be very clearly stated. This is easy if 
it is related to some physical aspect of the router such as to 
distinguish between a wireless interface or a wired interface. But this 
is less easy when the options are related to some scenario situation. An 
open wireless network is subject to scenario changes, therefore the 
options should be changed during operations and this would require:
- an automaton that distinguish when the current scenario conditions change
- a distributed consensus protocol that make the whole network to switch 
consistently from one option to another.

As engineers we all love to have options in order to play indefinitely 
with them, and this may be OK for experimental status. But if we 
consider a non expert user, imagine a soldier on a battlefield, I don't 
know how he will select the best option in the case the radio device 
displays a switch for this.

I hope this helps.

Best regards,
Philippe

Richard Ogier a écrit :
>> or maybe rather, that an protocol specification should contain what  
>> is necessary for interoperability.
>>
> 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.)
> 
> receiving interface.  For example, the HelloInterval of a received Hello 
> must match that of the receiving interface.
> 
> / /  "The above LSA options are interoperable with each other, because they
> wait for comments.  I will plan to add such a bit in the next draft update.
> 
> Richard
> 
> 
>>
>> Cheers,
>>
>> Thomas
>>
> 
> ------------------------------------------------------------------------
>

---

From: Richard Ogier <[email-masked]>
Date: Fri, 07 Dec 2007 10:52:56 -0800

Philippe,

The MDR draft gives some guidance regarding the options, e.g., that 
uniconnected adjacencies and partial-topology LSAs should be used to 
minimize overhead, but I agree that it would be good to include a better 
explanation of parameter choices.

The default configuration is recommended for most scenarios.  The 
optional configurations are included either because some people have 
expressed a preference to use full-topology adjacencies and LSAs (which 
also simplifies the protocol), or to provide greater scalability 
(LSAFullness = 0) or greater robustness (AdjConnectivity = 2).  More 
experimentation is needed to evaluate the benefits of these optional 
configurations.

I expect that the configuration will be selected before deployment 
depending on the scenario, and not changed during operations based on 
automatic scenario recognition.  However, if one chooses to change the 
parameters during operations, a nice property of OSPF-MDR is that each 
router can change its options independently of the other routers (as 
discussed in my previous message).

BTW, I noticed an error in the "corrected" paragraph of my previous 
message: "LSAFullness" should be changed to "AdjConnectivity", as follows:

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 
AdjConnectivity = 0 (no adjacency reduction).  With this option bit, 
interoperability is achieved even if each router chooses LSAFullness and 
AdjConnectivity independently of the other routers.

Richard

Philippe Jacquet wrote:

> All,
>
> I didn't listen to the audio recording of the meeting, therefore I 
> don't know how the question of options came out from the discussion. I 
> will just only give my general feeling.
>
> The upward options are when they add functions to the protocol that 
> can be used by the user. For example the kind of metric used, the 
> auto-configuration protocols, etc. The aims of the protocol are 
> changed by upward options.
>
> but the conditions of use (the lower layers) change. For example if 
> the protocol is used on wireless, on electric wires, or on gas.
>
> condition of application should be very clearly stated. This is easy 
> if it is related to some physical aspect of the router such as to 
> distinguish between a wireless interface or a wired interface. But 
> this is less easy when the options are related to some scenario 
> situation. An open wireless network is subject to scenario changes, 
> therefore the options should be changed during operations and this 
> would require:
> - a distributed consensus protocol that make the whole network to 
> switch consistently from one option to another.
>
> consider a non expert user, imagine a soldier on a battlefield, I 
> don't know how he will select the best option in the case the radio 
> device displays a switch for this.
>
> I hope this helps.
>
> Best regards,
> Philippe
>
>

---

From: "Thomas, Matthew R" <[email-masked]>
Date: Fri, 7 Dec 2007 19:18:35 -0000

Thanks Philippe for that last clarification. It took me back to the drawing board to make sure I understood the Fullness :o) With the type of scarios needing to be covered these features seem to be a minimum required. The fact that the routers can independently change and still work together is very useful.
 
Matthew

From: Richard Ogier [mailto:[email-masked]]
Sent: Fri 07/12/2007 18:52
To: Philippe Jacquet
Cc: [email-masked]
Subject: Re: [OSPF] OSPF-MDR options

Philippe,

Richard

---

From: "Thomas, Matthew R" <[email-masked]>
Date: Fri, 7 Dec 2007 19:23:48 -0000

Sorry I meant "Thanks Richard".. my turn for a typo..

From: Thomas, Matthew R
Sent: Fri 07/12/2007 19:18
To: Richard Ogier; Philippe Jacquet
Cc: [email-masked]
Subject: RE: [OSPF] OSPF-MDR options

Matthew

Philippe,

Richard