Re: bgp4-17 Section 9

Edward Crabbe <edc@nova.explosive.net> Sat, 19 January 2002 11:01 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 GAA04036 for <idr-archive@nic.merit.edu>; Sat, 19 Jan 2002 06:01:44 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id C53CD91205; Sat, 19 Jan 2002 06:00:47 -0500 (EST)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9352691331; Sat, 19 Jan 2002 06:00:47 -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 6873391205 for <idr@trapdoor.merit.edu>; Sat, 19 Jan 2002 06:00:46 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 4E8C95DDAC; Sat, 19 Jan 2002 06:00:46 -0500 (EST)
Delivered-To: idr@merit.edu
Received: from nova.explosive.net (ns.explosive.net [205.158.174.194]) by segue.merit.edu (Postfix) with ESMTP id 298755DD90 for <idr@merit.edu>; Sat, 19 Jan 2002 06:00:40 -0500 (EST)
Received: from localhost (edc@localhost) by nova.explosive.net (8.9.3/8.9.3) with ESMTP id DAA17254; Sat, 19 Jan 2002 03:04:01 -0800 (PST)
Date: Sat, 19 Jan 2002 03:04:01 -0800
From: Edward Crabbe <edc@nova.explosive.net>
To: Tom Petch <nwnetworks@dial.pipex.com>
Cc: Yakov Rekhter <yakov@juniper.net>, idr@merit.edu
Subject: Re: bgp4-17 Section 9
In-Reply-To: <00c901c2bf33$2fbdcb40$0301a8c0@tom3>
Message-ID: <Pine.GSO.4.21.0201190253520.16718-100000@nova.explosive.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: owner-idr@merit.edu
Precedence: bulk

A few comments here:

-  This has been discussed a few times before on the
list, but never brought to a head.  See the archives:

-  Some prominent bgp implementations would not comply
with the proposed changes (or offer the option of 
non-compliance *shrug*).  

For prevention of loops, it is sufficient that the bgp 
route under consideration have the same nh as the 
exact match route (from protocol with higher relative 
protocol preference) being installed in the routing table.  

Announcement without installation in routing table has
been a neccesary and desired behavior at some large
backbones I have worked at.

On Sat, 18 Jan 2003, Tom Petch wrote:

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