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

[Alejandro Acosta <[e-mail]>]

On 2/7/21 2:33 AM, Jakob Heitz (jheitz) wrote:
>
> Admin-distance is not defined in any RFCs. It is a vendor only concept.
>
> I can speak about it from the Cisco IOS-XR and Redback perspective.
>
> In both of these implementations, RIB and BGP are separate processes
>
> with separate memory spaces and their own routing tables.
>
> Routes are passed between them using inter-process communication messages.
>
> They cannot access each other's routing tables. Other routing protoclos,
>
> such as OSPF, ISIS and static are also separate processes. Each of the 
> routing
>
> protocols downloads their valid routes to RIB. If the same IP prefix is
>
> sent to RIB by multiple routing protocols, RIB will select one to be used
>
> for forwarding and resolving nexthops. RIB uses admin-distance to decide.
>
> Routing protocols get their local routes from RIB.
>
> A static route has admin-distance of 1 by default.
>
> However, a static route can be configured with a different admin-distance.
>
> It is possible to configure a backup static route by configuring a high
>
> admin-distance for it.
>
> In that case, if another route is found for the given prefix by another
>
> routing protocol, say an ISIS route, then the ISIS route will be used
>
> for forwarding. Only if the ISIS route disappears will the backup static
>
> route be used.
>
> Now, suppose we want to advertise that prefix in BGP. We can do that
>
> with a "redistribute" statement or with a "network" statement.
>
> They work a little bit differently, but either command will import
>
> the route from the RIB into BGP.
>
> Once the route is in BGP, it loses its admin-distance.
>
> BGP has no knowledge of the admin-distance that this route had in RIB.
>
> There is no admin-distance in section 9.1 of RFC 4271.
>
> This is the root of the problem that Enke and Jenny are trying to solve.
>
> The problem occurs if the same prefix can be learnt by BGP from
>
> a BGP peer. BGP may download it into RIB. The draft addresses the
>
> different outcome if BGP learns the route first from it peer or learns
>
> it first from the local RIB.
>

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,




> Regards,
>
> Jakob.
>
> *From:* Idr <[e-mail]> *On Behalf Of * Gyan Mishra
> *Sent:* Thursday, July 1, 2021 6:18 PM
> *To:* Robert Raszuk <[e-mail]>
> *Cc:* idr@ietf. org <[e-mail]>; Jenny Yuan 
> <[e-mail]>
> *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 <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     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]
>     <mailto:[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
>         <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
>         <https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/15986-admin-distance.html>
>
>         *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
>         <[e-mail] <mailto:[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:
>
>             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
>             <[e-mail] <mailto:[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]
>                 <mailto:[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] <mailto:[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]
>                         <mailto:[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] <mailto:[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] <mailto:[e-mail]>
>                     https://www.ietf.org/mailman/listinfo/idr
>                     <https://www.ietf.org/mailman/listinfo/idr>
>
>                 -- 
>
>                 <http://www.verizon.com/>
>
>                 *Gyan Mishra*
>
>                 /Network Solutions Architect /
>
>                 /Email [e-mail]
>                 <mailto:[e-mail]>/
>
>                 /M 301 502-1347/
>
>         -- 
>
>         <http://www.verizon.com/>
>
>         *Gyan Mishra*
>
>         /Network Solutions Architect /
>
>         /Email [e-mail]
>         <mailto:[e-mail]>/
>
>         /M 301 502-1347/
>
>     -- 
>
>     <http://www.verizon.com/>
>
>     *Gyan Mishra*
>
>     /Network Solutions Architect /
>
>     /Email [e-mail] <mailto:[e-mail]>/
>
>     /M 301 502-1347/
>
> -- 
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> /Network Solutions Architect /
>
> /Email [e-mail] <mailto:[e-mail]>/
>
> /M 301 502-1347/
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr