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