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

From: Gyan Mishra <[email-masked]>
Date: Thu, 1 Jul 2021 14:02:25 -0400

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 <[email-masked]>
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 <[email-masked]> 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 <[email-masked]>
>> 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
>>> [email-masked]
>>> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 1 Jul 2021 20:54:36 +0200

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:

Juniper:

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 <[email-masked]> wrote:

>> It needs to be in the right order (relatively) for the "role" the route
>> is supposed to play.
>>
>>> 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

---

From: Brian Dickson <[email-masked]>
Date: Thu, 1 Jul 2021 13:41:34 -0700

Top-reply, sorry if anyone doesn't like that.

So, serious question:
What if the solution to this problem is simply, "do not redistribute
anything into BGP"?
(If that is the case, maybe changing this draft to say that and nothing
else is the best approach?)

Specifically, instead of doing any redistributes, configure a prefix as
locally originated (in cisco-speak, "network" within a BGP config section,
IIRC).
The BGP rules would result in it being announced into BGP if and only if it
is (and only while it continues to be) resolvable (i.e. has a next hop in
the RIB, I believe.)

Does this actually fix the problem?
(I have never liked redistribution, as it leads to a lot of funky behavior,
including extraneous update messages that pollute the global BGP DFZ.)

Brian

On Thu, Jul 1, 2021 at 11:55 AM Robert Raszuk <[email-masked]> wrote:

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

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 1 Jul 2021 22:50:24 +0200

Brian,

In general you are correct that BGP would be much better if it would
only carry originated (somewhere) prefixes.

However the reality is that you have customers hanging off your network
with static routes or ospf. Even worse some of those customers got recently
fancy and they are multihomed what makes dynamic routing quite useful
to/from such sites.

So you can either put those customer prefixes to BGP or carry it with your
say separate IGP instance. You could also just put them into controller and
only deal with end to end encapsulations to get ingress to egress packets
via your network.

Well people like simplicity so just put those into BGP then aggregate it
(especially if those chucks are coming out of ones space).

This draft is trying to help with this in situations where you have
requirement for active-backup somehow predictable path selection.

Best,
Robert.

On Thu, Jul 1, 2021 at 10:41 PM Brian Dickson <[email-masked]>
wrote:

> The BGP rules would result in it being announced into BGP if and only if
> it is (and only while it continues to be) resolvable (i.e. has a next hop
> in the RIB, I believe.)
>
> (I have never liked redistribution, as it leads to a lot of funky
> behavior, including extraneous update messages that pollute the global BGP
> DFZ.)
>
> Brian
>
>>>>> How do you assure that admin distance is the same or delta would be
>>>>> the same across implementations ?
>>>>>

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Thu, 1 Jul 2021 21:24:34 +0000

Enke,

              I understand what you are driving at in the draft but is it specific to local routes being redistributed and the timing of.  Can this be generalized to other protocol redistribution i.e. OSPF, ISIS? Can you describe other scenarios involving redistribution of state from IGP protocols?

Would this or similar issues be possible if we are migrating from an IGP to a BGP LU solution and redistributing NHs. It seems that it is not AFI/SAFI specific..

Thanks,
              Jim Uttaro

From: Idr <[email-masked]> On Behalf Of Enke Chen
Sent: Tuesday, June 29, 2021 1:14 PM
To: idr@ietf. org <[email-masked]>
Cc: Jenny Yuan <[email-masked]>
Subject: [Idr] draft-chen-bgp-redist-01.txt

Hi, Folks:

       https://datatracker.ietf.org/doc/draft-chen-bgp-redist/01/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-chen-bgp-redist/01/__;!!BhdT!1VhLEdVG26zxX8nYSU3PKvPID9l8KGPdGF-8XBNnJkjGNO6Jj4SmmzPxLng$>

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.

Thanks.   -- Enke

---

From: Enke Chen <[email-masked]>
Date: Thu, 1 Jul 2021 14:48:46 -0700

Hi, Brian:

The route sourced by the "network" command has the same ordering issue as
the route sourced by the "redistribute" command.

Thanks.   -- Enke

On Thu, Jul 1, 2021 at 1:42 PM Brian Dickson <[email-masked]>
wrote:

>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=snEqNB2zn3PvbOz6evLTF_RY0Y4hzTk6um8tPviaKC0&s=8-pP2p8g4JLMvXje26e9nDe3D3DL9meBfLpDGDkyfvk&e=>
>>>>
>>> --
>>>
>>>
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.verizon.com_&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=snEqNB2zn3PvbOz6evLTF_RY0Y4hzTk6um8tPviaKC0&s=_ULOmZGbd9QRxwUuthq4UtFMoMWiPDLHMxcRhJYAlk0&e=>
>>>
>>> *Gyan Mishra*
>>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=snEqNB2zn3PvbOz6evLTF_RY0Y4hzTk6um8tPviaKC0&s=8-pP2p8g4JLMvXje26e9nDe3D3DL9meBfLpDGDkyfvk&e=>
>>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwICAg&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=snEqNB2zn3PvbOz6evLTF_RY0Y4hzTk6um8tPviaKC0&s=8-pP2p8g4JLMvXje26e9nDe3D3DL9meBfLpDGDkyfvk&e=
>

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 1 Jul 2021 20:23:45 -0400

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

*Gyan Mishra*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 1 Jul 2021 20:56:12 -0400

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

*Gyan Mishra*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 1 Jul 2021 21:17:37 -0400

>From a network design POV, in general within a an IP transit AS their is no
need to redistribute BGP into IGP unless their are non BGP speaking routers
within the network.

As for sourcing routes into BGP advertisement from a customer edge best
practice is to originate the advertisement as close to the source routers
as possible, and if it’s a summary then use a network statement and if LPM
routes are required then redistribution of IGP into BGP via policy is the
best way but also as close to the source of the prefixes.

>From a core perspective IP or MPLS it is common to redistribute connected
or IGP into BGP global table still separate from customer traffic in SP
operator core where MPLS any-any VPN VRF is used to carry Internet traffic
and in that case the NOC may sit in the Internet VRF and NMS systems need
telemetry access back to the global table.

Kind Regards

Gyan

On Thu, Jul 1, 2021 at 8:56 PM Gyan Mishra <[email-masked]> wrote:

> 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
> 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
>
> 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
>
>
>>> And that is as the draft says especially important when your intention
>>> is to control active - backup paths for a given net.
>>>
>>> Thx,
>>> R.
>>>
>>>
>>>> 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.
>>>>
>>>>> It needs to be in the right order (relatively) for the "role" the
>>>>> route is supposed to play.
>>>>>
>>>>>> 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 <
>>>>>> [email-masked]> wrote:
>>>>>>
>>>>>>> Hi, Folks:
>>>>>>>

*Gyan Mishra*

*M 301 502-1347*

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 2 Jul 2021 06:33:24 +0000

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.

From: Idr <[email-masked]> On Behalf Of Gyan Mishra
Sent: Thursday, July 1, 2021 6:18 PM
To: Robert Raszuk <[email-masked]>
Cc: idr@ietf. org <[email-masked]>; Jenny Yuan <[email-masked]>
Subject: Re: [Idr] draft-chen-bgp-redist-01.txt

From a network design POV, in general within a an IP transit AS their is no need to redistribute BGP into IGP unless their are non BGP speaking routers within the network.

As for sourcing routes into BGP advertisement from a customer edge best practice is to originate the advertisement as close to the source routers as possible, and if it’s a summary then use a network statement and if LPM routes are required then redistribution of IGP into BGP via policy is the best way but also as close to the source of the prefixes.

From a core perspective IP or MPLS it is common to redistribute connected or IGP into BGP global table still separate from customer traffic in SP operator core where MPLS any-any VPN VRF is used to carry Internet traffic and in that case the NOC may sit in the Internet VRF and NMS systems need telemetry access back to the global table.

Kind Regards

Gyan

On Thu, Jul 1, 2021 at 8:56 PM Gyan Mishra <[email-masked]<mailto:[email-masked]>> wrote:

Hi Enke

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.

selection.

Kind Regards

Gyan

On Thu, Jul 1, 2021 at 8:23 PM Gyan Mishra <[email-masked]<mailto:[email-masked]>> wrote:

Juniper

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

Route Source
Default 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 <[email-masked]<mailto:[email-masked]>> wrote:
Gyan,

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

Cisco:

Juniper:

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 <[email-masked]<mailto:[email-masked]>> 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.

Kind Regards

Gyan

On Wed, Jun 30, 2021 at 3:19 AM Enke Chen <[email-masked]<mailto:[email-masked]>> 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:

It needs to be in the right order (relatively) for the "role" the route is supposed to play.

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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Folks:

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

Thanks.   -- Enke

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

---

From: Gert Doering <[email-masked]>
Date: Fri, 2 Jul 2021 09:02:19 +0200

Hi,

> What if the solution to this problem is simply, "do not redistribute

In real-network deployments this is not feasible.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 2 Jul 2021 10:12:24 +0200

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

---

From: tom petch <[email-masked]>
Date: Fri, 2 Jul 2021 09:20:50 +0000

________________________________________
From: Idr <[email-masked]> on behalf of Jakob Heitz (jheitz) <jheitz=[email-masked]>
Sent: 02 July 2021 07:33
To: Gyan Mishra; Robert Raszuk
Cc: idr@ietf. org; Jenny Yuan
Subject: Re: [Idr] draft-chen-bgp-redist-01.txt

<tp>

I encounter it in (at least)

RFC8349
RFC8022
ospf-yang

Tom Petch

Regards,
Jakob.

Kind Regards

Gyan

Hi Enke

selection.

Kind Regards

Gyan

Juniper

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

Route Source
Default Distance Values
Connected interface
0
Static route
1

Cisco:

Juniper:

Thx,
R.

Hi Enke

Kind Regards

Gyan

Thanks.   -- Enke

Thx,
Robert

Thanks.   -- Enke

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 2 Jul 2021 11:32:49 +0000

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.

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) <[email-masked]<mailto:[email-masked]>> wrote:

Regards,
Jakob.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 2 Jul 2021 14:48:17 +0200

Jakob,

> On Fri, Jul 2, 2021 at 1:32 PM Jakob Heitz (jheitz) <[email-masked]>
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.

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 2 Jul 2021 10:39:51 -0400

Hi Jakob & Enke

I agree with everything you are saying.

Agreed no admin distance concept in BGP RFC 4271.

In that case of locally generated via network statement or redistribution
versus a route the route locally generated is at the top of the best path
selection and gets a weight of 32768 and becomes always preferred over a
BGP learned route.

https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html

Step 3 in best path selection is locally generated route from network
statement or redistribution and the locally generated route gets a weight
of 32768.

This is implementation specific as far as weight being added to locally
generated routes and not sure if all vendors do this but as weight is at
the top of the best path selection it is advertised over the learned
route.  This can be very problematic so care has to be taken when locally
generating a route that is also learned via BGP.  In that particular case
the best practice is to NOT locally generate if learned via BGP.  That can
be easily done by removing the exact match network statement for the prefix
learned or using a redistribution filter to exclude the route learned via
BGP so the learned route is preferable over the redistribution route.

So the solution to the problem of local versus learned prefix is
deterministic but is vendor implementation specific.  I would stand by the
best practice I mentioned to only locally generate if the route is not
learned via BGP.  Also if a route is learned via BGP the ab aggregate
should be used tp create an atomic aggregate if that’s the goal summary
only with advertise or suppress map etc or just generate the aggregate if
desired and not suppress component prefixes.  In this case we are talking
about exact match via network statement or redistribution matching a
learned route and not generating a summary.

The use case provided by Enke is not common as most providers do not want
to implement any static routing or anything static for that matter.  This
same scenario described in 2.2 can be accomplished simply by the customer
to de-prefer the backup path to R2 in/out.  Done.

