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

[Jeffrey Haas <[e-mail]>]

Enke,

On Fri, Aug 20, 2021 at 02:27:40PM -0700, Enke Chen wrote:
> 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.

In terms of route selection, the behavior remains consistent.  If you've set
your route's preference to be better from BGP rather than than from your
static route (your section 2.2), the better preference will win.

However, I think what you're actually asking is implied in your draft but
perhaps in need of some additional text: You want admin distance to have
domain-wide meaning.

I find this problematic.

My two high order concerns with the solution space discussed in the draft are:

1. Section 3.3, consistent admin distance across the deployment.  (At least
   on a per-prefix basis.)  
2. LOCAL_PREF is the best way to de-pref some classes of backup route.

The values various implementations use for their admin-distance style
behavior are DEEPLY embedded in the software.  While those implementations
usually give some level of room to adjust the values in question, doing so
in a multi-vendor fashion is likely to be challenging at best.  Given such
challenges, it's almost an argument that there should be a separate value
used for this tuning that is vendor-neutral.  I don't think this is likely
to be a good answer.  Let's come back to this point in a moment.

In current BGP route selection, LOCAL_PREF is a very heavy hammer to use on
route preferencing.  For all practical purposes, the minute one of your
contributing routes has a worse local preference than other otherwise
comparable routes, it's out of the game.  If this is your intent, as I think
your draft scenarios are largely tailored for, this works fine.  But I
suspect you'll find most operators usually have 2, maybe 3 values of
LOCAL_PREF they want to use because of this property.

In situations where you may want individual routers to make specific choices
for de-preferencing a route, that decision may be local.  Even so, that
local decision's result may want to be otherwise comparable for the rest of
the deployment.  

I think your answer to this point is, "No adjustment to local-preference is
necessary".  But if that local decision is made based on some form of
admin-distance and the procedures you're proposing are in place, you now
have exception cases to write code or policy for.

Where these two things lead us is what I think your not-quite-stated desire
is in this draft: You want a level of total-ordering of route selection
across the deployment, and you want admin-distance to be one of your inputs
to that.

This is doable with LOCAL_PREF, so I agree with that observation from your
proposal.

This should theoretically be implementable with nothing more than policy.
And this is the kind of thing that operators do on a regular basis.

In the implementations you discuss in your draft, the lack of local
determinism in the redistribution mechanisms is giving you an interesting
headache.  Figuring out a useful remediation for that is worth doing.  In my
opinion, it'd be better to fix the issue of local determinism without
forcing that into the local-pref - but I realize that changing existing
implementations with other non-obvious consequences is challenging at best.

-----

If you accept the above discussion, what do I think you should do about my
comments?

- Update the draft to focus a bit more on discussion of total ordering of
  routes across a deployment.  
  + Reach out to the grow WG, NANOG, etc. for their comment on this goal and
    how this intersects with their own operational practices.
- Update your procedures such that you discuss the end-goal of achieving a
  set of ordered LOCAL_PREF that matches the intent of the total-ordering
  for the different classes of routes by your metric-of-intent.
  (admin-distance, as an example).
  + Discuss how this mapping operation may or may not be able to be
    accomplished.  In some cases, math on a metric may work, but in a
    multi-vendor environment a local mapping operation may be auto-magic or
    potentially hand-coded policy may be best.
- Make the draft informational status.
  + Depending on how discussion proceeds, this is perhaps a better fit for
    grow than idr?

Interesting optional discussion: Do we finally tighten up our RFC 4271
language to discuss what redistribution actually looks like?  We end up in
interesting situations from this ambiguity every few years or so.

-- Jeff