Level 3's IRR Database

Mon Jan 31 19:42:35 UTC 2011

	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:

> 
> On 31 Jan 2011, at 19:40, Dongting Yu wrote:
> 
>> On Mon, Jan 31, 2011 at 6:17 PM, Andree Toonk <andree+nanog at toonk.nl> wrote:
>>> 
>>> Now AS17557 start to announce a more specific: 208.65.153.0/24. Validators
>>> would classify this as Invalid (2).
>> 
>> 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?
> 
> No, it would classify as invalid because as Randy said earlier in the thread:
> 
>  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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> -Alex