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. >
- Re: bgp4-17 Section 9 Edward Crabbe
- Re: bgp4-17 Section 9 Alex Zinin
- Re: bgp4-17 Section 9 Jeffrey Haas
- Re: bgp4-17 Section 9 Tom Petch
- Re: bgp4-17 Section 9 Tom Petch
- Re: bgp4-17 Section 9 Yakov Rekhter
- Re: bgp4-17 Section 9 Yakov Rekhter
- Fw: bgp4-17 Section 9 Tom Petch
- Re: bgp4-17 Section 9 Alex Zinin
- bgp4-17 Section 9 Tom Petch