Re: [Idr] draft-chen-bgp-redist - A Juniper Perspective

[Enke Chen <[e-mail]>]

Hi, Jeff:

Thanks for the pointer to JUNOS's BGP path selection. It's great that the
Gated/JUNOS already has some consideration of the "admin-distance" /
"preference" in BGP. That should take care of the case described in Sect.
2.1 ("On a single router").  It's not clear to me, though, whether and how
the cases described in Sec. 2.2 ("Network-wide behavior") are handled.

This is just a quick comment. I am still trying to digest your email.

-- Enke


On Fri, Aug 20, 2021 at 12:22 PM Jeffrey Haas <[e-mail]> wrote:

> Enke & Jenny,
>
> While I'm inclined to say that the matters described in
> draft-chen-bgp-redist aren't a problem, it's probably more reasonable to
> say
> "this isn't a problem for everyone".
>
> I'm not going to debate what other implementations do.  Instead, I'll spend
> the much of my message discussing what the implementation I work on does.
> This does leave us in an interesting headache as a working group whether
> there's more general work to do here that merits discussion as an RFC.
>
> ----
>
> One thing I will contribute toward some possible need for discussion is the
> sloppy ground that RFC 4271 had with regards to interactions with non-BGP
> protocols.  We had quite a difficult time getting the text for this "right"
> and there was multiple pushes to try to NOT discuss non-BGP protocols at
> all.  Such discussions got very deep in the internal details of various
> implementations.  What we did end up with in RFC 4271 was the following:
>
> The BGP RIBs are a distinct entity from the "Routing Table".
>
> Section 9.1.2 places the best BGP route in the Loc-RIB.
> It also says, "Whether the new BGP route replaces an existing non-BGP route
> in the Routing Table depends on the policy configured on the BGP speaker."
>
> Section 9.1.3 for Route Dissemination then says the following:
>  :    The Phase 3 decision function is invoked on completion of Phase 2, or
>  :    when any of the following events occur:
>  : [...]
>  :       b) when locally generated routes learned by means outside of BGP
>  :          have changed
>  : [...]
>  :
>  :    All routes in the Loc-RIB are processed into Adj-RIBs-Out according
>  :    to configured policy.
>
> So... there's not a lot of normative text there.  The last sentence above,
> "configured policy", is the wiggle room the RFC has to say "I'm originating
> a route".
>
> The general call in the RFC to not advertise things you can't forward to
> also provides some level of wiggle room that the best route in the Routing
> Table is what should be redistributed:
>  :    A route SHALL NOT
>  :    be installed in the Adj-Rib-Out unless the destination, and NEXT_HOP
>  :    described by this route, may be forwarded appropriately by the
>  :    Routing Table.
>
> Anyway, the text is sloppy and discussions about how redistribution is done
> and whether that is shown in the Loc-Rib view or as an override to the
> rib-out manifests in discussions in things like BMP or the Yang modules.
> It's still not as cleanly settled as it should be.
>
> Offering my opinion on this abstract model, I've tended to think about a
> better route in the Routing Table (e.g. a static route with a better admin
> distance/preference) as being selected into the Loc-Rib by considering it a
> route injected via a virtual Adj-Rib-In.  But that's just my personal
> justification.
>
> ----
>
> Juniper's implementation roughly works like the following.  Since it's
> derived from GateD heritage, many similar implementations will behave in a
> similar fashion.
>
> In a single routing table, there is a total ordering on all contributors to
> a given destination.
>
> The highest level of ordering is "preference", which roughly corresponds to
> admin-distance.
>
> When routes are BGP routes, the BGP routes are ordered based largely on
> standard RFC rules.  The deviations from those rules are the usual vendor
> deviations from standards based on when the later standards were published,
> and the mix of features the operator wants.  Examples of deviations are
> whether RFC 5004 is used for temporal vs. router-id based deterministic
> tie-breaking.
>
> BGP routes vs. non-BGP routes are not directly comparable, even when they
> have the same preference, but we have criteria that permits them to be
> selected deterministically.
>
> For non-BGP routes vs. non-BGP routes of two different protocols, we
> similarly will select things deterministically, but may be willing to use
> particular properties of the routes that may be comparable; e.g. metric.
>
> Much of this process is documented here:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.juniper.net_documentation_en-5FUS_junos_topics_reference_general_routing-2Dprotocols-2Daddress-2Drepresentation.html&d=DwIBAg&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=-dwyFCMbZS-tuTtu3oL1HNFBH-2mpqRlUm9F7wDkv6g&s=R7AEen-1wMEbbOC4rK4EjfOnMRVPTfQpMnYKMWKGmAA&e=
>
> For the described scenarios in draft-chen-bgp-redist, JUNOS doesn't have
> determinism issues.
>
> In our more recent multi-threaded BGP mode, we at one point in the design
> had an issue somewhat related to the one described in the draft.  In our
> implementation, we address the issue by always making the Routing Table and
> the BGP thread always exchange the best route in the local total-ordering.
>
> -- Jeff
>