RE: [Ospf-wireless-design] Design team outbrief (draft slides) posted
"Spagnolo, Phillip A" <phillip.a.spagnolo@boeing.com> Mon, 07 November 2005 20:59 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 1EZE4y-0005b7-Dw; Mon, 07 Nov 2005 15:59:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZE4w-0005b0-UM for ospf-wireless-design@megatron.ietf.org; Mon, 07 Nov 2005 15:58:59 -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 PAA07299 for <ospf-wireless-design@ietf.org>; Mon, 7 Nov 2005 15:58:31 -0500 (EST)
Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZEKa-0008Rm-9M for ospf-wireless-design@ietf.org; Mon, 07 Nov 2005 16:15:11 -0500
Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id OAA05362; Mon, 7 Nov 2005 14:58:37 -0600 (CST)
Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id jA7KwaY09121; Mon, 7 Nov 2005 14:58:36 -0600 (CST)
Received: from XCH-NW-5V2.nw.nos.boeing.com ([130.247.55.45]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Nov 2005 12:58:28 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Ospf-wireless-design] Design team outbrief (draft slides) posted
Date: Mon, 07 Nov 2005 12:58:28 -0800
Message-ID: <08590A72DC26A54B85632FF97C2C22DA0D5072@XCH-NW-5V2.nw.nos.boeing.com>
Thread-Topic: [Ospf-wireless-design] Design team outbrief (draft slides) posted
Thread-Index: AcXjyYP4/8nLFQCmRoK5dAo3kbPJOQAE0UlA
From: "Spagnolo, Phillip A" <phillip.a.spagnolo@boeing.com>
To: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>, ospf-wireless-design@ietf.org
X-OriginalArrivalTime: 07 Nov 2005 20:58:28.0796 (UTC) FILETIME=[00F0E7C0:01C5E3DE]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4
Content-Transfer-Encoding: quoted-printable
Cc:
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
Emmanuel, One of the benefits to OSPF-MDR is exactly what you point out. OSPF-MDR is not derived from the point-to-multipoint interface only (which does not route over non-adjacent links), but it is also derived from the broadcast interface (which routes over non-adjacent links). For example, picture a broadcast network with nodes 1 to 5. Node 1 is the DR and node 2 is the BDR. Node 3 wants to send a packet to node 5. Node 3 does not send to node 1 and then to node 5. Node 3 sends directly to node 5. Thus, it is routing over a non-adjacent link because node 3 and 5 are adjacent to the DR. The same is true with OSPF-MDR as long as a node is adjacent to the MDR backbone then it can route to other nodes adjacent to the MDR backbone. I find this as part of the beauty of the design. Sincerely, Phil > -----Original Message----- > From: Emmanuel Baccelli [mailto:Emmanuel.Baccelli@inria.fr] > Sent: Monday, November 07, 2005 9:45 AM > To: ospf-wireless-design@ietf.org > Subject: Re: [Ospf-wireless-design] Design team outbrief > (draft slides) posted > > > I think there is something rather confusing in the latest > discussions: > the use of the term adjacency, especially when compared to its > traditional meaning in OSPF. For example, some simulation > results tend > to show that the MDR approach features a reduced number of > adjacencies > without featuring any route stretching -- if "min-hop" LSAs a used. > However, this supposes that routing is not only done over adjacencies > (indeed, if routing was only done over adjacencies, the MDR approach > leads to more than 50% route stretching in most cases). This is thus > very confusing, since in traditional OSPF routing is supposed > to happen > only over adjacencies. So there is here at least a vocabulary issue, > that needs to be clarified in my opinion. > > Emmanuel > > > Richard Ogier wrote: > > >> 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 > > > > > > After further consideration, I partly agree with the above statement > > depending on how it is interpreted. > > The part about "better route stretch performance" is true if we are > > talking only about *flooding* and not *routing* (since routing can > > occur along non-adjacencies). Min-hop routing can be > achieved either > > with MPRs or with the min-cost LSAs described in the MDR draft. > > > > The part about "good topology reduction capabilities" depends on how > > adjacencies are defined. (By topology reduction I am talking about > > adjacencies, keeping in mind that LSAs can also include non-adjacent > > neighbors.) In our simulations, Phil and I showed that this > > is certainly not true if each node forms an adjacency with each of > > its MPRs and MPR selectors, and Emmanuel has agreed with this: > > > >> On the other hand using > >> MPR/MPRselector adjacencies does yield more adjacencies, > >> but no route stretching whatsoever. > > > > > > > > If adjacencies are defined in another way, then the method needs > > to be specified. One possible way (which I plan to investigate by > > modifying OSPF-MDR) is to select the CDS/MDRs by pruning MPRs > > and then defining adjacencies as in the MDR draft, but Emmanuel > > did not specify such a method. > > > > Richard > > > > > > > > > > _______________________________________________ > > Ospf-wireless-design mailing list > > Ospf-wireless-design@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ospf-wireless-design > > > > > > > _______________________________________________ > Ospf-wireless-design mailing list > Ospf-wireless-design@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ospf-wireless-design > _______________________________________________ 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