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

[Robert Raszuk <[e-mail]>]

Gyan,

> My understanding is by default most all implementations that I know of
for example Cisco & Juniper which have use identical default AD

Can you provide source(s) of your above information ?

To the best of my knowledge they are quite different ...

Cisco:

[image: image.png]

Juniper:

[image: image.png]

Except connected I do not see much of "identical default AD"

And that is as the draft says especially important when your intention is
to control active - backup paths for a given net.

Thx,
R.


On Thu, Jul 1, 2021 at 8:02 PM Gyan Mishra <[e-mail]> wrote:

>
> Hi Enke
>
> My understanding is by default most all implementations that I know of for
> example Cisco & Juniper which have use identical default AD, redistribution
> of the route only occurs from the source protocol that is being
> redistributed for example static versus OSPF or ISIS based on AD.
>
> So if you have multiple protocols redistribution into BGP, the source
> protocol with the lowest AD is what is inserted into the default RIB/FIB
> and its that specific route from the source protocol that is redistributed
> into BGP.   All implementations that I know of work that way.
>
> I don’t see any issue with deterministic redistribution as exists today
> with implementations.
>
> Normally you are only running one IGP but let’s say you are running OSPF
> and ISIS and you have a Juniper and Cisco ASBR redistribution into BGP, as
> OSPF has default AD 110, the OSPF prefix would be inserted into the Default
> RIB and redistributed into BGP.  Let’s say you set AD for ISIS down to 90
> and now the ISIS route is inserted into the RIB and now both Juniper and
> Cisco ASBR Will redistribute the ISIS route into BGP.
>
> I am not seeing the issue that you are trying to solve.
>
> Kind Regards
>
> Gyan
>
> On Wed, Jun 30, 2021 at 3:19 AM Enke Chen <[e-mail]>
> wrote:
>
>> Hi, Robert:
>>
>> 1) Usually the default admin-distance is configurable. Having the same
>> admin-distance across implementations would certainly make things simpler,
>> but that is not required. What matters is the local_pref value for the
>> redistribute backup route:
>>
>>             local_pref = default_local_pref - delta;
>>
>> It needs to be in the right order (relatively) for the "role" the route
>> is supposed to play.
>>
>> It's a good question. We will try to clarify it in the next revision.
>>
>> 2) Certainly it would work if we define the "delta" (or "local_pref") for
>> the redistributed route based on its role (e.g., primary, secondary,
>> tertiary). But extra config would be needed for specifying the "role".  The
>> algorithm described in the draft does not require additional config other
>> than the existing "admin-distance".  When more than two paths are involved
>> in a multi-vendor environment, the admin-distance needs to be carefully
>> assigned in order to get the desired local_pref value.
>>
>> Thanks.   -- Enke
>>
>> On Tue, Jun 29, 2021 at 1:05 PM Robert Raszuk <[e-mail]> wrote:
>>
>>> Hi Enke,
>>>
>>> How do you assure that admin distance is the same or delta would be the
>>> same across implementations ?
>>>
>>> Looking at say junos I see quite different values then when comparing
>>> with other implementations ...
>>>
>>>
>>> https://www.juniper.net/documentation/en_US/junos/topics/reference/general/routing-protocols-default-route-preference-values.html
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.juniper.net_documentation_en-5FUS_junos_topics_reference_general_routing-2Dprotocols-2Ddefault-2Droute-2Dpreference-2Dvalues.html&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=iUboWFiSpP9QvSDj9hoG8_DO7R_8EOQvfEHnwyX-mc0&s=GOhXjwEf1z0GAfIQVgVAc4sHvcAog6czTO30VhKwzQk&e=>
>>>
>>> Would it be simpler to define here verbatim what the local pref should
>>> be for redistributed routes ? Then at least those could be used as default
>>> local pref values unless overwritten by operator's policy during
>>> redistribution.
>>>
>>> Thx,
>>> Robert
>>>
>>>
>>> On Tue, Jun 29, 2021 at 7:14 PM Enke Chen <[e-mail]>
>>> wrote:
>>>
>>>> Hi, Folks:
>>>>
>>>> Apologies for the very long delay in updating the draft:
>>>>
>>>>        https://datatracker.ietf.org/doc/draft-chen-bgp-redist/01/
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dchen-2Dbgp-2Dredist_01_&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=iUboWFiSpP9QvSDj9hoG8_DO7R_8EOQvfEHnwyX-mc0&s=IBn3kTJmGrWISvSq8L3M9GLLamXIqw7t2PvEdtvhmos&e=>
>>>>
>>>> The issue still exists, and shows up from time to time. The revised
>>>> version provides a complete solution that covers the use cases involving a
>>>> single router as well as multiple routers in a network.
>>>>
>>>> Your review and comments are welcome.
>>>>
>>>> Thanks.   -- Enke
>>>>
>>>>
>>>> _______________________________________________
>>>> Idr mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/idr
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=iUboWFiSpP9QvSDj9hoG8_DO7R_8EOQvfEHnwyX-mc0&s=O1wpTf7XmDmE4-mQGDJ9YNEx2UVZW-k1meY3fd-tQrE&e=>
>>>>
>>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr
>>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email [e-mail] <[e-mail]>*
>
>
>
> *M 301 502-1347*
>
>