[j-nsp] Juniper route age reset behavior

[Magnus Bergroth]

Hi Jeff

For me "show route" is all about troubleshooting and age is a big part
of that.

My believe of the juniper age for a bgp prefix has always been that it
reflects the time it has been valid. Even though it's not completely
true as hidden routes retains it's age when the route becomes valid. But
it's still been very helpful in verifying if a BGP route has been stable.

To get the bigger picture you also need to check the age of the prefix
that the protocol next-hops points to. I believe that the additional
lookup gives me the same information that the new junos behaviour tries
to do. It would be helpful though if that extra lookup could be done for
you. Showing the bgp prefix age as well as the protocol next-hops age in
the same view.

If a additional timer would be added I rather have an age since the last
bgp route selection change.

Kindly

Magnus




 
 
On 2018-04-19 22:12, Niall Donaghy wrote:
>
> Hi Jeff,
>
>  
>
> Niall> I suggest the default should be on-the-wire as this incurs the
> minimal CPU hit, as I understand it.
>
> Jeff> Please consider the extra CPU hit to be marginal.  It's the
> memory hit that's the main concern for having more than one timer.
>
>  
>
> I should also add that as I previously stated, I find the
> ‘on-the-wire’ age to be the most intuitive one / ‘rule of least
> surprise’, etc.
>
> I read the age as ‘age of route to destination {via this BGP
> speaker}’, as I presume Magnus (OP) also intuits.
>
>  
>
> HTH, and again, thanks for your diligence in soliciting user input on
> this one. :)
>
>  
>
> Br,
>
> Niall
>
>  
>
> *From:*Jeff Haas [mailto:jhaas at juniper.net]
> *Sent:* 19 April 2018 21:00
> *To:* Niall Donaghy <niall.donaghy at geant.org>
> *Cc:* Magnus Bergroth <bergroth at nordu.net>; juniper-nsp
> <juniper-nsp at puck.nether.net>
> *Subject:* Re: [j-nsp] Juniper route age reset behavior
>
>  
>
> Niall,
>
>  
>
> I'll answer clarifying questions, but hope to remain mostly silent
> while people offer their opinions.
>
>  
>
>     On Apr 19, 2018, at 3:46 PM, Niall Donaghy
>     <niall.donaghy at geant.org <mailto:niall.donaghy at geant.org>> wrote:
>
>     Jeff> Thus, a knob is being considered to have both the "only
>     on-the-wire" impact or the "whenever the route's properties
>     change" impact.
>
>      
>
>     Can I suggest a knob with three options – the two you mention,
>     plus an option to maintain /both/ timers? If that’s not feasible
>     (for reasons you already eluded), so be it.
>
>     My preference is indeed for ‘best of both’.
>
>  
>
> I don't believe we'll be adding a second timer at this time.
>
>  
>
> We have proposals in mind that may permit variable sizing of some of
> our core data structures.  Once we have such a thing, we may consider
> such optional memory-hungry features.  I know I want to do several
> things with them. :-)
>
>  
>
>      
>
>     Jeff> The question being: What's the default?
>
>      
>
>     As you indicated, quite a few folk on older hardware will be
>     sensitive to resource impacts.
>
>     I suggest the default should be on-the-wire as this incurs the
>     minimal CPU hit, as I understand it.
>
>  
>
> Please consider the extra CPU hit to be marginal.  It's the memory hit
> that's the main concern for having more than one timer.
>
>  
>
> -- Jeff
>
>  
>