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

[Richard Ogier <[e-mail]>]

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.
>
Not compared to the current version of MDR, since it already makes adjacency
decisions based only on 2-hop neighbor information.  Also see below.

>
>
>>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?
>
I was actually talking about MDR with uniconnected adjacencies (since
the smart peering method does not provide biconnected adjacencies).
So MDR Other routers would tend to form only one adjacency to the
backbone in this case.  The adjacency information from Hellos
would be used to further reduce the number of adjacencies.
A router would never form an adjacency with a neighbor unless it
would do so in the unmodified protocol with uniconnected adjacencies,
but the modification would cause a router to suppress some adjacencies
that it would otherwise form. Therefore, the modification should not
increase the number of adjacencies (but it might not reduce it much
either). Since MDR Other routers tend to form only one adjacency,
this would mainly affect adjacencies between (Backup) MDRs.
Of course, a router must update its adjacencies whenever the adjacency
information from Hellos changes, but that is true anyway whenever 2-hop
neighbor information changes, so I don't think it adds significantly more
processing or communications overhead.

I agree that it is probably not worth it when applied to MDR with
uniconnected adjacencies.
But I wanted to mention it in case smart peering is considered
independently of MDRs. In this case, I think that including adjacency
information in Hellos is a good approach to avoid the circular
dependency problem.  You also mentioned avoiding this problem by
having LSAs indicate which neighbors are adjacent (which I also
considered a few months ago with regard to routable neighbors),
but I don't see any easy way to include such information in LSAs,
and if one wishes to limit the length of the adjacency path to
3 hops (which I think might help in tems of synchronization), then
Hellos are sufficient to achieve this without driving up the
number of adjacencies.  Anyway, if we agree that this is not
a promising approach, then we probably don't need to discuss
it further.

Richard


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