Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes

"Tom Petch" <nwnetworks@dial.pipex.com> Mon, 01 March 2004 18:16 UTC

Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26298 for <idr-archive@ietf.org>; Mon, 1 Mar 2004 13:16:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxryO-00055G-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 13:17:00 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxrxT-0004xR-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 13:16:03 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axrwb-0004pm-00; Mon, 01 Mar 2004 13:15:09 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxrwV-0006qj-2V; Mon, 01 Mar 2004 13:15:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxrwK-0006qC-GK for idr@optimus.ietf.org; Mon, 01 Mar 2004 13:14:52 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26168 for <idr@ietf.org>; Mon, 1 Mar 2004 13:14:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxrwI-0004ni-00 for idr@ietf.org; Mon, 01 Mar 2004 13:14:50 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxrvJ-0004gq-00 for idr@ietf.org; Mon, 01 Mar 2004 13:13:50 -0500
Received: from colossus.systems.pipex.net ([62.241.160.73]) by ietf-mx with esmtp (Exim 4.12) id 1AxruP-0004V7-00 for idr@ietf.org; Mon, 01 Mar 2004 13:12:53 -0500
Received: from tom3 (1Cust2.tnt15.lnd4.gbr.da.uu.net [62.188.144.2]) by colossus.systems.pipex.net (Postfix) with SMTP id A1FE51C00158; Mon, 1 Mar 2004 18:12:19 +0000 (GMT)
Message-ID: <00b101c3ffb8$89bdf9a0$0301a8c0@tom3>
Reply-To: Tom Petch <nwnetworks@dial.pipex.com>
From: Tom Petch <nwnetworks@dial.pipex.com>
To: Pekka Savola <pekkas@netcore.fi>, idr <idr@ietf.org>
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Content-Transfer-Encoding: 7bit
Sender: idr-admin@ietf.org
Errors-To: idr-admin@ietf.org
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 01 Mar 2004 18:10:44 -0000
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit

It's a fair point but sounds more like
draft-ietf-idr-bgp4-experience-protocol-03.txt
than
draft-ietf-idr-bgp4-23.txt

Tom Petch

-----Original Message-----
From: Pekka Savola <pekkas@netcore.fi>
To: idr@ietf.org <idr@ietf.org>
Date: 29 February 2004 06:24
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0
routes


>After some off-list iteration, a revamped version of the possible text
>could be:
>
>In certain common deployment scenarios, the next-hop addresses are
>supposed to be valid only if resolved via routes of a specific type
>(e.g., IGP, connected or local).  There are likely less specific
>routes from other sources (e.g., static or BGP) which may resolve the
>next-hops as well, but such resolvability typically leads to problems
>when the less specific route actually can't be used to reach the
>next-hop, and the BGP routes are not invalidated even though their
>next-hop is, for all intents and purposes, unroutable.  Therefore, it
>is advisable that the implementations allow the operator to specify
>which routes should yield a positive result if they covered the the
>next-hop.
>
>.. thoughts?  This doesn't have any MAY/SHOULD etc. terminology, at
>least yet -- maybe it should.
>
>--
>Pekka Savola                 "You each name yourselves king, yet the
>Netcore Oy                    kingdom bleeds."
>Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
>
>_______________________________________________
>Idr mailing list
>Idr@ietf.org
>https://www1.ietf.org/mailman/listinfo/idr



_______________________________________________
Idr mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr