[170841] in North American Network Operators' Group
Re: BGPMON Alert Questions
daemon@ATHENA.MIT.EDU (Mark Tinka)
Thu Apr 10 09:27:34 2014
From: Mark Tinka <mark.tinka@seacom.mu>
To: Randy Bush <randy@psg.com>
Date: Thu, 10 Apr 2014 15:26:50 +0200
In-Reply-To: <m2wqexh3xg.wl%randy@psg.com>
Cc: North American Network Operators' Group <nanog@nanog.org>
Reply-To: mark.tinka@seacom.mu
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--nextPart99800010.Fjfr0LligU
Content-Type: Text/Plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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.=20
> 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=20
enough to generate ROA's for the de-aggregates (or, at=20
least, respond to the errors that indicate that). But the=20
reverse is also true.
It would be useful to use BGPmon's free RPKI validation=20
feature, which e-mails you, incessantly, about validation=20
failures due to un-ROA'd de-aggregates.
It will also help if the CA's run by the RIR's support=20
prefix length definitions. For the Africa region, AFRINIC=20
currently do not, meaning every de-aggregate needs to be=20
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=20
you recall, was part of our panel discussion on the subject=20
in Xi'an last year.
I think it would be helpful if CA delegation was supported=20
by RIR's, and supported well, so that customers can deal=20
with their ISP's CA instead of having to deal with the RIR=20
instead (particularly for situations where RIR's aren't 24/7=20
shops).
On the monitoring side, it will be critical for ISP's to=20
provide looking glasses that customers can use to verify the=20
delta between what has been ROA'd and what has been=20
announced/rejected, particularly in the case of un-ROA'd de-
aggregates.
Mark.
--nextPart99800010.Fjfr0LligU
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
iQIcBAABAgAGBQJTRpwdAAoJEGcZuYTeKm+GqPIQAJDwLyVUvR2YFslvde5KRb0M
glB2y40w3qUSRPK8EohFZ3zfPL5Y+IICJ2RV1eZIj51GnrS+aGulUVNO52NhWdPZ
4iR9gjdQddC/E3KUNnAv0fXApXMbtmZ21MDDAd1WkmLMoXrZquh0U06nNWFHSy5P
Jf/8a64+c6BlgS1bdHcwvgaAZ7Bx7awH76zH+e9rLILL0av66AcfCx/bCZ05BN6F
7lnmz8NukjkILiWy8+gKksV5ynTNLbV87OBSiTYVKEX88yCPTQyCbiJmHnBo8Vj4
EjflWmhWPrGgiztX+FgMPoVkZLEkQ1gHuQI5OA+mtQi57wCaQo9fUCZdl/v/eawL
aI75TIkBQv6S9Y3BdxZnSldfGeK28uoSd66dbAj3ktucj0cr2R4e8ZKaQGxYMV+5
u1i6GwZIp58S1cfzpU2y6u6FwgUw944gY2dq5uyNsx3VvJcetGBZgFnzaf5pHCF8
35Rj12BtV5u/nOUo7sHRMFS2ETXF8/VqqKQtIu4VqI+qm4TGmUmZXBIV+WUrZ8ym
N5mLpgcUBkvnwqZe5k4U6c772fXuhqdhyw1WYFkwqV+qWcdA9xr8tkmVKb2UffXW
uB7PxsBSNOsr8fvls3dbXGM5olojCNdmBhAlEwk3IofQQRovXhmcCmTipfvePxGb
Cuc19TSQjp7Z2mspr3H5
=8PeN
-----END PGP SIGNATURE-----
--nextPart99800010.Fjfr0LligU--
