FW: OSPF-MDR options

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: ospf <at> ietf.org
Subject: RE: [OSPF] OSPF-MDR options

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:ogier <at> earthlink.net]
Sent: Fri 07/12/2007 18:52
To: Philippe Jacquet
Cc: ospf <at> ietf.org
Subject: Re: [OSPF] OSPF-MDR options

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

_______________________________________________
OSPF mailing list
OSPF <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ospf