[j-nsp] BGP4 MIBv2 question on bgpM2PrefixInPrefixesAccepted (fwd)

[Pekka Savola]

Hi,

(Sorry for delay in responding..)

On Wed, 24 Dec 2003, Josef Buchsteiner wrote:
> Tuesday, December 23, 2003, 1:52:25 PM, you wrote:
> > No response on idr IETF list, so..
> 
> > I think Juniper's implementation/interpretation of accepted/rejected
> > prefixes in the brand new BGP MIB is a bit funky, and loses some
> > important information (this was tested on 6.1R1).
> 
> > Is it just me or should PrefixesAccepted include also those prefixes
> > which passed through the BGP filters, but are currently inactive due
> > to the existence of a route of better preference?
> 
> 
>   I think you need to see this from the RIB table perspective and
>   a  route  in hidden status ( which is vendor specific ) is from
>   the Loc-RIB point of view the same as inactive due to better
>   route preference. So when I look at the definition
> 
>   jnxBgpM2PrefixInPrefixesAccepted
> 
>   The number of prefixes for a peer that are installed
>   in the Adj-Ribs-In and are eligible to become active
>   in the Loc-Rib.
> 
> 
>   then I can only count the active routes. This is how it is done
>   since day one. So the MIB does only present what the CLI has
>   done since the very begin.

No, I completely disagree about "can only count the active routes".  
Look closer to the definitions:

   The number of prefixes for a peer that are installed
   in the Adj-Ribs-In and are ****eligible to become*** active
   in the Loc-Rib.

Note that it does not say active, but "eligible to become active".  
That reads IMHO very clearly that this is supposed to be a superset of 
active routes (e.g., also including those routes which could become 
active due to a route advertisement change).

Note that this definition does not even require that the prefixes to
be counted are in fact in Loc-RIB.  If a route is eligible to become
active in the Loc-Rib, but exists only in an Adj-Rib-In (or something
similar, after applying policies etc.), that should be counted as
well.  This seems to leave a door open to two implementation
techniques: multiple routes can exist in Loc-RIB (ie., anything
passing the first phase of route selection), or only one.

>   jnxBgpM2PrefixInPrefixesRejected
>         The number of prefixes for a peer that are installed
>         in the Adj-Ribs-In and are NOT eligible to become active
>         in the Loc-Rib.
> 
> 
>   So from here the routes which are not active due to attribute
>   tiebreakers or due to policies ( hidden ) or due to unresolved
>   next-hop ( hidden ) needs to be counted here.

I think the Rejected counter should include the routes which are 
hidden due to policies, or hidden due to unresolved next-hop.

(In the terms of draft-ietf-idr-bgp4-23.txt, anything that's rejected 
before Phase 2 of Route selection, section 9.1.2.2.)

>  What   you   are  looking  for  is  a  private  MIB  which  does
>  differentiate   hidden   routes   versus  inactive  routes.  aka
>  jnxBgpM2PrefixInPrefixesHidden  or  hidden  routes  due to local
>  policies.

That would be an acceptable solution to the problem.  As a matter of
fact, I'm going to push something like that to be included in BGP-V2
MIB when the IDR WG at IETF continues working on it.

>       b) Loc-RIB: The Loc-RIB contains the local routing information
>       that the BGP speaker has selected by applying its local policies
>       to the routing information contained in its Adj-RIBs-In. These are
>       the routes that will be used by the local BGP speaker. The next
>       hop for each of these routes MUST be resolvable via the local BGP
>       speaker's Routing Table.

Note that this, again, does not preclude having multiple routes to the 
same destination in Loc-RIB.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings