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