In the example described in 2.2 R2 has static with high admin distance
“floating static” as backup route so is never installed in RIB/FIB unless
R1 stops advertising the iBGP route AD 200.  So routing remains
deterministic as R1 is primary path and when it redistributes the route
locally generated the route gets a 32768 weight preferring the path over
any leaned route as weight is at the top of BGP best path selection and R2
cannot perform the action to redistribute the route until the iBGP route AD
200 goes away.  Once R1 fails the floating static is triggered and
redistributed into BGP and now R3 routes via R2.  Done.

I am not seeing what is broken here or a need to have AD context which is
locally significant and unique to each vendor and does not have to match.

The key here is that the redistribution trigger does not even occur until
the route is inserted into the RIB/FIB forwarding plane as primary and
until that happens it remains backup and not triggered until R1 fails or
stops advertisement.

Kind Regards

Gyan

On Fri, Jul 2, 2021 at 2:33 AM Jakob Heitz (jheitz) <[email-masked]>
wrote:

> *From:* Idr <[email-masked]> *On Behalf Of * Gyan Mishra
> *Sent:* Thursday, July 1, 2021 6:18 PM
> *To:* Robert Raszuk <[email-masked]>
> *Cc:* idr@ietf. org <[email-masked]>; Jenny Yuan <[email-masked]
> >
> *Subject:* Re: [Idr] draft-chen-bgp-redist-01.txt
>
>
>
>
>
> From a network design POV, in general within a an IP transit AS their is
> no need to redistribute BGP into IGP unless their are non BGP speaking
> routers within the network.
>
>
>
> *Route Source*
> *Default Distance Values*
>
> Connected interface
>
> 0
>
> Static route
>
> 1
>
> *Network Solutions Architect *
>
> *Network Solutions Architect *
>
> *Network Solutions Architect *
>
> *Network Solutions Architect *
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Enke Chen <[email-masked]>
Date: Fri, 2 Jul 2021 09:51:23 -0700

Hi, Jim:

Although the static routing is used as examples in the draft, the issues
are generic between BGP and RIB, regardless of the source/protocol of the
RIB route. The proposed solution is also generic. We will look at the draft
to see if there are places that need to be generalized.

Yes, the issues and the proposed solution are AFI/SAFI agnostic as long as
the AFI/SAFI has similar RIB interaction (i.e., route redistribution and
download) and uses the same BGP route selection algorithm.

Thanks.   -- Enke

On Thu, Jul 1, 2021 at 2:24 PM UTTARO, JAMES <[email-masked]> wrote:

> *Enke,*
>
>
>
> *              I understand what you are driving at in the draft but is it
> specific to local routes being redistributed and the timing of.  Can this
> be generalized to other protocol redistribution i.e. OSPF, ISIS? Can you
> describe other scenarios involving redistribution of state from IGP
> protocols? *
>
>
>
> *Would this or similar issues be possible if we are migrating from an IGP
> to a BGP LU solution and redistributing NHs. It seems that it is not
> AFI/SAFI specific..*
>
>
>
> *Thanks,*
>
> *              Jim Uttaro*
>
>
>
> *From:* Idr <[email-masked]> *On Behalf Of * Enke Chen
> *Sent:* Tuesday, June 29, 2021 1:14 PM
> *To:* idr@ietf. org <[email-masked]>
> *Cc:* Jenny Yuan <[email-masked]>
> *Subject:* [Idr] draft-chen-bgp-redist-01.txt
>
>
>
> Hi, Folks:
>
>
>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-chen-bgp-redist/01/__;!!BhdT!1VhLEdVG26zxX8nYSU3PKvPID9l8KGPdGF-8XBNnJkjGNO6Jj4SmmzPxLng$>
>
>
>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 2 Jul 2021 20:25:05 +0000

Thanks Tom. You complete my search.

Regards,
Jakob.

-----Original Message-----
From: tom petch <[email-masked]> 
Sent: Friday, July 2, 2021 2:21 AM
To: Jakob Heitz (jheitz) <[email-masked]>; Gyan Mishra <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: idr@ietf. org <[email-masked]>; Jenny Yuan <[email-masked]>
Subject: Re: [Idr] draft-chen-bgp-redist-01.txt

<tp>

RFC8349
RFC8022
ospf-yang

Tom Petch

Regards,
Jakob.

>From a network design POV, in general within a an IP transit AS their is no need to redistribute BGP into IGP unless their are non BGP speaking routers within the network.

As for sourcing routes into BGP advertisement from a customer edge best practice is to originate the advertisement as close to the source routers as possible, and if it's a summary then use a network statement and if LPM routes are required then redistribution of IGP into BGP via policy is the best way but also as close to the source of the prefixes.

Kind Regards

Gyan

Hi Enke

selection.

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

Kind Regards

Gyan

Juniper

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

Route Source
Default Distance Values
Connected interface
0
Static route
1

Cisco:

Juniper:

Thx,
R.

Hi Enke

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.

Kind Regards

Gyan

Thanks.   -- Enke

Thx,
Robert

Thanks.   -- Enke

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

---

From: Alejandro Acosta <[email-masked]>
Date: Fri, 2 Jul 2021 20:50:37 -0400

> it first from the local RIB.

To be honest after reading the draft I still had my doubts.

I just tested it (using old Cisco gear) and the behavior was exactly the 
described in draft. Having said that I have to admit that at the 
beginning I was skeptical about this, but now I believe this draft 
deserve further discussions.

Thanks,

Alejandro,

> *Cc:* idr@ietf. org <[email-masked]>; Jenny Yuan 
> <[email-masked]>
> From a network design POV, in general within a an IP transit AS their 
> is no need to redistribute BGP into IGP unless their are non BGP 
> speaking routers within the network.
>
> As for sourcing routes into BGP advertisement from a customer edge 
> best practice is to originate the advertisement as close to the source 
> routers as possible, and if it’s a summary then use a network 
> statement and if LPM routes are required then redistribution of IGP 
> into BGP via policy is the best way but also as close to the source of 
> the prefixes.
>
> From a core perspective IP or MPLS it is common to redistribute 
> connected or IGP into BGP global table still separate from customer 
> traffic in SP operator core where MPLS any-any VPN VRF is used to 
> carry Internet traffic and in that case the NOC may sit in the 
> Internet VRF and NMS systems need telemetry access back to the global 
> table.
>
> Kind Regards
>
> Gyan
>
>     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.
>
>     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
>
>     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
>
>         <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 Source*
>
>         	
>
>         On Thu, Jul 1, 2021 at 2:54 PM Robert Raszuk
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>             Gyan,
>
>             > My understanding is by default most all implementations
>             that I know of for example Cisco & Juniper which have use
>             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
>             <[email-masked] <mailto:[email-masked]>> 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
>                 On Wed, Jun 30, 2021 at 3:19 AM Enke Chen
>                 <[email-masked]
>                 <mailto:[email-masked]>> 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:
>
>                     It needs to be in the right order (relatively) for
>                     the "role" the route is supposed to play.
>
>                     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
>                     <[email-masked] <mailto:[email-masked]>> 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 ...
>
>                         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
>                         <[email-masked]
>                         <mailto:[email-masked]>> wrote:
>
>                             Hi, Folks:
>
>                             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.
>
>                             [email-masked] <mailto:[email-masked]>
>                     [email-masked] <mailto:[email-masked]>
>                     <https://www.ietf.org/mailman/listinfo/idr>
>
>                 -- 
>
>                 /Network Solutions Architect /
>
>                 /Email [email-masked]
>                 <mailto:[email-masked]>/
>
>                 /M 301 502-1347/
>
>         -- 
>
>         /Network Solutions Architect /
>
>         /Email [email-masked]
>         <mailto:[email-masked]>/
>
>         /M 301 502-1347/
>
>     -- 
>
>     /Network Solutions Architect /
>
>     /Email [email-masked] <mailto:[email-masked]>/
>
>     /M 301 502-1347/
>
> -- 
>
> /Network Solutions Architect /
>
> /Email [email-masked] <mailto:[email-masked]>/
>
> /M 301 502-1347/
>
>

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 3 Jul 2021 00:19:40 -0400

Here are my thoughts on the draft problem statement and a solution I
believe that  exists today by some or maybe all vendors to resolve the
problem.

The issue mentioned in this draft is an inherent issue with BGP RFC 4271
and need for operators for deterministic behavior when all attributes are
equal that the oldest or first advertisement received is the what is
installed in the BGP RIB over the most recent or newest last received
advertisement #10 in the BGP best path selection link below.

10.  When both paths are external, prefer the path that was received first
(the oldest one). == RFC 5004

This step minimizes route-flap because a newer path does not displace an
older one, even if the newer path would be the preferred route based on the
next decision criteria (Steps 11, 12, and 13).

RFC 4271 published in 2006 section 9.1.2,2  F> states the eBGP best path
tie breaker to be  lowest router-id and G> lowest peer IP address.  G> only
comes into play if 2 parallel peers between two routers.

RFC 5004 published in 2007 to avoid best path transitions oscillations
institutes the oldest first advertisement over the newest last
advertisement which is what we are discussing now with this draft about the
same deterministic routing we are trying to achieve.  RFC 5004 critiqued
RFC 4271 that section 9.1,2.2 F> would being random in nature was less
deterministic then oldest versus newest introduced in RFC 5004.

The problem with RFC 5004 was that in an effort to avoid oscillation it
actually created oscillation with non deterministic nature of the oldest
path being preferred over newest as when a link bounces the newest becomes
preferred over the oldest and the nature of base on receipt of the
advertisement in essence is less deterministic.  Also the fact oldest
versus newest is much more random then lowest BGP identifier.

Due to operators looking for deterministic routing, vendors introduced a
knob for operators to reinstating RFC 4291 section 9.1,2.2 F> using  knob
 “BGP bestpath compare-routerid” which led by Cisco and also introduced by
other vendors to provide deterministic BGP path selection.

So with this knob the eBGP all attributes equal tie breaker is no longer
non deterministic but now deterministic always picking the same router
every time with the lowest BGP identifier with this knob set on all eBGP
peering routers to provide deterministic best path selection in both
directions.

For this draft section 2.2 if we use this knob “BGP bestpath
compare-routerid” then that solves the non deterministic nature and problem
statement as now it’s not a timing or race condition or which advertisement
is received first as the results is now always the same based on lowest BGP
identifier.  This vendor implementation specific knob has to be configured
on all eBGP speaking routers for deterministic routing in both directions.

We may want to do a bis version or update to RFC 5004 to change from oldest
versus newest non deterministic routing to deterministic routing
reinstating 9.1.2.2 F>

Kind Regards

Gyan

On Fri, Jul 2, 2021 at 8:51 PM Alejandro Acosta <
[email-masked]> wrote:

> described in draft. Having said that I have to admit that at the beginning
> I was skeptical about this, but now I believe this draft deserve further
> discussions.
>
>
> Thanks,
>
>
> Alejandro,
>
>
>
>
>
>
> Regards,
>
> Jakob.
>
>
>
> *From:* Idr <[email-masked]> <[email-masked]> *On Behalf Of *
> Gyan Mishra
> *To:* Robert Raszuk <[email-masked]> <[email-masked]>
> *Cc:* idr@ietf. org <[email-masked]> <[email-masked]>; Jenny Yuan
> <[email-masked]> <[email-masked]>
> Idr mailing [email-masked]://www.ietf.org/mailman/listinfo/idr
>
> --

*Gyan Mishra*

*M 301 502-1347*

---

From: Enke Chen <[email-masked]>
Date: Fri, 2 Jul 2021 22:56:10 -0700

Hi, Gyan:

The goal of the draft is to support the primary/backup routing scheme in a
network when route redistribution is involved. The behavior needs to be
deterministic and correct.

As a co-author of RFC 5004, I am familiar with it.  The problem described
in the RFC is different from the ones in the draft, and the solution would
not work either.

Thanks.   -- Enke

On Fri, Jul 2, 2021 at 9:19 PM Gyan Mishra <[email-masked]> wrote:

> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.cisco.com_c_en_us_support_docs_ip_border-2Dgateway-2Dprotocol-2Dbgp_13753-2D25.html&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=2kwStMfHhEhk3eVLY_fgtkdqD8XYGT6CX4dBxW3AKHA&s=aKZmdtrk3V2JEJLB41WZJRGcK4rERSGlNu4GsxT9UbY&e=>
>
> We may want to do a bis version or update to RFC 5004 to change from
> oldest versus newest non deterministic routing to deterministic routing
> reinstating 9.1.2.2 F>
>
>
> Kind Regards
>
>
> Gyan
>
>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.juniper.net_documentation_en-5FUS_junose15.1_topics_task_configuration_ip-2Droute-2Dadministrative-2Ddistance-2Dconfiguration.html&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=2kwStMfHhEhk3eVLY_fgtkdqD8XYGT6CX4dBxW3AKHA&s=-WrDCRDmFCpQQxJA5X2_5Xl1xSR9-FQtsvjzYSZk6VI&e=>
>>
>>
>>
>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.cisco.com_c_en_us_support_docs_ip_border-2Dgateway-2Dprotocol-2Dbgp_15986-2Dadmin-2Ddistance.html&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=2kwStMfHhEhk3eVLY_fgtkdqD8XYGT6CX4dBxW3AKHA&s=MGV6BNLM3zBIDIejfGq_4gqAI_u1ZdUbSRT90_nIebY&e=>
>>
>>
>>
>>
>>
>> *Route Source*
>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=2kwStMfHhEhk3eVLY_fgtkdqD8XYGT6CX4dBxW3AKHA&s=YxLkiWI1KnOgmU9FEb371TJ9isd8mdJHEmT5x33RmDY&e=>
>>
>> --
>>
>>
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.verizon.com_&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=2kwStMfHhEhk3eVLY_fgtkdqD8XYGT6CX4dBxW3AKHA&s=YaH0vtoFUdvOXCJVz30TALXqSQU4vzYryXaDtMAzolI&e=>
>>
>> *Gyan Mishra*
>>
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.verizon.com_&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=2kwStMfHhEhk3eVLY_fgtkdqD8XYGT6CX4dBxW3AKHA&s=YaH0vtoFUdvOXCJVz30TALXqSQU4vzYryXaDtMAzolI&e=>
>>
>> *Gyan Mishra*
>>
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.verizon.com_&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=2kwStMfHhEhk3eVLY_fgtkdqD8XYGT6CX4dBxW3AKHA&s=YaH0vtoFUdvOXCJVz30TALXqSQU4vzYryXaDtMAzolI&e=>
>>
>> *Gyan Mishra*
>>
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.verizon.com_&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=2kwStMfHhEhk3eVLY_fgtkdqD8XYGT6CX4dBxW3AKHA&s=YaH0vtoFUdvOXCJVz30TALXqSQU4vzYryXaDtMAzolI&e=>
>>
>> *Gyan Mishra*
>>
>> Idr mailing [email-masked]://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=2kwStMfHhEhk3eVLY_fgtkdqD8XYGT6CX4dBxW3AKHA&s=YxLkiWI1KnOgmU9FEb371TJ9isd8mdJHEmT5x33RmDY&e=>
>>
>> --
>
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.verizon.com_&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=2kwStMfHhEhk3eVLY_fgtkdqD8XYGT6CX4dBxW3AKHA&s=YaH0vtoFUdvOXCJVz30TALXqSQU4vzYryXaDtMAzolI&e=>
>
> *Gyan Mishra*
>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 3 Jul 2021 12:58:08 +0200

> The issue mentioned in this draft is an inherent issue with BGP RFC 4271

No.

The issue occurs regardless of what routing protocol you use to propagate
your routes around. BGP here is just one example of it (quite commonly
used) and local preference is currently suggested as a metric. Sure there
are other options too.

The issue described here is a system issue of interactions between
various route producers. As it happens IETF does not really standardize
system wide behaviours - it focuses on components of it in silos. Hence
from time to time we run into such traps.

As an example I believe the same very issue would occur provided DC
operator would like to use deterministic active-backup if you run Static or
Babel or RIPv2 between TORs and computes and redistribute those into RIFT
to provide flat reachability in the DC fabric.

Best,
Robert.

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 3 Jul 2021 08:27:44 -0400

Understood.

Thank you Enke

Gyan

On Sat, Jul 3, 2021 at 1:56 AM Enke Chen <[email-masked]>
wrote:

>> 10.  When both paths are external, prefer the path that was received
>> first (the oldest one). == RFC 5004
>>
>>> *From:* Idr <[email-masked]> <[email-masked]> *On Behalf Of
>>> * Gyan Mishra
>>> connected or IGP into BGP global table still separate from customer traffic
>>> in SP operator core where MPLS any-any VPN VRF is used to carry Internet
>>> traffic and in that case the NOC may sit in the Internet VRF and NMS
>>> systems need telemetry access back to the global table.
>>>
>>>
>>>
>>>
>>>
>>> Kind Regards
>>>
>>>
>>>
>>> Gyan
>>>
>>>
>>>

*Gyan Mishra*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 3 Jul 2021 08:38:01 -0400

Hi Robert

In-line

Thanks for helping me understand the problem.

Gyan

> > The issue mentioned in this draft is an inherent issue with BGP RFC 4271

Gyan> I meant RFC 5004 - oscillations and non deterministic routing due to
oldest versus newest.

> used) and local preference is currently suggested as a metric. Sure there

Gyan> Understood

> from time to time we run into such traps.

Gyan>. Understood

> to provide flat reachability in the DC fabric.

Gyan>. Thank for explaining

>>> <[email-masked]>

*Gyan Mishra*

*M 301 502-1347*

---

From: Alejandro Acosta <[email-masked]>
Date: Sat, 3 Jul 2021 09:21:44 -0400

Hello,
   As I said before I created a small lab with three routers, just for 
testing purposes.
   Even when the draft is not 100% aimed for BGP I have to say one 
finding (well, maybe you are already aware but at I did not catched it 
when reading the draft) that I believe is important.

In this scenario:

R1 -- R2 -- R3

R1 (AS65001) is announcing 10.0.0.1 (eBGP, AD 20)

R2 (AS65002) has a static floating (AD 150) route pointing to 10.0.0.1 
toward R1.

R3 Learns 10.0.0.1 via R2 and the AS_Origin is set to 65001 (in case 
there is a ROA, RPKI would be fine)

Suppose eBGP session resets between R1 & R2, static floating route takes 
places.

Now R3 learns 10.0.0.1 but AS_Origin is AS 65002 (RPKI fails !!.., 
routing valid, prefix dropped, etc. )

Two more comments:

Even when the eBGP session goes up RIB & BGP in R2 remains static for 
10.0.0.1

Even when the eBGP session goes up RIB & BGP in R3 AS_Path still 
indicating 65001 as AS_ORIGIN

Well, hope it helps and I made myself understood.

Thanks,

Alejandro,

On 2/7/21 8:50 PM, Alejandro Acosta wrote:
> I just tested it (using old Cisco gear) and the behavior was exactly 
> the described in draft. Having said that I have to admit that at the 
>> best practice is to originate the advertisement as close to the 
>> source routers as possible, and if it’s a summary then use a network 
>> into BGP via policy is the best way but also as close to the source 
>> of the prefixes.
>>
>>     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.
>>
>>     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
>>
>>                 BGP, the source protocol with the lowest AD is what
>>                 is inserted into the default RIB/FIB and its that
>>                 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.
>>
>>                     across implementations would certainly make
>>                     things simpler, but that is not required. What
>>                     matters is the local_pref value for the
>>                     It needs to be in the right order (relatively)
>>                     for the "role" the route is supposed to play.
>>
>>                     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
>>
>>                         unless overwritten by operator's policy
>>                         during redistribution.
>>
>>                         Thx,
>>                         Robert
>>
>>                             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.
>>

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 3 Jul 2021 08:18:40 -0400

Hi Alejandro

Thanks for validating.  Yes so your test validates RFC 5004 at work with
first received oldest is best over the newest or last received.

On Sat, Jul 3, 2021 at 9:22 AM Alejandro Acosta <
[email-masked]> wrote:

>   Even when the draft is not 100% aimed for BGP I have to say one finding
> (well, maybe you are already aware but at I did not catched it when reading
> the draft) that I believe is important.
>
> In this scenario:
>
> R1 -- R2 -- R3
>
> R3 Learns 10.0.0.1 via R2 and the AS_Origin is set to 65001 (in case there
> is a ROA, RPKI would be fine)
>
Gyan> So the oldest or first received is BGP learned route from R1 is
preferred

> Now R3 learns 10.0.0.1 but AS_Origin is AS 65002 (RPKI fails !!.., routing
> valid, prefix dropped, etc. )
>
Gyan> So now the oldest or first installed is the static as the bgp learned
from R1 is gone

> Gyan> Does it seem to be consistent that every time the BGP session comes
> up that R3 sees 65001 as origin which means BGP learned is the oldest first
> received over the static.  Strange.  I would have though that if the static
> on R2 was installed first and then the BGP session came up between R1 & R2
> that the static locally originated would always be the oldest first
> received and R3 would show AS 65002 and that would happen consistently.  I
> would think the only time the BGP learned would be oldest first received
> showing 65001 AS path on R3 is if the static was configured after the BGP
> session was up.
>
>
>
>

-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 3 Jul 2021 08:41:55 -0400

Alejandro

This is what I thought initially what would be happening but then when down
the road of RFC 5004 of oldest being preferred over newest.

So it seems that the lowest AD is what is installed and that changes
dynamically.  So with R2 static AD 150,  the static being installed first
and then as soon
as the BGP peer comes up R1 to R2 the eBGP route takes precedence AD 20 on
R2 is valid/best dynamically changes due to AD installed in RIB & BGP RIB
and advertised to R3.

Can you see the route change so lets say if you have the static installed
on R2, then on R3 you see AS path 65002 and then as soon as the BGP session
comes up
R1 to R2 then R3 sees AS path 65001.  So Cisco is using AD during the
initial install of the route when the peer comes UP.

However when the session is reset then R2 locally originates is preferred
as that is the oldest and and R3 now sees as-path 65001.

I think this maybe a code issue older hardware you mentioned with the
inconsistency.

So when  the peer comes up initially R2 uses AD for best path but then when
a session reset happens it reverts to oldest versus newest RFC  5004.

I would think it would do one or the other either use AD consistently or
use oldest versus newest consistently but its not doing that.

Great job testing!

I will try in my lab on newer hardware if that makes any difference.

Gyan

On Sat, Jul 3, 2021 at 8:18 AM Gyan Mishra <[email-masked]> wrote:

> Gyan> So now the oldest or first installed is the static as the bgp
> learned from R1 is gone
>
>> Two more comments:
>>

-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Enke Chen <[email-masked]>
Date: Sat, 3 Jul 2021 15:42:45 -0700

Hi, Alejandro:

If I understand correctly, what you have described is a routing scenario
for a multi-homed customer involving multiple AS'es. It's different from
the one described in the draft.

In your description, the prefix can be legitimately sourced by more than
one AS. Thus it should be registered with multiple AS origins.

Thanks.   -- Enke

On Sat, Jul 3, 2021 at 6:22 AM Alejandro Acosta <
[email-masked]> wrote:

> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.juniper.net_documentation_en-5FUS_junose15.1_topics_task_configuration_ip-2Droute-2Dadministrative-2Ddistance-2Dconfiguration.html&d=DwMDaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=zpEblJ3z3c0OEtuNzktkKuxjjMU1yKtGwU8enmtyOkw&s=735ipugi7SGesVlY0SEFmSNpYqTCsecAg_O1SMKNSOQ&e=>
>
>
>
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.cisco.com_c_en_us_support_docs_ip_border-2Dgateway-2Dprotocol-2Dbgp_15986-2Dadmin-2Ddistance.html&d=DwMDaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=zpEblJ3z3c0OEtuNzktkKuxjjMU1yKtGwU8enmtyOkw&s=V01amfitHyWGAZGUhzoFgDiAai3FDMero5ckZo5B26Q&e=>
>
>
>
>
>
> *Route Source*
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwMDaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=zpEblJ3z3c0OEtuNzktkKuxjjMU1yKtGwU8enmtyOkw&s=vmp12DPUncS015OY67eHSJ77dpplP6_0iEmETUGbkqA&e=>
>
> --
>
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.verizon.com_&d=DwMDaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=zpEblJ3z3c0OEtuNzktkKuxjjMU1yKtGwU8enmtyOkw&s=nNdwoitq7zPtB6SnDiG5nhTMR6auXZdN8sOG2xwGICw&e=>
>
> *Gyan Mishra*
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.verizon.com_&d=DwMDaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=zpEblJ3z3c0OEtuNzktkKuxjjMU1yKtGwU8enmtyOkw&s=nNdwoitq7zPtB6SnDiG5nhTMR6auXZdN8sOG2xwGICw&e=>
>
> *Gyan Mishra*
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.verizon.com_&d=DwMDaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=zpEblJ3z3c0OEtuNzktkKuxjjMU1yKtGwU8enmtyOkw&s=nNdwoitq7zPtB6SnDiG5nhTMR6auXZdN8sOG2xwGICw&e=>
>
> *Gyan Mishra*
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.verizon.com_&d=DwMDaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=zpEblJ3z3c0OEtuNzktkKuxjjMU1yKtGwU8enmtyOkw&s=nNdwoitq7zPtB6SnDiG5nhTMR6auXZdN8sOG2xwGICw&e=>
>
> *Gyan Mishra*
>
> Idr mailing [email-masked]://www.ietf.org/mailman/listinfo/idr <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwMDaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=zpEblJ3z3c0OEtuNzktkKuxjjMU1yKtGwU8enmtyOkw&s=vmp12DPUncS015OY67eHSJ77dpplP6_0iEmETUGbkqA&e=>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwICAg&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=zpEblJ3z3c0OEtuNzktkKuxjjMU1yKtGwU8enmtyOkw&s=vmp12DPUncS015OY67eHSJ77dpplP6_0iEmETUGbkqA&e=
>

---

From: Enke Chen <[email-masked]>
Date: Sat, 3 Jul 2021 15:59:09 -0700

Yes, it is a generic issue, although the cases involving BGP are more
visible in deployment.

In version -00.txt, we had:

   It is noted that the proposed algorithm is generally applicable when
   a route is redistributed from one protocol into another protocol.

It's dropped in order to focus.

Thanks.   -- Enke

On Sat, Jul 3, 2021 at 3:58 AM Robert Raszuk <[email-masked]> wrote:

>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.cisco.com_c_en_us_support_docs_ip_border-2Dgateway-2Dprotocol-2Dbgp_13753-2D25.html&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=UrndcBjaQEYEjbpe43Dmp1cU8kv7u3c3IZLQaEaw-Tg&s=FSUkTwE1UDrjBg7zRicOnco2ySnEj5RGfUjxz4OFM4s&e=>
>>
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.juniper.net_documentation_en-5FUS_junose15.1_topics_task_configuration_ip-2Droute-2Dadministrative-2Ddistance-2Dconfiguration.html&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=UrndcBjaQEYEjbpe43Dmp1cU8kv7u3c3IZLQaEaw-Tg&s=8HX97tuLeHDkgFkFORkNt9LjHy8sh3-Jso2oALUYMxk&e=>
>>>
>>>
>>>
>>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.cisco.com_c_en_us_support_docs_ip_border-2Dgateway-2Dprotocol-2Dbgp_15986-2Dadmin-2Ddistance.html&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=UrndcBjaQEYEjbpe43Dmp1cU8kv7u3c3IZLQaEaw-Tg&s=z_AO_qcHE1HnTkzoPsHLyvT83lPMbJjI7pawAcHu0sk&e=>
>>>
>>>
>>>
>>>
>>>
>>> *Route Source*
>>>
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=UrndcBjaQEYEjbpe43Dmp1cU8kv7u3c3IZLQaEaw-Tg&s=Weyjlq5go3AJVxvImrawxciSJUMHNXCaL7x-2WFhAgU&e=>
>>>
>>> --
>>>
>>>
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.verizon.com_&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=UrndcBjaQEYEjbpe43Dmp1cU8kv7u3c3IZLQaEaw-Tg&s=JlLCqgIHEWMnFhVgEh9uJTIn_5HepK_jtIN6vAvIXNA&e=>
>>>
>>> *Gyan Mishra*
>>>
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.verizon.com_&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=UrndcBjaQEYEjbpe43Dmp1cU8kv7u3c3IZLQaEaw-Tg&s=JlLCqgIHEWMnFhVgEh9uJTIn_5HepK_jtIN6vAvIXNA&e=>
>>>
>>> *Gyan Mishra*
>>>
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.verizon.com_&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=UrndcBjaQEYEjbpe43Dmp1cU8kv7u3c3IZLQaEaw-Tg&s=JlLCqgIHEWMnFhVgEh9uJTIn_5HepK_jtIN6vAvIXNA&e=>
>>>
>>> *Gyan Mishra*
>>>
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.verizon.com_&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=UrndcBjaQEYEjbpe43Dmp1cU8kv7u3c3IZLQaEaw-Tg&s=JlLCqgIHEWMnFhVgEh9uJTIn_5HepK_jtIN6vAvIXNA&e=>
>>>
>>> *Gyan Mishra*
>>>
>>> Idr mailing [email-masked]://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=UrndcBjaQEYEjbpe43Dmp1cU8kv7u3c3IZLQaEaw-Tg&s=Weyjlq5go3AJVxvImrawxciSJUMHNXCaL7x-2WFhAgU&e=>
>>>
>>> --
>>
>>
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.verizon.com_&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=UrndcBjaQEYEjbpe43Dmp1cU8kv7u3c3IZLQaEaw-Tg&s=JlLCqgIHEWMnFhVgEh9uJTIn_5HepK_jtIN6vAvIXNA&e=>
>>
>> *Gyan Mishra*
>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=UrndcBjaQEYEjbpe43Dmp1cU8kv7u3c3IZLQaEaw-Tg&s=Weyjlq5go3AJVxvImrawxciSJUMHNXCaL7x-2WFhAgU&e=>
>>
>

