Re: [Ospf-wireless-design] Design Team slides for IETF 63

[Richard Ogier <[e-mail]>]

Since the recent discussion might have been a little confusing
(or unclear), I would like to summarize some of my points and
design principles.  First of all, the MDR solution uses 2-hop
neighbor information (actually information regarding interconnectivity
between 1-hop neighbors) from Hellos to select MDRs and decide which
neighbors should be adjacent. I think the use of such 2-hop neighbor
information from Hellos is desirable for a number of reasons.
First, when 2-hop neighbor information changes, it is learned
very quickly via differential Hellos (typically within 2 seconds).
The use of router-LSAs to convey 2-hop neighbor information
(or even non-local adjacency information) can result in
slower convergence and more overhead following a link failure.
For example, there can be delay of MinLSInterval before the
change is advertised in a new LSA.  Recall that we cannot
simply make MinLSInterval smaller in a dense, highly mobile
network, because this will greatly increase overhead!
Also, since Hellos can be differential, this allows
the Hello interval to be smaller, thus allowing a change
to be reported sooner (e.g., within 1 second).
That is why I like the design principal of advertising 2-hop
neighbor information in Hellos, and of using only this
information from Hellos in deciding which neighbors should be
adjacent.  (For example, I would prefer not to use LSAs to
indicate which neighbors are adjacent, if a variation of
smart peering is used.)

One might argue that using only 2-hop neighbor information from
Hellos can increase the number of MDRs and the number of
adjacencies. It may indeed result in a few more adjacencies
and MDRs, but it will also improve robustness and convergence
following topology changes.

Richard





Henderson, Thomas R wrote:

> 
>
>>-----Original Message-----
>>From: Richard Ogier [mailto:[e-mail]] 
>>Sent: Thursday, August 04, 2005 6:40 PM
>>To: Henderson, Thomas R
>>Cc: [e-mail]
>>Subject: Re: [Ospf-wireless-design] Design Team slides for IETF 63
>>
>>
>>I would like to comment on the smart peering approach, 
>>studied in Section 4.5 of the report.
>>I agree that "smart peering" has a circular dependency 
>>problem if non-adjacent neighbors are included in LSAs.
>>(A simple 4-node example can be constructed to show this.)
>>
>>To avoid this problem, I considered a variation in which each 
>>router lists its adjacent neighbors in a new Hello TLV.
>>Then the router can avoid forming an adjacency with a 
>>neighbor if there already exists a path of adjacencies from 
>>the router to that neighbor based on the adjacency 
>>information obtained from Hellos.  
>>
>
>I think that this may improve the performance, but one challenge that
>remains is that it is not clear whether the loss of an adjacency
>somewhere causes nodes to have to reconsider their previous decisions to
>defer forming adjacencies with their neighbors.  If the degree of the
>node is not high, however, it probably will not be burdensome to revisit
>these decisions when this Hello TLV changes.  But since the adjacency
>decisions are just being made on this localized information, it will
>probably drive up the number of adjacencies.
>
>>This can be used in 
>>conjunction with the MDR extension, so that a router selects 
>>adjacent neighbors as before except that it avoids forming an 
>>adjacency with a neighbor if there already exists a path of 
>>adjacencies to that neighbor.
>>An adjacent neighbor still remains adjacent only as long as 
>>either the router or the neighbor is a (Backup) MDR, so that 
>>adjacencies are still aligned with (Backup) MDRs.
>>This will reduce the number of adjacencies (at least a 
>>little), but I have not run simulations to determine how this 
>>affects performance.
>>
>
>This explanation wasn't completely clear to me.  Are you suggesting that
>the DR-other nodes would then tend to form only one adjacency to the
>backbone in this case?
>
>If one suppresses adjacencies between DR-other neighbors, then one might
>expect that these synchronized DR-other neighbors are often two hops
>away from one another (adjacent to the same (Backup) MDR).  But it is
>not guaranteed; in a dense network, they may have become adjacent to
>(Backup) MDRs that are not topologically close.  In this case, your
>suggestion to include adjacency info in the Hellos might help avoid
>"synchronized" neighbors with long adjacency paths between them, but I
>am not sure that it is going to be worth it-- I am not sure that such
>scenarios are common (plus, again, it might cause more adjacencies). 
>
>Tom
>



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