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

Richard Ogier <rich.ogier@earthlink.net> Fri, 05 August 2005 01:40 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0rBw-0003UL-Vg; Thu, 04 Aug 2005 21:40:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0rBn-0003Nm-JM for ospf-wireless-design@megatron.ietf.org; Thu, 04 Aug 2005 21:39:59 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22007 for <ospf-wireless-design@ietf.org>; Thu, 4 Aug 2005 21:39:57 -0400 (EDT)
Received: from pop-altamira.atl.sa.earthlink.net ([207.69.195.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0rin-0005cj-In for ospf-wireless-design@ietf.org; Thu, 04 Aug 2005 22:14:05 -0400
Received: from dialup-4.246.30.9.dial1.sanjose1.level3.net ([4.246.30.9] helo=earthlink.net) by pop-altamira.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1E0rBj-0003wz-00; Thu, 04 Aug 2005 21:39:56 -0400
Message-ID: <42F2C360.3020804@earthlink.net>
Date: Thu, 04 Aug 2005 18:39:44 -0700
From: Richard Ogier <rich.ogier@earthlink.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202)
X-Accept-Language: en-us
MIME-Version: 1.0
To: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>
Subject: Re: [Ospf-wireless-design] Design Team slides for IETF 63
References: <77F357662F8BFA4CA7074B0410171B6D512AB4@XCH-NW-5V1.nw.nos.boeing.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Content-Transfer-Encoding: 7bit
Cc: ospf-wireless-design@ietf.org
X-BeenThere: ospf-wireless-design@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: OSPF Wireless Design Team <ospf-wireless-design.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf-wireless-design>, <mailto:ospf-wireless-design-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <https://www1.ietf.org/mailman/private/ospf-wireless-design>
List-Post: <mailto:ospf-wireless-design@lists.ietf.org>
List-Help: <mailto:ospf-wireless-design-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf-wireless-design>, <mailto:ospf-wireless-design-request@lists.ietf.org?subject=subscribe>
Sender: ospf-wireless-design-bounces@lists.ietf.org
Errors-To: ospf-wireless-design-bounces@lists.ietf.org

>
>
>We have to get another approval to release the below to a wider (general
>public) distribution, so please do not redistribute the below outside of
>the design team at this time.  However, it is now posted for the design
>team:
>
>http://hipserver.mct.phantomworks.org/ietf/ospf/
>
>In particular, there is a 100+ page tech report.  I don't expect people
>to wade through the whole thing, but please look at the data in chapter
>4 and summary in chapter 5, if you only read a portion of it.
>

I read Chapters 4 and 5 the technical report, and think the authors
did an excellent job in comparing the different proposals.

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

Here is an example that shows one potential drawback of smart peering.
Consider a network of 100 nodes whose placement is such that the
connectivity graph is a cycle.  Then smart peering may result in the
formation of 99 adjacencies.  (Even though there are 100 edges in
the cycle, only 99 adjacencies are needed to connect all nodes.)
Now suppose that these 100 nodes all travel toward the same
geographical point so that all nodes end up being 1 hop
from each other. With smart peering, no new adjacencies
are formed, so that the adjacency graph still has diameter
99 even though the connectivity graph has diameter 1.
I'm not sure this is really "smart".  With MDRs, one MDR
will be selected, and adjacencies will be formed between
the MDR and all other routers (similar to the DR in an OSPF
broadcast network).

Richard


>
>


_______________________________________________
Ospf-wireless-design mailing list
Ospf-wireless-design@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ospf-wireless-design