Re: [Sidrops] WG-ADOPTION: draft-borchert-sidrops-rpki-state-unverified-01 - ENDS: 2019-03-12 (mar 12)

[Randy Bush <[e-mail]>]

> Examine the iBGP peer that you thought you configured to do origin
> validation and determine why it is unable to.

the path of debugging hooks runs far deeper into the mud.  to repeat;
you are stepping off a cliff here.

there are a number of reasons the match might not have been made: peer
not configured for validation, prefix in execption list, AS in exception
list, ...  will we next enumerate them all?  e.g. for debugging, i might
like to know which of my policies, or combination thereof, caused the
prefix not to be evaluated.  i am NOT suggesting we go down this rabbit
hole.

> We envisioned this being useful in scenarios such as: you have enabled
> BGP Origin Validation on a router that has lost all connections to its
> validating caches.

% show bgp rpki servers

> At the moment we can't tell administratively disabled from enabled,
> but failed in some manner.  We see some value in being able to
> diagnose that.

that is why we have cli-based (and yang etc) debugging tools.  you want
to know where in all your complex policy some decision was made, you
need to go through the policy, don't try to encode the cross-product of
all the posibilities in a result.

> Keep in mind, most of the FUD in this space comes from the fear that
> operators will not be able to diagnose why routes are/are not being
> filtered.  This theme came up a lot in the meeting before NANOG.

the game is over.  at&t has deployed and the multitude are hurrying to
join him.  and the flag-wavers are rushing to get in front and curry
publicity.

> Not the subject of this draft, but the concept of being able to tell
> if your iBGP peer actually performed validation will be even more
> useful in BGPSec, but that is for another draft.

and another century

randy