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

From: Aniket Desai <[email-masked]>
Date: Mon, 02 Oct 2006 13:08:07 -0400

As I mentioned, a single OSPF extension can be flexible enough
to work in all (or almost all) environments.  If adjacency reduction
is not appropriate for some environments, OSPF-MDR can include the
option of full topology adjacencies, as has been discussed.
This might not be the ideal solution for full topology
adjacencies, but Boeing's simulations show it is as good
as any in terms of performance, and we get the benefit of
a single flexible protocol for a wide range of environments.

- Supporting full topology adjacencies in MDRs is very easy as far as 
I can tell. Parent selection and dependent selection algorithms can 
be modified if a full topology option is specified on a router 
(modification is straightforward: If full topology option is 
specified, form adjacencies with all bidirectional neighbors 
regardless of whether they belong to parent/dependent subset). Sender 
should perhaps put a multicast address in the DR and BDR fields of 
its MDR TLV (?). The receiver will work as usual (i.e. it will honor 
an incoming adjacency only if it is from a child or a dependent 
selector); however an exception will be made for the special 
multicast DR/BDR addresses, and the incoming adjacency will be 
treated as if it came from a child and/or a dependent selector 
(doesn't matter).

I like this scheme, because each router can independently decide 
whether it wants to form full topology adjacencies or optimal 
adjacencies. Also, this does not affect flooding at all, which will 
follow the usual MDR flooding rules. That way, we can get best of 
both the worlds (robustness and efficiency).

Sincerely,

Aniket 

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

---

From: Acee Lindem <[email-masked]>
Date: Mon, 02 Oct 2006 13:39:04 -0400

Let me summarize where I think we are  - In Dallas I believe we did have
a "rough" consensus among those actively participated on the OSPF
wireless design team that the core OSPF MDR algorithm for flooding
and adjacency reduction should be the approach that we submit to the
OSPF/MANET WGs for consideration. This didn't include topology reduction
or some of the other enhancements that are confusing the discussion today.
We did vastly under estimate the arguments based on factors other than
those considered by the design team. These arguments came from
minority members of the design team including some who heretofore hadn't
participated as well as other interested individuals. These factors include
computation complexity, deployment momentum, disagreement with the
problem statement, and possibly even the reluctance or inability
to understand the MDR draft. Any others?

The question is where we go now. Independent of draft status,  it doesn't
look like we'll easily reach an agreement.Going forward with multiple 
drafts
is one option but everyone should realize that this will also impact future
optimizations which will undoubtedly be proposed for the contentious OSPF
MANET interface type.

Thanks,
Acee

---

From: Richard Ogier <[email-masked]>
Date: Mon, 02 Oct 2006 12:50:04 -0700

Acee,

I was hoping it would be possible to decide on a single approach
by having a team of (perhaps 3) unbiased judges look at the
relevant evidence and compare the approaches.
But maybe that is not practical.

I think that if we decide to go forward with multiple experimental
drafts, then we MUST first agree on a methodology for comparing the
proposals, and all participants MUST agree to cooperate with this
methodology.  (E.g., if one team refuses to implement their solution
in GTNetS, then they will be disqualified.)

I agree with the following paragraph of Tom Henderson:

>If the WG decides to adopt multiple experimental drafts, there should be
>some criteria defined for making technical progress in the evaluation,
>so we do not come to the end and have the results and whole methodology
>questioned once again.  I would like the people who have objected to the
>past process to propose some alternatives with technical detail.  I
>strongly believe it should be an agreed goal to avoid multiple draft
>standards on this topic.
>

Richard

---

From: "Joe Macker" <[email-masked]>
Date: Mon, 2 Oct 2006 16:07:41 -0400

>-----Original Message-----
>From: Acee Lindem [mailto:[email-masked]] 
>Sent: Monday, October 02, 2006 1:39 PM
>Cc: [email-masked]
>Subject: Re: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, Issue 2
>
>
>Let me summarize where I think we are  - In Dallas I believe 
>we did have a "rough" consensus among those actively 
>participated on the OSPF wireless design team that the core 
>OSPF MDR algorithm for flooding and adjacency reduction should 
>be the approach that we submit to the OSPF/MANET WGs for 
>consideration. This didn't include topology reduction or some 
>of the other enhancements that are confusing the discussion today.
>We did vastly under estimate the arguments based on factors 
>other than those considered by the design team. These 
>arguments came from minority members of the design team 
>including some who heretofore hadn't participated as well as 
>other interested individuals. These factors include 
>computation complexity, deployment momentum, disagreement with 
>the problem statement, and possibly even the reluctance or 
>inability to understand the MDR draft. Any others?

I think its good to have this historically correct and thanks for writing
some of the timeline summary. I can't help but remember that overoptimizing
was a non-goal agreed to by the initial wireless design team members, ADs,
and chairs.  The reasoning behind this was that we really proposed this
effort in the hopes of a consensus design within an open protocol framework.
Early on the adjacency reduction was shown to be a first order design
effect.  I think this was a big step forward in understanding the design
space.  My reading was a basic open framework MANET interface+optimized
flooding+adjacency reduction method could then be agreed upon as a core spec
and further alternate optimizations could follow

I personally never underestimated the argument potential and this is why I
believe upfront we agreed to not overoptimize this design effort and to
scope the early goals of the design team to improve consensus probability. I
am certainly disappointed with what occurred from the "rough consensus"
decision point forward.  There will always be multiple valid ways to solve
particular problems.  So we can continue to do multiple proposals and pay
the related cost.  The original proposal was not to create another MANET WG
scenario but to have a consensus framework for OSPF extension improving
mobile wireless performance.

-Joe

>
>The question is where we go now. Independent of draft status,  
>it doesn't look like we'll easily reach an agreement.Going 
>forward with multiple drafts is one option but everyone should 
>realize that this will also impact future optimizations which 
>will undoubtedly be proposed for the contentious OSPF MANET 
>interface type.
>
>Thanks,
>Acee
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 02 Oct 2006 16:29:04 -0400

Why must the teams agree on a methodology?
The point of experimental publication is to get the definitions out 
there so that people can implement and use them.
If it does not get used, then there is no need to move anything to 
Proposed Standard.
If one gets used, and the others do not, then that one ends up on the 
standards track.  Probably with improvements from the implementation 
and deployment experience.
If several get implemented and deployed, then we hope to learn things 
from that deployment.  We may discover that factors that never 
occurred to the working group will turn out to be important.  It may 
be that factors the working group thought important turn out to be irrelevant.

The IETF has almost never agreed on criteria for moving from 
experimental to proposed standard, other than "lets see what happens."
And I would be amazed at the IETF giving significant weight to 
simulation experience for that transition.

Yours,
Joel M. Halpern

PS: When this has been done in the past, it has been with the view 
that it was intended to get real world deployment experience.  And 
that such experience was what mattered for any possible eventual move 
from experimental to standards track status.

---

From: Acee Lindem <[email-masked]>
Date: Mon, 02 Oct 2006 16:49:31 -0400

Hi Joe, et al,

I guess I still need to try and objectively enumerate the alternatives:

   1. Continue as we are today trying to reach consensus on this list.
   2. Move forward with both implemented drafts as experimental. We need
       to come up with terminolgy to avoid confusion. For example, we 
probably
       need to call one an OSPF MANET Overlapping Relay interface and the
      other as an OSPF MANET Designated Router.
   3. Enlist some outside reviewers to try and get to #1. I say "try" since
       given the august cast we had on the design team, I don't see that 
members
       of another, e.g., the routing directorate, would have more of a 
mandate
       than the design team.
   4. Shelve the problem indefinitely and focus the OSPF/MANET WGs on
       other problems.

Any other alternatives?

For any alternative other than #4, I'd add that we should also publish 
the work
of the design team as an informational draft.

Thanks,
Acee

---

From: Acee Lindem <[email-masked]>
Date: Mon, 02 Oct 2006 16:58:05 -0400

Richard,

I'd have to agree with Joel. Addiitonally, reaching consensus on the 
criteria
and who has the mandate to make the decision may be as difficult as agreeing
on an approach.  So, we could bring in others, e.g. the routing ADs or 
members of the
routing directorate, but this may not bring us any closer to concensus.

Thanks,
Acee

---

From: Richard Ogier <[email-masked]>
Date: Mon, 02 Oct 2006 15:59:13 -0700

Acee,

In that case, I am strongly opposed to having multiple drafts.
As Joe implied, this would just create another MANET WG scenario
which is what we were trying to avoid. Tom Henderson also said

> I strongly believe it should be an agreed goal to avoid multiple draft
> standards on this topic.

He also said

> questioned once again. 

So, several of us seem to be opposed to going with multiple drafts
(although I will let the others speak for themselves).

I was hoping that the WG would want to standardize the best possible
extension of OSPF.  But from what Joel is saying, Cisco could pay
several people to implement their solution, and it would be adopted
as the standard regardless of how good the solution is?
If this is how things will be decided, then I would not want to
waste my time.  I.e., if we go with multiple drafts and have no
criteria, then I am not sure I would want to participate.

So I guess that leaves alternatives 1, 2, and 4 in your previous email.
I think the best approach is to try to find a team of 3 unbiased
judges, possibly including one or both ADs, and give the teams a few
months to come up with a draft, a position paper, and data to support
their solution (alternative 3).

Richard

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 3 Oct 2006 11:11:34 -0700

Since you are taking a straw poll...  

> Sent: Monday, October 02, 2006 10:39 AM
> Cc: [email-masked]
> we did have

Disagreement on qualitative design aspects, disagreement on requirements
(principally scenarios of interest), reluctance to rely solely on
simulations for quantitative comparison.

>  it doesn't

I think the past week is evidence that we are nowhere near a consensus.
Although several design team members suggested in Dallas to focus on the
MDR framework, I haven't seen any evidence that such a group has
expanded beyond more than perhaps one or two people since that time.
Aside from a few new implementations of the proposals (Aniket's MDR
implementation for OPNET and Kenneth Holter's quagga implementation of
ORs), we also haven't really made any technical progress on any points
of disagreement since then, nor even much discussion on how to try to
resolve these differences, and the debate continues to erode (have we
bottomed out yet?).
 
Therefore, despite not wanting to arrive at the state where we have
multiple drafts doing very similar things, I don't see how we can
reasonably proceed otherwise at this point.

I do want to return to the methodology question.  Why do we need a
methodology (maybe not a formal methodology but some understanding of
how to move forward)?  Well, at the very least, I'd like to understand
how we will make future technical progress, or whether it will just be
based largely on the level of vendor support, as Joel suggested.  If
simulation results are going to be deprecated, we should understand that
in advance.  On this point, we should be clear that there has long been
a call from the WG to have experimental results and not just simulation
results (I recall Sue Hares voicing this many meetings ago), but no one
has come forward with these to the IETF.  How do we avoid a similar
debate a few years down the road?  

I feel that it is important to at least discuss a way forward to try to
reach one OSPF MANET extension standard because I haven't seen evidence
yet to support the belief that multiple (of these proposals, at least)
are needed.  

Tom

---

From: Richard Ogier <[email-masked]>
Date: Tue, 03 Oct 2006 22:23:05 -0700

This is a difficult decision, but I will throw in my two cents,
in the context of Tom's reply.

>>optimizations which will undoubtedly be proposed for the 
Since the above seems important, can you elaborate on this?
E.g., how will future proposed optimizations be impacted?

>reasonably proceed otherwise at this point.

Of course, if we had stuck with our original plan, then it would
have been easy.  I worked hard assuming that we would stick with
our original plan, i.e., I was motivated by the promise that the
solutions would be compared fairly.  So I feel like I wasted a lot
of effort due to false promises.

I am still not sure that we need to go forward with multiple
experimental drafts.  It is true that simulation results are
not sufficient to decide whether a solution will go to standards
track.  But we are only talking about experimental, so if we
stick to our original plan, we should be able to decide at this
point (or soon) which single approach will become an experimental
draft.  You don't need lots of implementations to decide this.
Perhaps all we need is to look at the simulation results we
have (for experimental the decision can be based on
simulation results) and write position drafts (again), and have
better discussions that include more experienced OSPF people.

One recent argument is that we might need two standards, in order
to support all possible scenarios.  That would be a valid reason
to have two experimental drafts.  But, as Tom wrote below,
there is no evidence to support the need for multiple standards.
A single, flexible protocol might be sufficient.
If this is the reason for proceeding with two experimental drafts,
then it is not a valid reason unless we have good evidence that
multiple standards will be needed.

One might argue that proceeding with two experimental drafts will
allow us to compare the implementations (in addition to simulations).
This sounds good, but is it worth the time and effort?
Or can we reasonably predict based on analysis and simulations which
solution is likely to result in a better implementation?
Note, for example, that the coding is the same, since the GTNetS
simulator uses the same Quagga code for simulation and implementation.

In summary, I am saying it might be better to try harder to
reach consensus, before proceeding with two experimental drafts.
(But as mentioned above, this opinion is worth only two cents.)

Richard

---

From: Richard Ogier <[email-masked]>
Date: Thu, 05 Oct 2006 23:28:49 -0700

Acee,

After some more thinking, I would like to update my
previous thoughts regarding whether we should proceed
with multiple experimental drafts.

I agree with Tom that we should avoid having multiple
experimental drafts if possible.  But if it can't be
avoided, then I am confident that the MDR design will
prove to be the best standard for OSPF-MANET, and I will
work to improve the MDR draft (with the other authors),
and to ensure that a good reference implementation is freely
and openly available.  I will also work to help people
understand and appreciate the MDR approach.

That said, I am not sure we should proceed with multiple
experimental drafts at this time.
Those of us who prefer the MDR approach have good reasons
for preferring it, and I think we can come to a decision in
the next few months if we discuss this more fully.  In addition,
Boeing has written a paper with simulation results and conclusions
that support the MDR approach.  I think it is important for Tom
to discuss these results and his reasons for preferring the MDR
approach, and for the WG to discuss these reasons and other
arguments in much greater depth, before a decision is made.

If we can't decide on a single approach in the next few months,
then I seriously doubt that we will be able to decide after proceeding
with two experimental drafts, except to "let the market decide",
which to me is not fair and does not result in the best standard.
Also, proceeding with multiple experimental drafts will significantly
delay the selection of a single proposal (and prolong the agony)
during which the people who are working on the "wrong" draft
will be wasting valuable time.
So it would be better to decide on a single approach first.

The issues you listed below are good feedback, and can/will
be resolved in the next few months, whether or not we
proceed with two experimental drafts.
(If the feedback were given a few months ago, the issues would
probably have been resolved by now.)

In summary, I think it is better to keep the drafts as individual
for now.  We just need to try harder, and we can do so
without proceeding with multiple experimental drafts.

I also address some of the concerns/issues of the MDR approach
listed below.

>>to understand the MDR draft. Any others?

The computational complexity of the MDR draft is O(n^2) where n is
the number of neighbors.  This is the same as for MPRs and does not
increase the computational complexity of OSPF.
The main concern is that the BMDR algorithm is not easy to understand,
although it is still O(n^2).  It is based on the Suurballe-Tarjan
algorithm for computing disjoint paths, so it is based on a well-known
algorithm!  But as stated in the draft, a simpler alternative algorithm
can be used for selecting BMDRs.  Or, if uniconnected adjacencies are
used, one can simply select all non-MDRs to be BMDRs.
So, is this a serious drawback of the MDR approach?  I don't think so.

Regarding claims that the MDR draft is difficult to understand,
I think this is partly because the MDR draft modifies
RFC 2328 (and 2740), which itself is fairly complex.
For example, one person told me he had trouble reading
Section 8.1 (LSA Forwarding Procedure), which modifies Section 13.3
of RFC 2328 and thus is written to parallel the steps of Section 13.3,
which supports multiple interfaces.  The person said it would be easier
to understand if the procedure is first described for a single interface.
I agree, but that is not how Section 13.3 was written.
Also, the MDR draft is a complete spec, and therefore is larger
than some other drafts that are not as detailed.
In general, it is certainly possible to improve the readability
of the MDR draft, and we will work on that.

>simulations for quantitative comparison.

Even if there is disagreement on which scenarios are
important, I believe that simulations have shown that
the MDR approach performs at least as well as the OR
approach in almost all scenarios (possibly with some
exceptions for which the MDR solution can be improved).
(Hopefully, Tom will soon present his results.)
In other words, as Tom has said, there is no evidence
that we need multiple solutions to support the different
scenarios of interest.  The MDR solution performs well in
a wide variety of scenarios, and parameters can be selected
to emphasize different objectives, such as robustness
versus overhead.

Richard

---

From: Acee Lindem <[email-masked]>
Date: Fri, 06 Oct 2006 12:35:48 -0400

All,

I'm not sure extending the discussion longer will yield a consensus.
I don't know what other parties who have not joined the discussion will 
join
or what new information will move the WG toward a single approach. I may
be wrong but I believe all the people who are familiar with two approaches
are subscribed to this list. As I believe it was Joel who stated, there are
many factors involved with what does or doesn't become a standard.

I also think both of these drafts have received sufficient review and
scrutiny of the design team to be experimental OSPF WG drafts. There are
those who may disagree but I could possibly see these being positioned
as a simple approach (MPRs) and dense topology optimal approach (MDRs).
As I previously stated, the main drawback I see is that future OSPF MANET
optimizations would be proposed with one or the other as a starting point.

As OSPF WG  co-chair and independent of any company affiliation or
technology preference, I would like to see us move forward with an
output from all this work.  Publishing the competing drafts as experimental
and the OSPF Wireless Design Team output as informational would be
both accrue the benefit of this work and provide a stable base for
experimentation by the general networking community.

Russ White has asked to present the dual experimental tact at the
next OSPF WG meeting in San Diego. Other positions are welcome.

Thanks,
Acee

Richard Ogier wrote:
>>> From: Acee Lindem [mailto:[email-masked]] Sent: Monday, October 02, 
>>> 2006 10:39 AM
>>> Cc: [email-masked]
>>> look like we'll easily reach an agreement.Going forward with 
>>> multiple drafts

---

From: Richard Ogier <[email-masked]>
Date: Sat, 07 Oct 2006 13:45:01 -0700

Acee,

Acee Lindem wrote:

> I don't know what other parties who have not joined the discussion 
> will join

I really don't believe the MPR approach is simpler than the MDR
approach, assuming that smart peering is used for adjacency
reduction to achieve scalability.  I provided some evidence
in my last post to support this belief (e.g., smart peering
would also have to compute disjoint paths to all neighbors
if biconnected adjacencies are desired).
(We can debate this issue in more detail if you think
it is important to agree on this now.)

Therefore, I don't think it is appropriate to position
the MPR approach as the simple approach.

I think the main difference between the two approaches
is as follows:

- The MDR approach uses a source-independent CDS which
  generalizes the DR.  (For scalability, adjacencies are reduced
  based on the MDRs/BMDRs, similar to the way adjacencies are
  reduced based on the DR/BDR in an OSPF broadcast network.
  However, adjacency reduction is optional.)

- The MPR approach uses source-dependent MPRs.
  (For scalability, adjacencies can be reduced using smart
  peering, which is based on connectivity via synchronized
  adjacencies and is not based on MPRs.)

I think the two approaches have about the same complexity.
Also, I think Boeing's simulation results show that MDRs
perform as well as MPRs even in sparse topologies, so
it would not be appropriate to position MPRs for sparse
and MDRs for dense topologies.

Richard

>>> debate a few years down the road? I feel that it is important to at 
>>> least discuss a way forward to try to
>>> are needed. Tom

---

From: Acee Lindem <[email-masked]>
Date: Tue, 10 Oct 2006 18:04:13 -0400

Richard,

> if biconnected adjacencies are desired).
Well the one implementation didn't require this and I think
that if we were to proceed with this draft, this could be
clarified.

