Re: [Idr] draft-chen-bgp-redist-01.txt

["Jakob Heitz (jheitz)" <[e-mail]>]

The difficulty with that is that IBGP and EBGP also have an admin-distance and the admin-distance of those routes is not used and cannot be used in the best path tie breaker.

Regards,
Jakob.


On Jul 2, 2021, at 1:13 AM, Robert Raszuk <[e-mail]> wrote:



> The draft addresses the different outcome if BGP learns the route
> first from it peer or learns it first from the local RIB.

Yes that is section 2.1

However, more interesting to me is the scenario described in section 2.2 - Network-wide Behavior  - no local peers.

Here by setting AD on a per route basis and propagating it via IBGP using Local Preference we get consistent active-backup network wide.

Thx,
R.



On Fri, Jul 2, 2021 at 8:33 AM Jakob Heitz (jheitz) <[e-mail]<mailto:[e-mail]>> wrote:
Admin-distance is not defined in any RFCs. It is a vendor only concept.
I can speak about it from the Cisco IOS-XR and Redback perspective.
In both of these implementations, RIB and BGP are separate processes
with separate memory spaces and their own routing tables.
Routes are passed between them using inter-process communication messages.
They cannot access each other's routing tables. Other routing protoclos,
such as OSPF, ISIS and static are also separate processes. Each of the routing
protocols downloads their valid routes to RIB. If the same IP prefix is
sent to RIB by multiple routing protocols, RIB will select one to be used
for forwarding and resolving nexthops. RIB uses admin-distance to decide.
Routing protocols get their local routes from RIB.

A static route has admin-distance of 1 by default.
However, a static route can be configured with a different admin-distance.
It is possible to configure a backup static route by configuring a high
admin-distance for it.
In that case, if another route is found for the given prefix by another
routing protocol, say an ISIS route, then the ISIS route will be used
for forwarding. Only if the ISIS route disappears will the backup static
route be used.

Now, suppose we want to advertise that prefix in BGP. We can do that
with a "redistribute" statement or with a "network" statement.
They work a little bit differently, but either command will import
the route from the RIB into BGP.
Once the route is in BGP, it loses its admin-distance.
BGP has no knowledge of the admin-distance that this route had in RIB.
There is no admin-distance in section 9.1 of RFC 4271.
This is the root of the problem that Enke and Jenny are trying to solve.

The problem occurs if the same prefix can be learnt by BGP from
a BGP peer. BGP may download it into RIB. The draft addresses the
different outcome if BGP learns the route first from it peer or learns
it first from the local RIB.

Regards,
Jakob.