section 9.1.2: NH recursion questions

edc@exodus.net Mon, 21 May 2001 21:27 UTC

Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA00974 for <idr-archive@nic.merit.edu>; Mon, 21 May 2001 17:27:40 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 2F65E5DE83; Mon, 21 May 2001 17:27:10 -0400 (EDT)
Delivered-To: idr-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56) id 1E8165DE7A; Mon, 21 May 2001 17:27:10 -0400 (EDT)
Received: from gevurah.exodus.net (gevurah.exodus.net [216.32.171.180]) by segue.merit.edu (Postfix) with ESMTP id 67AB85DE5E for <idr@merit.edu>; Mon, 21 May 2001 17:27:08 -0400 (EDT)
Received: (from edc@localhost) by gevurah.exodus.net (8.10.2/8.10.2) id f4LJRRw14512 for idr@merit.edu; Mon, 21 May 2001 14:27:27 -0500 (CDT)
Date: Mon, 21 May 2001 14:27:27 -0500
From: edc@exodus.net
To: idr@merit.edu
Subject: section 9.1.2: NH recursion questions
Message-ID: <20010521142726.A14508@exodus.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Mailer: Mutt 1.0.1us
Sender: owner-idr@merit.edu
Precedence: bulk

Hello folks.  I have a few questions on the current bgp draft (and
1771), all having to do with the phase 2 decision process:
  

9.1.2 Phase 2: Route Selection
 ----------
  
    If the NEXT_HOP attribute of a BGP route depicts an address to which
    the local BGP speaker doesn't have a route in its Loc-RIB, the BGP
    route should be excluded from the Phase 2 decision function.
  
 this would seem to imply that if the NH for a given prefix does /not/ 
 exist as a selected (ie: best) _bgp_ route, the prefix shall be excluded from
 the decision process.  Should this not be urib?
   
 ----------
  
    The local speaker SHALL then install that route in the Loc-RIB,
    replacing any route to the same destination that is currently being
    held in the Loc-RIB. The local speaker MUST determine the immediate
    next hop to the address depicted by the NEXT_HOP attribute of the
    selected route by performing a lookup in the IGP and selecting one of
    the possible paths in the IGP.  
  
 IMO the term IGP was misleading here.  The nh may exist
 as static, as direct, in an IGP, or in BGP itself.  as long as the nh is
 present in the unicast rib and the recursive lookup does not loop, the 
 route should be considered feasible?

perhaps:

    The local speaker SHALL then install that route in the Loc-RIB,
    replacing any route to the same destination that is currently being
    held in the Loc-RIB. The local speaker MUST determine the immediate
    next hop to the address depicted by the NEXT_HOP attribute of the
    selected route by performing a lookup in it's routing table and selecting 
    the best path therein. 
  
 ----------
  
    Unfeasible routes shall be removed from the Loc-RIB, and
    corresponding unfeasible routes shall then be removed from the Adj-
    RIBs-In.
  
 (A) vendor may want to keep routes which are considered unfeasible due to   
 lack of valid nh to recurse to around in whatever structure set they are
 using as an adj-rib in equivalent.  This is obviously an implementation 
 detail, but it seems odd to preclude this in the spec?  

Thanks,

	-ed  

-- 
Edward Crabbe
=============
Sr. Network Architect  
Backbone Group
Exodus Communications
-------------
v0x: 408 346 1544