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

[Robert Raszuk <[e-mail]>]

Jakob,

> On Fri, Jul 2, 2021 at 1:32 PM Jakob Heitz (jheitz) <[e-mail]>
wrote:

> 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.
>

I think it really does not matter (yes originally I was also asking to
myself the same question).

Reason why this does not matter is that ebgp vs ibgp comparison is much
further in best path selection then local pref.

So BGP will overall select the best and push it to the RIB. Of course for
this entire scheme to work BGP now has to lie and neither say this is EBGP
not IBGP learned route but say use new admin distance 0.5 :)  Otherwise
static will overwrite any BGP produced route in RIB which is not what we
want in the first place.

Thx,
R.

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]>
> 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.
>>
>