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

["Montgomery, Douglas (Fed)" <[e-mail]>]

Which of your N hundred routers will you login to, to do the "show bgp rpki servers"?

We thought the one sending you "unverified" state would be a good clue.

No one was asking for the cross product of any other info ... so I don't really buy the slippery slope logic.

I hope you are right about everyone rushing to join the parade.  

I still see as many folks express concerns about debugging as wave flags.

dougm
-- 
DougM at NIST
 

On 2/27/19, 6:48 PM, "Randy Bush" <[e-mail]> wrote:

    > 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