Re: [Ospf-wireless-design] Design team outbrief (draft slides) posted
Richard Ogier <rich.ogier@earthlink.net> Sun, 06 November 2005 20:03 UTC
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYqja-0005mN-Vr; Sun, 06 Nov 2005 15:03:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYqjY-0005mF-Vf for ospf-wireless-design@megatron.ietf.org; Sun, 06 Nov 2005 15:03:21 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17372 for <ospf-wireless-design@ietf.org>; Sun, 6 Nov 2005 15:02:56 -0500 (EST)
Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYqz1-0003LR-QI for ospf-wireless-design@ietf.org; Sun, 06 Nov 2005 15:19:20 -0500
Received: from dialup-4.246.15.15.dial1.sanjose1.level3.net ([4.246.15.15] helo=earthlink.net) by pop-tawny.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1EYqjR-0000lJ-00; Sun, 06 Nov 2005 15:03:13 -0500
Message-ID: <436E6183.4060007@earthlink.net>
Date: Sun, 06 Nov 2005 12:03:15 -0800
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 outbrief (draft slides) posted
References: <77F357662F8BFA4CA7074B0410171B6DC9E615@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: 32b73d73e8047ed17386f9799119ce43
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
Henderson, Thomas R wrote: > > > >>This bullet on page 17 of your slides bothers me: >> >>>Emmanuel Baccelli stated that MPR flooding offers better properties >>>than CDS flooding, with at least as good topology reduction >>>capabilities, and better routing stretch performance >>> >> >>Emmanuel may have "stated" such things, but Phil and I >>clearly pointed out that some of his statements were >>incorrect and based on a lack of understanding of the MDR >>approach. Therefore, one may say that your bullet is the >>truth, but not the whole truth. You could add something like: >>"Phil and Richard pointed out that Emmanuel's statements were >>not justified and Emmanuel did not dispute this." OK, so >>this may be biased in the other direction, but I am making a point. >> > >I am trying to represent the range of opinions expressed without passing >too much judgement on whether claims have been substantiated. > Still, I think it would be misleading not to at least point out the fact that the min-cost LSAs of OSPF-MDR also avoid route stretch, just as MPRs do. This is not passing judgement, but is a simple, clear fact that Phil has expressed, and which Emmanuel was not aware of. Or you can say it is another relevant claim made by Phil and me (without passing judgement). I have some additional comments on Cisco's simulation results, and some comments on consensus (below). In the simulations for Smart Peering, what neighbors were included in the router-LSAs? If only adjacent neighbors were included, then that could explain the lower overhead obtained for Smart Peering, and would also result in highly suboptimal paths (much longer than shortest paths). That is why simulation results are not very meaningful unless other measures such as average path length and delivery ratio are also presented. (The average path length can be obtained from the numbers of UDP packets sent/forwarded/received, but I did not see those numbers.) Also, since Cisco is running SPF twice, once for real adjacencies and once for all acceptable links, I would like to know how a router knows which non-local links are real adjacencies. Does the LSA somehow indicate this? Is a different Link State ID used for real adjacenies versus non-adjacencies? Also, I want to point out that other methods for selecting MDRs are being considered (including MPR pruning as has been discussed) which might result in fewer MDRs and adjacencies, especially in sparse networks. For example, as I suggested to Tom and Phil a few months ago, the idea of Smart Peering can be used to reduce the number of adjacencies in OSPF-MDR. In this modification, another TLV is defined for Hellos which indicates which neighbors are adjacent, to provide 2-hop adjacency information. Adjacencies are still formed only between (Backup) MDRs and their neighbors, but a new adjacency is suppressed if the 2-hop adjacency information indicates that an adjacency path of at most 3 hops exists to the neighbor under consideration. I have not yet incorporated this enhancement, because I was not sure it would be worth the added complexity, and didn't know that Cisco was working on an enhancement to Smart Peering. Note, however, that the enhancement to Smart Peering also adds complexity, since it requires running SPF on two different topology graphs. Regarding consensus, it appears to me that we have a deadlock, since each team has their own solution that they want to win. One way to break the deadlock is to trust the opinion of the person that we chose to lead the team because of his fairness and neutrality. Or we can continue the race for a few more months (perhaps with a deadline) and hope it will become more clear which approach is preferable. Performance is an important criteria, but other qualities are also important, such as minimizing the changes to OSPF and maintaining the same philisophy as OSPF. Richard > > _______________________________________________ Ospf-wireless-design mailing list Ospf-wireless-design@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ospf-wireless-design
- [Ospf-wireless-design] Design team outbrief (draf… Henderson, Thomas R
- Re: [Ospf-wireless-design] Design team outbrief (… Richard Ogier
- RE: [Ospf-wireless-design] Design team outbrief (… Henderson, Thomas R
- Re: [Ospf-wireless-design] Design team outbrief (… Richard Ogier
- Re: [Ospf-wireless-design] Design team outbrief (… Richard Ogier
- Re: [Ospf-wireless-design] Design team outbrief (… Richard Ogier
- Re: [Ospf-wireless-design] Design team outbrief (… Emmanuel Baccelli
- RE: [Ospf-wireless-design] Design team outbrief (… Spagnolo, Phillip A