> it is important to agree on this now.)
I would rather not put the effort into re-issuing this draft
right now just to clarify this point.
> I think the two approaches have about the same complexity.
But if you don't considered adjacency reduction (which was
a point of contention on this list), the ORCA proposal could be
positioned as being quite a bit simpler.

Thanks,
Acee

>>>>> From: Acee Lindem [mailto:[email-masked]] Sent: Monday, October 
>>>>> 02, 2006 10:39 AM
>>>>> Cc: [email-masked]

---

From: Richard Ogier <[email-masked]>
Date: Tue, 10 Oct 2006 17:54:00 -0700

>> Acee Lindem wrote: 
(snip)

> positioned as being quite a bit simpler.

Either the ORCA proposal or the MDR proposal would be
quite a bit simpler if adjacency reduction is not done.
In this case, one need not run any algorithm to select BMDRs,
but could simply let all non-MDR routers act as BMDRs, similar
to non-active ORs.  I plan to allow any non-MDR router to act
as a BMDR (whether or not adjacency reduction is done),
for people who think this is important for robustness.
But those who want to limit the number of BMDRs to achieve scalability
and avoid too many backup floods need not use this option.
(I think Boeing looked into the question of how the large
number of non-active ORs affects performance.)

So, I think the simple version of the MDR proposal (without
adjacency reduction) can be as simple as the simple version of ORCA.
This "simple version" will be an option within the full MDR proposal.
But maybe there are (perhaps nontechnical) reasons to position
the ORCA proposal as a simple solution without adjacency reduction.

