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

[Jeffrey Haas <[e-mail]>]

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