[136003] in North American Network Operators' Group
Re: Level 3's IRR Database
daemon@ATHENA.MIT.EDU (Arturo Servin)
Mon Jan 31 14:43:25 2011
From: Arturo Servin <arturo.servin@gmail.com>
Date: Mon, 31 Jan 2011 14:42:35 -0500
In-Reply-To: <A3FBFB4F-457E-40B5-86B6-DD300B829385@ripe.net>
To: "nanog@nanog.org list" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
I think the issue is not between valid vs invalid, but that =
using route-maps and local preference a "more specific not valid" route =
would be used over another "less specific valid" because of the routing =
decision process, right?
Perhaps this would help?
http://www.ietf.org/mail-archive/web/sidr/current/msg02117.html
So, it is my understanding that yes, with local pref the Google =
vs Pakistan Telecom wouldn't have been avoided, however Google would =
"only need" to generate more specific routes to beat the unauthorised =
announce and "fix" the issue.
Right?
.as
On 31 Jan 2011, at 14:20, Alex Band wrote:
>=20
> On 31 Jan 2011, at 19:40, Dongting Yu wrote:
>=20
>> On Mon, Jan 31, 2011 at 6:17 PM, Andree Toonk <andree+nanog@toonk.nl> =
wrote:
>>>=20
>>> Now AS17557 start to announce a more specific: 208.65.153.0/24. =
Validators
>>> would classify this as Invalid (2).
>>=20
>> Would it be classified as invalid or unknown? Or are both possible
>> depending on whether 208.65.153.0/24 is signed? Do these two cases
>> differ in this particular case?
>=20
> No, it would classify as invalid because as Randy said earlier in the =
thread:
>=20
> Before issuing a ROA for a block, an operator MUST ensure that any
> sub-allocations from that block which are announced by others (e.g.
> customers) have ROAs in play. Otherwise, issuing a ROA for the
> super-block will cause the announcements of sub-allocations with no
> ROAs to be Invalid.
>=20
> In a ROA you can specify a maximum length, authorising the AS to =
deaggregate the prefix to the point you specify. If no max length is =
specified, the AS is only allowed to announce the prefix as indicated.
>=20
> So if the ROA for AS36561 with prefix 208.65.152.0/22 was created with =
no 'max length' specified, the /24 that AS17557 announces would be =
invalid because it's the wrong prefix length *and* because it's the =
wrong origin AS. If a max length of /24 was specified in the ROA, it =
would be invalid only because of the latter.
>=20
> There could be another ROA for 208.65.153.0/24 specifically, but =
obviously not for AS17557, so again invalid because of the wrong origin =
AS. Pakistan Telecom also can't create a valid ROA, because they are not =
the holder of the address space.
>=20
> -Alex
