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

"Henderson, Thomas R" <thomas.r.henderson@boeing.com> Mon, 28 March 2011 18:39 UTC

Return-Path: <thomas.r.henderson@boeing.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 4540B3A6825 for <ospf@core3.amsl.com>; Mon, 28 Mar 2011 11:39:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.455
X-Spam-Level:
X-Spam-Status: No, score=-106.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 7tBLg-9D9jEh for <ospf@core3.amsl.com>; Mon, 28 Mar 2011 11:39:18 -0700 (PDT)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 84A363A67D6 for <ospf@ietf.org>; Mon, 28 Mar 2011 11:39:18 -0700 (PDT)
Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p2SIemV5021065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 28 Mar 2011 11:40:48 -0700 (PDT)
Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p2SIem3c010868; Mon, 28 Mar 2011 11:40:48 -0700 (PDT)
Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p2SIeml2010854 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 28 Mar 2011 11:40:48 -0700 (PDT)
Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.85]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Mon, 28 Mar 2011 11:40:48 -0700
From: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>
To: 'Acee Lindem' <acee.lindem@ericsson.com>, Nischal Sheth <nsheth@juniper.net>, "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
Date: Mon, 28 Mar 2011 11:40:47 -0700
Thread-Topic: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type
Thread-Index: AcvSu75+VNuBUribS4ij2HE3LTP6sQasXWow
Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CED25B07D@XCH-NW-10V.nw.nos.boeing.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> <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 18:39:19 -0000

I don't have a problem with the proposal to specify a simpler interface type for the use cases described.  It seems preferable for a vendor to be able to say that it fully implements a particular interface type rather than having to say that it implements an interface type but lacking features a,b,c etc.

There are many radio systems that perform routing below IP and provide a full broadcast-based abstraction, but for which the neighbor costs are unequal and it would be nice to be able to represent them that way in OSPF.  Moreover, people are now designing radio to router protocols to allow these unequal costs to be dynamic and automatically computed. 

It might be nice to define broadcast-oriented interface types progressively as follows:

1) existing broadcast interface for equal-cost neighbors
2) the proposed hybrid interface for full mesh broadcast links with unequal neighbor costs
3) correct the DR election and flooding behavior for links that may be partial mesh

The above could all be separate interface types, and 2) and 3) could each be supplemented by additional capabilities:
- optional radio-to-router control protocol to determine the unequal neighbor costs or router priorities automatically
- overhead reduction techniques such as differential hellos or partial topology reporting

Tom