I think we should compare both proposals on an equal basis,
without adjacency reduction and with adjacency reduction,
rather than assume that one is better for full-topology adjacencies
and the other is better for reduced adjacencies.

Richard

>>>>> debate a few years down the road? I feel that it is important to 
>>>>> at least discuss a way forward to try to

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 10 Oct 2006 18:36:45 -0700

> number of non-active ORs affects performance.)

To respond to this point, we did do some limited sensitivity analysis of
the PushBackInterval that governs the aggressiveness of the non-active
relays, and found that overhead performance was sensitive to this
parameter while the user data delivery ratio tended to be insensitive;
that is, we saw no significant penalty of making PushBackInterval on the
larger side of the interval recommended in the OR draft.  This data and
discussion is in Appendix E of:
http://hipserver.mct.phantomworks.org/ietf/ospf/reports/Boeing-D950-1089
7-1.pdf

As we reported in our other report last March, the Cisco results
presented at IETF-64 had the PushBackInterval at a large fraction of the
RxmtInterval, larger than what was recommended in the draft, thereby
significantly deemphasizing the firing of non-active relays:
http://hipserver.mct.phantomworks.org/ietf/ospf/reports/Boeing-IETF64-An
alysis.pdf
This configuration was reported to give better results.

So I don't think it has ever been established that non-active ORs
significantly improve robustness, or that the overhead associated with
them is best spent there and not doing something else such as reducing
the Hello interval.

