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 today).
Agree. 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 conventions?
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 shops). 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- aggregates. Mark.