Re: bgp4-17 Section 9
"Tom Petch" <nwnetworks@dial.pipex.com> Tue, 15 January 2002 18:34 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 NAA03758 for <idr-archive@nic.merit.edu>; Tue, 15 Jan 2002 13:34:26 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 1327491257; Tue, 15 Jan 2002 13:33:41 -0500 (EST)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 83EEF91259; Tue, 15 Jan 2002 13:33:39 -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 27A1E91257 for <idr@trapdoor.merit.edu>; Tue, 15 Jan 2002 13:33:37 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 0A87F5DDB0; Tue, 15 Jan 2002 13:33:37 -0500 (EST)
Delivered-To: idr@merit.edu
Received: from monsoon.mail.pipex.net (monsoon.mail.pipex.net [158.43.128.69]) by segue.merit.edu (Postfix) with SMTP id 490B75DDAC for <idr@merit.edu>; Tue, 15 Jan 2002 13:33:36 -0500 (EST)
Received: (qmail 567 invoked from network); 15 Jan 2002 18:33:30 -0000
Received: from userbf52.uk.uudial.com (HELO tom3) (62.188.142.73) by smtp-1.dial.pipex.com with SMTP; 15 Jan 2002 18:33:30 -0000
Message-ID: <004b01c2bcc4$84018820$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: Wed, 15 Jan 2003 18:28:48 -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
Combining NEXT_HOP resolution into one place (5.1.3) I suggest Revised 9.1.2 para 7 The local speaker MUST determine the immediate next-hop address from the NEXT_HOP attribute of the selected route (see section 5.1.3). If either the immediate next hop or the IGP cost to the NEXT_HOP (where the NEXT_HOP is resolved through an IGP route) changes, Phase 2: Route Selection should be performed again. ---------------------------- Revised 5.1.3 The NEXT_HOP attribute is used by the BGP speaker to determine the actual outbound interface and immediate next-hop address that should be used to forward transit packets to the associated destinations. The immediate next-hop address is determined by performing a recursive route lookup operation for the IP address in the NEXT_HOP attribute using the contents of the Routing Table, -----------revised text follows ------------ selecting one entry if multiple entries of equal cost exist. The Routing Table entry which resolves the NEXT_HOP attribute will always specify the outbound interface. If the entry also specifies the next-hop address, this address should be used as the immediate next-hop address for packet forwarding. If the entry specifies an attached subnet (and does not specify a next-hop address), then the address in the NEXT_HOP attribute should be used as the immediate next-hop address. ------------end of revision---------- I (still) believe 'resolving route' is not at all clear, hence my use of the form 'The Routing Table entry which resolves the NEXT_HOP attribute ...' But I am less hung up on whether we mention entry or use path or drop 'Routing Table'. I take the point about there being a limit as to how much we can say about routing tables; I tend to regard RFC1812 as the sine qua none. 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? >> >> 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. >> >> 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. > >Please propose the specific changes. > >Yakov.
- 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