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

[Gyan Mishra <[e-mail]>]

Hi Enke

I am still trying to understand the need for this draft.


Their are two main methods to locally originate routes into BGP done at the
customer edge which is via redistribution or network statement.  When you
redistribute routes into BGP the origin flag is set to incomplete.  When
you use a network statement with exact match of prefix installed in the
RIB, the route origin changes to IGP origin.   The pecking order for Orgin
is EGP, IGP, Incomplete so if the routes is also advertised via network
statement and redistribution by two different ASBR the best path selection
will converge on the best path IGP origin via network statement over
redistribution.  Maybe that is the intention of the draft to prefer
incomplete over IGP origin and that can be set via policy as well so that
both are equal so load balancing can occur.

At the bottom of page 2 below is stated as the premise for this draft.

Currently the admin-distance does not play any role in BGP route
selection.


I disagree.  Indeed AD plays an important role in redistribution or
locally sourcing of prefixes into BGP advertisement.  All vendor
implementations do this the same way and that is that only the lowest
AD source

Of a particular prefix is what is installed onto the RIB and FIB.  So
when doing either a redistribution or using network statement exact
match to source local routes into a BGP advertisement only the
prefixes installed in the RIB that match exactly via network statement
or if you have a redistribution policy matches the prefix and source
protocol for the route being redistributed.


Let’s say you have a redistributing OSPF into BGP however their is a
static route exact match for the prefix you want to redistribute that
matches your redistribution prefix list

however as OSPF has AD 110 and static had AD 1 default and if you are
trying to redistribute ospf into BGP the redistribution will not work
since the RIB has the static route as the source for the prefix
installed in the RIB.


Example of how AD plays an important role in how redistribution can or
may not occur properly due to AD of the protocol sourcing the prefix

And the protocol being redistributed must match or the redistribution will fail.


I have noticed one issue with both redistribution and network
statement which is problematic is that the IGP metric is passed into
BGP as MED which is higher in the BGP best path selection which can
result in sub optimal routing.  The workaround is to reset MED to 0
with a policy.



Kind Regards


Gyan


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

>
> The main protocols are BGP, OSPF, ISIS, Static
>
> Juniper
>
>
> https://www.juniper.net/documentation/en_US/junose15.1/topics/task/configuration/ip-route-administrative-distance-configuration.html
>
> Route Source
>
> Default Distance
>
> Connected interface
>
> 0
>
> Static route
>
> 1
>
> Internal access route
>
> 2
>
> Access route
>
> 3
>
> External BGP
>
> 20
>
> OSPF
>
> 110
>
> IS-IS
>
> 115
>
> RIP
>
> 120
>
> Internal BGP
>
> 200
>
> Unknown
>
> 255
>
>
> Cisco
>
>
> https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/15986-admin-distance.html
>
>
> Route SourceDefault Distance Values
> Connected interface 0
> Static route 1
> Enhanced Interior Gateway Routing Protocol (EIGRP) summary route 5
> External Border Gateway Protocol (BGP) 20
> Internal EIGRP 90
> IGRP 100
> OSPF 110
> Intermediate System-to-Intermediate System (IS-IS) 115
> Routing Information Protocol (RIP) 120
> Exterior Gateway Protocol (EGP) 140
> On Demand Routing (ODR) 160
> External EIGRP 170
> Internal BGP 200
> Unknown* 255
>
>
>
> On Thu, Jul 1, 2021 at 2:54 PM Robert Raszuk <[e-mail]> wrote:
>
>> 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*
>>>
>>> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email [e-mail] <[e-mail]>*
>
>
>
> *M 301 502-1347*
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*