Tom

p.s. time for a new subject line on this thread

---

From: Philippe Jacquet <[email-masked]>
Date: Wed, 11 Oct 2006 11:19:32 +0200

Richard,

<>Sorry, I was in Japan for OLSR Interop and I could not participate to 
the late part of the discussion. <>

You cannot say that the MDRs are source-independent (you mean last-hop 
independent?) since you have introduced a very complex last hop 
dependent procedure in your draft (step 2b). I understand that in some 
specific scenario it would help the performance but in a very expensive 
way. MPRs don’t need to be tuned with complex options in order to 
perform as well in sparse and dense networks. <>

Furthermore, Overlapping Relays can also benefit from the MPR topology 
and adjacency reduction that we discussed on the mailing list and which 
is explained in our draft.

Philippe

---

From: Richard Ogier <[email-masked]>
Date: Wed, 11 Oct 2006 08:12:42 -0700

Philippe Jacquet wrote:

> Richard,
>
> <>Sorry, I was in Japan for OLSR Interop and I could not participate 
> to the late part of the discussion. <>
>
> dependent procedure in your draft (step 2b).

As we discussed, this "very complex" procedure (in which the router
must determine whether all neighbors are covered by the received LSA)
is no more complex than what OSPF already does when forwarding LSAs.
In RFC 2328, Section 13.3, when a new LSA is received, for each eligible
interface, "Each of the neighbors attached to this interface are examined,
to determine whether they must receive the new LSA."
I know you would prefer to avoid examining all neighbors
when forwarding an LSA, which would require retransmitted LSAs to be
multicast, but none of the implemented proposals (MDRs and ORs) do this.
Note also that in the OR proposal, a non-active OR must also determine
which neighbors are covered by a received LSA.

Also, MDRs themselves are indeed source-independent, i.e., all routers
agree who the MDRs are (even though the flooding procedure may have
a source-dependent rule for avoiding some unnecessary floods).
With MPRs, each node selects its own MPRs, so there is no such
agreement.

The last point I would like to make is that it is possible to allow
retransmitted LSAs to be multicast as an *option* in any of the
implemented proposals.  Also, as discussed repeatedly,
it is possible to determine in advance (whenever the 2-hop neighbor
info changes) whether each neighbor covers all other neighbors.

Richard

> I understand that in some specific scenario it would help the 
> performance but in a very expensive way. MPRs don’t need to be tuned 
> with complex options in order to perform as well in sparse and dense 
> networks. <>
>
> and adjacency reduction that we discussed on the mailing list and 
> which is explained in our draft.
>
> Philippe
>
> Richard Ogier wrote:
>
>> Acee,
>>
>> Acee Lindem wrote:
>>
>>> All,
>>>