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

[Josef Buchsteiner]

Wednesday, December 31, 2003, 1:46:35 PM, you wrote:
> 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.

  this  means you prefer non-visibility of true active routes per
  peer ?


  Josef