Proxy: comments on section 9.1.3

Alex Zinin <zinin@psg.com> Fri, 06 September 2002 13:07 UTC

Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02269 for <idr-archive@ietf.org>; Fri, 6 Sep 2002 09:07:57 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 32880912CE; Fri, 6 Sep 2002 09:09:19 -0400 (EDT)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id F1FFA912CF; Fri, 6 Sep 2002 09:09:18 -0400 (EDT)
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 B383B912CE for <idr@trapdoor.merit.edu>; Fri, 6 Sep 2002 09:09:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 92C0D5DE4D; Fri, 6 Sep 2002 09:09:17 -0400 (EDT)
Delivered-To: idr@merit.edu
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 674AC5DE4A for <idr@merit.edu>; Fri, 6 Sep 2002 09:09:17 -0400 (EDT)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17nIrM-000DTl-00 for idr@merit.edu; Fri, 06 Sep 2002 06:09:17 -0700
Date: Fri, 06 Sep 2002 15:07:40 +0200
From: Alex Zinin <zinin@psg.com>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <zinin@psg.com>
X-Priority: 3 (Normal)
Message-ID: <14776995313.20020906150740@psg.com>
To: idr@merit.edu
Subject: Proxy: comments on section 9.1.3
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-idr@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Proxy-fwd below.

--
Alex

I'm looking for clarification to wording in section 9.1.3 Phase 3: Route
Dessemination of draft-ietf-idr-bgp4-17.txt.

My understanding is that a BGP route should not be advertised to a peer if
that route is not also in the Routing Table (e.g. FIB).  I was looking for
wording to support this, but am now starting to second guess myself.

"All routes in the Loc-RIB shall be processed into Adj-RIBs-Out according to
configured policy. This policy may exclude a route in the Loc-RIB from being
installed in a particular Adj-RIB-Out."

This seems clear.  I'm interpreting "configured policy" as routes can be
filtered prior to being sent (and thus not sent) to a peer.

"A route shall not be installed in the Adj-Rib-Out unless the destination
and NEXT_HOP described by this route may be forwarded appropriately by the
Routing Table."

This covers the case when local policy keeps a route in Loc-RIB from being
placed into the Routing Table and there is no other way for the route to get
in the Routing Table.  Even though the route is in Loc-RIB, it will not be
sent to the peer.

What if the route in Loc-RIB would have been placed in the Routing Table,
except local policy (e.g. lower Administrative Distance) placed an IGP route
there instead?   Durring Phase 3, both the destination and NEXT_HOP
described by the route in Loc-RIB could be "forwarded appropriately" (but
perhaps to the wrong place.)   In this case, should the Loc-RIB be placed in
Adj-RIB-Out?

The text doesn't say that both Loc-RIB and the Routing Table (the route the
local speaker itself uses) must have the same route.  It reads as if only
route in Loc-RIB need be considered.  In the description of earlier phases,
"local policy" is mentioned in the text describing what to do.  In this
phase, the impact of any "local policy" should be called out.