Re: bgp4-17 Section 9

Alex Zinin <azinin@nexsi.com> Fri, 11 January 2002 17:18 UTC

Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA13451 for <idr-archive@nic.merit.edu>; Fri, 11 Jan 2002 12:18:12 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id CC12691286; Fri, 11 Jan 2002 12:17:52 -0500 (EST)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 95C0A91287; Fri, 11 Jan 2002 12:17:52 -0500 (EST)
Delivered-To: idr@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 91BF991286 for <idr@trapdoor.merit.edu>; Fri, 11 Jan 2002 12:17:51 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 60C755DD8D; Fri, 11 Jan 2002 12:17:51 -0500 (EST)
Delivered-To: idr@merit.edu
Received: from relay1.nexsi.com (relay1.nexsi.com [66.35.205.133]) by segue.merit.edu (Postfix) with ESMTP id 3060D5DD8C for <idr@merit.edu>; Fri, 11 Jan 2002 12:17:51 -0500 (EST)
Received: from mail.nexsi.com (ripper1.nexsi.com [66.35.212.35]) by relay1.nexsi.com (Postfix) with ESMTP id 9DA3A3F65; Fri, 11 Jan 2002 09:20:34 -0800 (PST)
Received: from khonsu.sw.nexsi.com (cscovpn4.nexsi.com [172.16.213.4]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id JAA24827; Fri, 11 Jan 2002 09:21:38 -0800
Date: Fri, 11 Jan 2002 09:16:54 -0800
From: Alex Zinin <azinin@nexsi.com>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <azinin@nexsi.com>
Organization: Nexsi Systems
X-Priority: 3 (Normal)
Message-ID: <172687938513.20020111091654@nexsi.com>
To: Tom Petch <nwnetworks@dial.pipex.com>
Cc: idr@merit.edu
Subject: Re: bgp4-17 Section 9
In-Reply-To: <007d01c2b989$a6a6c2c0$c490bc3e@tom3>
References: <007d01c2b989$a6a6c2c0$c490bc3e@tom3>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-idr@merit.edu
Precedence: bulk

Tom,

> 9.1.2 Route selection now allows for the best route in
> Loc-RIB not to be placed in the Routing table; how does this
> impact on the principle (2 Introduction) that a BGP Speaker
> should only advertise routes it itself uses?  Is it enough
> for the route to be in Loc-RIB and not in the Routing Table?

The principle implies that the route is both in Loc-RIB and
in the routing table, i.e., it needs to be both selected as
the best and used by the router.
However, we can only specify so much about the routing table,
as it is (strictly speaking) outside of the scope of the BGP
protocol and administrator do have the "filter" rope in
their hands. Section 3.2 also talks about this.

> I believe the paragraph on immediate next hop should
> cross-reference the one in 5.1.3; and the latter allows
> route lookup to resolve to a subnet and not an immediate
> next hop address, a possibility 9.1.2 appears not to cater
> for.

Fine with me.

> Perhaps the information on immediate next hop in 5.1.3 and 9
> should be combined in one place; 5.1.3 would be my
> preference.

Fine with me.

> 9.1.2.1 Intermediate network address throws me each time as
> I start thinking of networks; I assume that this is the
> immediate next hop of Rte1; if so, would not that be
> clearer?

The address in Rte1 can be either a direct next-hop or
a third party next-hop (not really a next hop from the RT
perspective). "Intermediate" should account for both cases.

> Resolvability talks of routing table entries for IGP and
> directly connected networks; for consistency with 3.2, I
> would like to see static in there as well.

I actually thought about it when writing this text, but
it fell out of my head. How about this:

   BGP routes do not refer to interfaces, but can be resolved through
   the routes in the Routing Table that can be of both types. IGP routes
   and routes to directly connected networks are expected to specify the
   outbound interface. Static routes can specify the outbound
   interface, or the intermediate address, or both.

> 9.1.2.2e  Again 5.1.3 impacts on this;should this be
> 'immediate next hop' as opposed to 'next hop' (or NEXT_HOP!)
> and what happens with a recursive lookup?  Which of the
> metrics in the various Routing Table entries gets used?
> Perhaps 'The interior cost of a route is the metric in the
> routing table for the immediate next hop (see 5.1.3)'

In fact, "next hop" should read as NEXT_HOP. The metric
is the IGP cost found in the route resolving the NEXT_HOP.

Alex.