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

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 4 Aug 2005 21:10:29 -0700

> -----Original Message-----
> From: Richard Ogier [mailto:[email-masked]] 
> Sent: Thursday, August 04, 2005 6:40 PM
> To: Henderson, Thomas R
> Cc: [email-masked]
> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ospf-wireless-design

---

From: Richard Ogier <[email-masked]>
Date: Fri, 05 Aug 2005 00:18:22 -0700

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

>the DR-other nodes would then tend to form only one adjacency to the
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

---

From: Richard Ogier <[email-masked]>
Date: Fri, 05 Aug 2005 13:46:21 -0700

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

---

From: "Joe Macker" <[email-masked]>
Date: Tue, 9 Aug 2005 13:21:22 -0400

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

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Richard
Ogier
Sent: Friday, August 05, 2005 4:46 PM
To: Henderson, Thomas R
Cc: [email-masked]
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:

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