[c-nsp] BGP DFZ convergence time - FIB programming

[adamv0025 at netconsultings.com]

> Tim Warnock
> Sent: Friday, October 12, 2018 2:14 AM
> 
> > -----Original Message-----
> > From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf
> > Of Robert Raszuk So for educational purposes could you describe some
> > real valid use cases to apply bgp policies on routes *received* over
> > IBGP ?
> >
> > Thx,
> > Robert.
> 
> Setting local preference?
> 
> Rewriting next hop?
>
I  think Robert was interested in use cases not what attribute can be set in
ingress on an iBGP session.

This question got me thinking actually,

There are several possible attach-points that can be used to manipulate the
iBGP route before it gets installed into RIB, (ibgp session/vrf
import/BGP->RIB)
Now would you say all of these are sort of in the inbound direction from the
iBGP perspective? After all the iBGP route would be subject to all these
before it gets installed to RIB. 

With regards to the use cases, 
I think that one common trait of all the use cases relying on either of the
above mentioned attach points, is the need to manipulate how the route is
treated locally on the receiving BGP speaker -which ,driven by the use case,
would be in contrary with how the same route is treated on all other
speakers in the AS. (think one size does not fit all)
Thinking about it this need for ingress policy on iBGP sessions is rooted in
the fact that one (by default and no hacks) can't "process" a BGP route for
the same prefix multiple times where each copy would be intended only for a
specific receiver or a set of receivers.   
The specifics of how that is accomplished are irrelevant, but what stays is
that a policy in "ingress" direction is indeed required in these use cases. 


//yes I know I should not be using term "bgp route" in context of bgp
process and should be using term "prefix" or "path" instead.
 
adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::