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

[Robert Raszuk <[e-mail]>]

Hi Jeff,

I think you have very well described and summarized both 4271 loose
language as well as local behaviour of Junos/GateD based BGP
implementations.

But my reading and some off-list discussions with Enke about this draft
rather indicate that the crux of the issue is how to *signal* the
preference across BGP speakers to be consistent with intended network wide
behaviour.

I am not able to find your opinion on such signalling (say in the form of
LOCAL PREF) or alternative options which would allow to work network wide.

Many thx,
R.





On Fri, Aug 20, 2021 at 9: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://www.juniper.net/documentation/en_US/junos/topics/reference/general/routing-protocols-address-representation.html
>
> 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
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>