Re: editorial fixes
Susan Hares <skh@nexthop.com> Wed, 16 January 2002 00:21 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 TAA13889 for <idr-archive@nic.merit.edu>; Tue, 15 Jan 2002 19:21:39 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 5302C912A8; Tue, 15 Jan 2002 19:21:08 -0500 (EST)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BBA49912A9; Tue, 15 Jan 2002 19:21:05 -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 8D802912A8 for <idr@trapdoor.merit.edu>; Tue, 15 Jan 2002 19:20:39 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 684885DDCA; Tue, 15 Jan 2002 19:20:39 -0500 (EST)
Delivered-To: idr@merit.edu
Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 1D7175DDAD for <idr@merit.edu>; Tue, 15 Jan 2002 19:20:39 -0500 (EST)
Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0G0KI304212; Tue, 15 Jan 2002 19:20:18 -0500 (EST) (envelope-from skh@nexthop.com)
Message-Id: <5.0.0.25.0.20020115191918.029259a8@mail.nexthop.com>
X-Sender: skh@mail.nexthop.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Tue, 15 Jan 2002 19:20:17 -0500
To: Yakov Rekhter <yakov@juniper.net>
From: Susan Hares <skh@nexthop.com>
Subject: Re: editorial fixes
Cc: idr@merit.edu
In-Reply-To: <200201152311.g0FNBT614783@merlot.juniper.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-NextHop-MailScanner: Found to be clean
Sender: owner-idr@merit.edu
Precedence: bulk
Yakov: The FSM revision I posted as gotten approval from Russ. We are awaiting Alex's review of the text. That should go on your list if Alex approves. Sue At 03:11 PM 1/15/2002 -0800, Yakov Rekhter wrote: >Folks, > >In the absence of any objections I will incorporate the >changes suggested below. > >Yakov. >------- Forwarded Message > >Date: Wed, 15 Jan 2003 18:28:48 +0000 >From: "Tom Petch" <nwnetworks@dial.pipex.com> >To: "Yakov Rekhter" <yakov@juniper.net> >cc: <idr@merit.edu> >Subject: Re: bgp4-17 Section 9 > >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. > > > >------- End of Forwarded Message
- Re: editorial fixes Susan Hares
- Re: editorial fixes Russ White
- Re: editorial fixes Susan Hares
- editorial fixes Yakov Rekhter