Re: bgp4-17 Section 9

"Tom Petch" <nwnetworks@dial.pipex.com> Fri, 18 January 2002 20:51 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 PAA06116 for <idr-archive@nic.merit.edu>; Fri, 18 Jan 2002 15:51:18 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id EB39B9131E; Fri, 18 Jan 2002 15:50:53 -0500 (EST)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BA9459131F; Fri, 18 Jan 2002 15:50: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 9065B9131E for <idr@trapdoor.merit.edu>; Fri, 18 Jan 2002 15:50:51 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 750555DD91; Fri, 18 Jan 2002 15:50:51 -0500 (EST)
Delivered-To: idr@merit.edu
Received: from snowstorm.mail.pipex.net (snowstorm.mail.pipex.net [158.43.192.97]) by segue.merit.edu (Postfix) with SMTP id B69A85DD90 for <idr@merit.edu>; Fri, 18 Jan 2002 15:50:50 -0500 (EST)
Received: (qmail 1673 invoked from network); 18 Jan 2002 20:50:48 -0000
Received: from userbm54.uk.uudial.com (HELO tom3) (62.188.145.6) by smtp-6.dial.pipex.com with SMTP; 18 Jan 2002 20:50:48 -0000
Message-ID: <00c901c2bf33$2fbdcb40$0301a8c0@tom3>
Reply-To: Tom Petch <nwnetworks@dial.pipex.com>
From: Tom Petch <nwnetworks@dial.pipex.com>
To: Yakov Rekhter <yakov@juniper.net>
Cc: idr@merit.edu
Subject: Re: bgp4-17 Section 9
Date: Sat, 18 Jan 2003 20:42:45 -0000
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
Sender: owner-idr@merit.edu
Precedence: bulk

For ensuring that advertised routes are present in the
Routing Table,
and not just in the Loc-RIB, how about

2. Introduction
..................
   To characterize the set of policy decisions that can be
enforced
   using BGP, one must focus on the rule that a BGP speaker
advertises
   to its peers (other BGP speakers which it communicates
with) in
   neighboring ASs only those routes that it itself uses,
---add--------------
that is, are present in the BGP speaker's Routing Table.
----------------
   This rule
   reflects the "hop-by-hop" routing paradigm generally used
throughout
   the current Internet.
................................

3.2 (no change needed)

9.1.2 (no change needed)

9.1.3 Phase 3: Route Dissemination
......................
   All routes
----change to-------------
that are present in both the Loc-RIB and the Routing Table
-------------------------------
 shall be processed into Adj-RIBs-Out
   according to configured policy.
........................


9.4 (no change needed)

Tom Petch, Network Consultant
nwnetworks@dial.pipex.com

-----Original Message-----
From: Yakov Rekhter <yakov@juniper.net>
To: Tom Petch <nwnetworks@dial.pipex.com>
Cc: idr@merit.edu <idr@merit.edu>
Date: 14 January 2002 20:15
Subject: Re: bgp4-17 Section 9


>>
>> 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?
>>
{paragraph omitted - covered in previous e-mail}
>
>Please propose the specific changes.
>
>Yakov.

{ plus an earlier reply from Alex to me}

> 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.
>