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

Nischal Sheth <nsheth@juniper.net> Thu, 10 February 2011 23:31 UTC

Return-Path: <nsheth@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 095833A6B04 for <ospf@core3.amsl.com>; Thu, 10 Feb 2011 15:31:05 -0800 (PST)
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 xostnrsLTj3k for <ospf@core3.amsl.com>; Thu, 10 Feb 2011 15:31:04 -0800 (PST)
Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 0FB8A3A6B02 for <ospf@ietf.org>; Thu, 10 Feb 2011 15:31:01 -0800 (PST)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTVR1QFEl0VOEzXhIGbEl3Rh8uuBzX863@postini.com; Thu, 10 Feb 2011 15:31:17 PST
Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 10 Feb 2011 15:28:57 -0800
Received: from [127.0.0.1] (nsheth-xp-lt.jnpr.net [172.17.21.91]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id p1ANTAU15437; Thu, 10 Feb 2011 15:29:10 -0800 (PST) (envelope-from nsheth@juniper.net)
Message-ID: <4D5474C5.1050107@juniper.net>
Date: Thu, 10 Feb 2011 15:29:09 -0800
From: Nischal Sheth <nsheth@juniper.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: "Alvaro Retana (aretana)" <aretana@cisco.com>
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>
In-Reply-To: <1D23749D4168CC4D8B8652397B5F643204176A6C@XMB-RCD-206.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, 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: Thu, 10 Feb 2011 23:31:05 -0000

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