---

From: Alejandro Acosta <[email-masked]>
Date: Sat, 3 Jul 2021 20:52:53 -0400

Hello Enke,

   You are totally right, the prefix could have more than one ROA, 
perfectly valid. Easy and straight forward solution.

Alejandro,

On 3/7/21 6:42 PM, Enke Chen wrote:
> Hi, Alejandro:
>
> If I understand correctly, what you have described is a routing 
> scenario for a multi-homed customer involving multiple AS'es. It's 
> different from the one described in the draft.
>
> In your description, the prefix can be legitimately sourced by more 
> than one AS. Thus it should be registered with multiple AS origins.
>
> Thanks.   -- Enke
>
> On Sat, Jul 3, 2021 at 6:22 AM Alejandro Acosta 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hello,
>       As I said before I created a small lab with three routers, just
>     for testing purposes.
>     finding (well, maybe you are already aware but at I did not
>     catched it when reading the draft) that I believe is important.
>
>     In this scenario:
>
>     R1 -- R2 -- R3
>
>     R2 (AS65002) has a static floating (AD 150) route pointing to
>     10.0.0.1 toward R1.
>
>     R3 Learns 10.0.0.1 via R2 and the AS_Origin is set to 65001 (in
>     case there is a ROA, RPKI would be fine)
>
>     Suppose eBGP session resets between R1 & R2, static floating route
>     takes places.
>
>     Even when the eBGP session goes up RIB & BGP in R2 remains static
>     for 10.0.0.1
>
>>     I just tested it (using old Cisco gear) and the behavior was
>>     exactly the described in draft. Having said that I have to admit
>>     that at the beginning I was skeptical about this, but now I
>>     believe this draft deserve further discussions.
>>
>>
>>     Thanks,
>>
>>
>>     Alejandro,
>>
>>
>>
>>
>>>     Regards,
>>>
>>>     Jakob.
>>>
>>>     *From:* Idr <[email-masked]> <mailto:[email-masked]>
>>>     *On Behalf Of * Gyan Mishra
>>>     *To:* Robert Raszuk <[email-masked]> <mailto:[email-masked]>
>>>     *Cc:* idr@ietf. org <[email-masked]> <mailto:[email-masked]>; Jenny
>>>     Yuan <[email-masked]>
>>>     <mailto:[email-masked]>
>>>     From a network design POV, in general within a an IP transit AS
>>>     their is no need to redistribute BGP into IGP unless their are
>>>     non BGP speaking routers within the network.
>>>
>>>     As for sourcing routes into BGP advertisement from a customer
>>>     edge best practice is to originate the advertisement as close to
>>>     the source routers as possible, and if it’s a summary then use a
>>>     network statement and if LPM routes are required then
>>>     redistribution of IGP into BGP via policy is the best way but
>>>     also as close to the source of the prefixes.
>>>
>>>     connected or IGP into BGP global table still separate from
>>>     customer traffic in SP operator core where MPLS any-any VPN VRF
>>>     is used to carry Internet traffic and in that case the NOC may
>>>     sit in the Internet VRF and NMS systems need telemetry access
>>>     back to the global table.
>>>
>>>     Kind Regards
>>>
>>>     Gyan
>>>
>>>     On Thu, Jul 1, 2021 at 8:56 PM Gyan Mishra
>>>         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
>>>         prefer incomplete over IGP origin and that can be set via
>>>         policy as well so that both are equal so load balancing can
>>>         occur.
>>>
>>>         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
>>>
>>>         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
>>>
>>>         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
>>>                 Juniper which have use 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.
>>>
>>>                     implementations that I know of for example Cisco
>>>                     & Juniper which have use identical default 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.
>>>
>>>                     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
>>>                         things simpler, but that is not required.
>>>                         What matters is the local_pref value for 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 <[email-masked]
>>>                         <mailto:[email-masked]>> wrote:
>>>
>>>                             Hi Enke,
>>>
>>>                             How do you assure that admin distance is
>>>                             the same or delta would be the same
>>>                             across implementations ?
>>>
>>>                             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 <[email-masked]
>>>                                 version provides a complete solution
>>>                                 that covers the use cases involving
>>>                                 a single router as well as multiple
>>>                                 routers in a network.
>>>
>>>     https://www.ietf.org/mailman/listinfo/idr  <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwMDaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=zpEblJ3z3c0OEtuNzktkKuxjjMU1yKtGwU8enmtyOkw&s=vmp12DPUncS015OY67eHSJ77dpplP6_0iEmETUGbkqA&e=>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwICAg&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=zpEblJ3z3c0OEtuNzktkKuxjjMU1yKtGwU8enmtyOkw&s=vmp12DPUncS015OY67eHSJ77dpplP6_0iEmETUGbkqA&e=>
>
>

---

From: tom petch <[email-masked]>
Date: Mon, 5 Jul 2021 16:24:55 +0000

From: Jakob Heitz (jheitz) <[email-masked]>
Sent: 02 July 2021 21:25

<tp>
Almost.  It also appears in 
bgp-model
as adopted by this WG and so is closer to home, but then the I-D is expired which is how come I forgot it!

Tom Petch

Regards,
Jakob.

-----Original Message-----
From: tom petch <[email-masked]>
Sent: Friday, July 2, 2021 2:21 AM
To: Jakob Heitz (jheitz) <[email-masked]>; Gyan Mishra <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: idr@ietf. org <[email-masked]>; Jenny Yuan <[email-masked]>
Subject: Re: [Idr] draft-chen-bgp-redist-01.txt

<tp>

RFC8349
RFC8022
ospf-yang

Tom Petch

Regards,
Jakob.

Kind Regards

Gyan

Hi Enke

selection.

Kind Regards

Gyan

Juniper

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

Route Source
Default Distance Values
Connected interface
0
Static route
1

Cisco:

Juniper:

Thx,
R.

Hi Enke

Kind Regards

Gyan

Thanks.   -- Enke

Thx,
Robert

Thanks.   -- Enke

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347