editorial fixes

Yakov Rekhter <yakov@juniper.net> Tue, 15 January 2002 23:11 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 SAA12276 for <idr-archive@nic.merit.edu>; Tue, 15 Jan 2002 18:11:54 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 97F799129B; Tue, 15 Jan 2002 18:11:31 -0500 (EST)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 69A72912A1; Tue, 15 Jan 2002 18:11:31 -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 24D789129B for <idr@trapdoor.merit.edu>; Tue, 15 Jan 2002 18:11:30 -0500 (EST)
Received: by segue.merit.edu (Postfix) id E45375DDAD; Tue, 15 Jan 2002 18:11:29 -0500 (EST)
Delivered-To: idr@merit.edu
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 603095DDA0 for <idr@merit.edu>; Tue, 15 Jan 2002 18:11:29 -0500 (EST)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g0FNBT614783 for <idr@merit.edu>; Tue, 15 Jan 2002 15:11:29 -0800 (PST) (envelope-from yakov@juniper.net)
Message-Id: <200201152311.g0FNBT614783@merlot.juniper.net>
To: idr@merit.edu
Subject: editorial fixes
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <15896.1011136288.1@juniper.net>
Date: Tue, 15 Jan 2002 15:11:29 -0800
From: Yakov Rekhter <yakov@juniper.net>
Sender: owner-idr@merit.edu
Precedence: bulk

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