BGPMON Alert Questions
mark.tinka at seacom.mu
Thu Apr 10 13:26:50 UTC 2014
On Thursday, April 10, 2014 12:30:51 PM Randy Bush wrote:
> as folk start to roll out rejection of invalids, we might
> think about how we report problems with folk registering
> inadequate roas, covering their customers, covering
> their deaggs (maybe deaggs get what they deserve), etc.
> if they are not clued enough to generate prudent roas,
> they will not be clued enough to generate ghostbusters
> (and neither ripe's nor apnic's software supports gbrs
If you are clued enough to generate ROA's, you are clued
enough to generate ROA's for the de-aggregates (or, at
least, respond to the errors that indicate that). But the
reverse is also true.
It would be useful to use BGPmon's free RPKI validation
feature, which e-mails you, incessantly, about validation
failures due to un-ROA'd de-aggregates.
It will also help if the CA's run by the RIR's support
prefix length definitions. For the Africa region, AFRINIC
currently do not, meaning every de-aggregate needs to be
ROA'd. It's planned, though...
> if my customer can not reach foo's customer, will foo's
> rir be willing to help? if foo's customer can not reach
> mine, how to let foo know who to call/write? do we need
This was one of the questions I've always pondered, and if
you recall, was part of our panel discussion on the subject
in Xi'an last year.
I think it would be helpful if CA delegation was supported
by RIR's, and supported well, so that customers can deal
with their ISP's CA instead of having to deal with the RIR
instead (particularly for situations where RIR's aren't 24/7
On the monitoring side, it will be critical for ISP's to
provide looking glasses that customers can use to verify the
delta between what has been ROA'd and what has been
announced/rejected, particularly in the case of un-ROA'd de-
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: This is a digitally signed message part.
More information about the NANOG