Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Mon, 28 March 2011 14:48 UTC

Return-Path: <zzhang@juniper.net>
X-Original-To: ospf@core3.amsl.com
Delivered-To: ospf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6761D3A68F3 for <ospf@core3.amsl.com>; Mon, 28 Mar 2011 07:48:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id md0fhh8n2JRt for <ospf@core3.amsl.com>; Mon, 28 Mar 2011 07:48:11 -0700 (PDT)
Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id 3A5E83A6863 for <ospf@ietf.org>; Mon, 28 Mar 2011 07:48:08 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTZCgCapgYLNQPWfuNm7/dEalpqBVyJIB@postini.com; Mon, 28 Mar 2011 07:49:49 PDT
Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 28 Mar 2011 07:47:02 -0700
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 28 Mar 2011 10:48:29 -0400
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: Acee Lindem <acee.lindem@ericsson.com>, "Abhay Roy (akr)" <akr@cisco.com>
Date: Mon, 28 Mar 2011 10:48:24 -0400
Thread-Topic: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type
Thread-Index: AcvSu75+VNuBUribS4ij2HE3LTP6sQamjntw
Message-ID: <13205C286662DE4387D9AF3AC30EF456D340239330@EMBX01-WF.jnpr.net>
References: <FC090A1B-0A33-4CC8-B7B8-34076F16EE4D@ericsson.com> <1D23749D4168CC4D8B8652397B5F6432041769BB@XMB-RCD-206.cisco.com> <13205C286662DE4387D9AF3AC30EF456B03C2377D6@EMBX01-WF.jnpr.net> <1D23749D4168CC4D8B8652397B5F643204176A6C@XMB-RCD-206.cisco.com> <4D5474C5.1050107@juniper.net> <C687946D-2D50-4DEE-B276-9826E6B98943@ericsson.com>
In-Reply-To: <C687946D-2D50-4DEE-B276-9826E6B98943@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ospf@ietf.org" <ospf@ietf.org>
Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Mar 2011 14:48:12 -0000

WG chairs and members,

As Acee mentioned below, this optimization is a reasonable, simple and general solution for a valid probem, and is really not conflicting with MANET.

As a result, we would like to request again for WG's acceptance of this work.

Thanks.
Jeffrey, Nischal, Lili. 

> -----Original Message-----
> From: Acee Lindem [mailto:acee.lindem@ericsson.com] 
> Sent: Tuesday, February 22, 2011 7:10 PM
> To: Nischal Sheth
> Cc: Alvaro Retana (aretana); Jeffrey (Zhaohui) Zhang; ospf@ietf.org
> Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type
> 
> Speaking as a WG member, I really don't see this hybrid 
> interface optimization as conflicting with the problem space 
> covered by the MANET draft. 
> Thanks,
> Acee 
> On Feb 10, 2011, at 6:29 PM, Nischal Sheth wrote:
> 
> > On 1/6/2011 2:26 PM, Alvaro Retana (aretana) wrote:
> > 
> >> You don't need to implement everything in the rfc to support the
> >> interface functionality.  Most of the work in the rfc is 
> oriented at
> >> reducing the overhead on the wire (Incremental Hellos, 
> Smart Peering) or
> >> at addressing the cases where not all the nodes are 
> visible (Overlapping
> >> Relays).
> >> 
> >> If you don't care about reducing the overhead and can 
> guarantee that all
> >> the nodes are visible, then the interface definition is enough. ;-)
> >> That reduces to taking advantage of the broadcast 
> characteristics for
> >> flooding, but using p2p adjacencies -- which would be a 
> lot easier to
> >> operate because it is clearer what the relationship 
> between the peers
> >> w/the different metrics is.
> >> 
> >> In my mind the problem in your document is already solved.
> >> 
> > 
> > Hi Alvaro,
> > 
> > If one were to use just the interface definition, we would 
> end up with a 
> > full mesh of adjacencies between all routers on the 
> broadcast network.
> > This is less desirable compared to the hybrid interface 
> which requires 
> > adjacencies only to the DR/BDR.
> > 
> > One would need to implement Smart Peering in order to 
> reduce the number 
> > of adjacencies on the MANET interface.  However, doing so 
> would result 
> > in suboptimal routing unless you implement Unsynchronized 
> Adjacencies.
> > Finally, Unsynchronized Adjacencies requires a protocol 
> extension which 
> > is defined only for OSPFv3.
> > 
> > Based on the points above, I don't consider the MANET 
> Interface to be a 
> > true superset of the hybrid interface to solve the problem at hand.
> > 
> > -Nischal
> > 
> 
>