IETF Logo Mail Archive

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

"Alvaro Retana (aretana)" <aretana@cisco.com> Thu, 06 January 2011 22:28 UTC

Return-Path: <aretana@cisco.com>
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 B29913A6F66 for <ospf@core3.amsl.com>; Thu, 6 Jan 2011 14:28:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 HjNpQGBjTiBr for <ospf@core3.amsl.com>; Thu, 6 Jan 2011 14:28:50 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E5C203A6F5A for <ospf@ietf.org>; Thu, 6 Jan 2011 14:28:49 -0800 (PST)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAK7RJU2tJXHB/2dsb2JhbACkH3OlKJgnhUwEhGeJRQ
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rtp-iport-2.cisco.com with ESMTP; 06 Jan 2011 22:30:56 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p06MUuui008012; Thu, 6 Jan 2011 22:30:56 GMT
Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 Jan 2011 16:30:56 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 06 Jan 2011 16:26:21 -0600
Message-ID: <1D23749D4168CC4D8B8652397B5F643204176A6C@XMB-RCD-206.cisco.com>
In-Reply-To: <13205C286662DE4387D9AF3AC30EF456B03C2377D6@EMBX01-WF.jnpr.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type
Thread-Index: Acutzi8zDH6n3dvMTCyf90oq7HZe+AAE8kPgAAKTIGAAALWwMA==
References: <FC090A1B-0A33-4CC8-B7B8-34076F16EE4D@ericsson.com> <1D23749D4168CC4D8B8652397B5F6432041769BB@XMB-RCD-206.cisco.com> <13205C286662DE4387D9AF3AC30EF456B03C2377D6@EMBX01-WF.jnpr.net>
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, Acee Lindem <acee.lindem@ericsson.com>, ospf@ietf.org
X-OriginalArrivalTime: 06 Jan 2011 22:30:56.0059 (UTC) FILETIME=[627290B0:01CBADF1]
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, 06 Jan 2011 22:28:51 -0000

> From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]
> Sent: Thursday, January 06, 2011 5:06 PM
...
> Indeed we wanted to distinguish from the OSPF MANET interface.
> 
> When the underlying network is clearly not a MANET but a broadcast
one,
> there is no need to implement the complicated procedures specified in
> RFC 5820 - a simple enhancement as specified in this draft will do. It
> simplifies operators' job (monitoring and debugging) as well.

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.

Alvaro.

v2.46.0 | Report a Bug | By Email | System Status