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

["Joe Macker" <[e-mail]>]

I agree with this. I think this is a better engineering approach.

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Richard
Ogier
Sent: Friday, August 05, 2005 4:46 PM
To: Henderson, Thomas R
Cc: [e-mail]
Subject: Re: [Ospf-wireless-design] Design Team slides for IETF 63

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



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