WG Chair hat _OFF_
On 07/10/2008, at 5:48 PM, Brian Dickson wrote:
Randy Bush wrote:
Geoff:
and this case, although not common, has been visible in the routing
table already
Randy:
oh? and how do you detect it? how many are there? how much of a
real
problem is it?
so i had a three hour drive from seeing kids in portland to the
exciting
westin colo in seattle. i did not even make it through the neil
young
on my ipod. but i kept thinking of how one could test or demonstrate
your assertion. perhaps neil scrambled my thinking, but it did not
even
get to winterlude.
for each prefix in some routing table, rv, dump of one of my routers,
whatever, see if that prefix can be decomposed into two or more
prefixes
which one can demonstrate are 'given' to the announcing asn by two or
more different would-be certificate authoritiess, e.g. rirs or
disparate
delegatees of rirs.
i could not really see how to do this for other than the case where
the
prefix can be shown to be in the delegation registries of two rirs.
please give us one example which supports your assertion, or whack me
with a clue by four about how one could better test/demonstrate your
assertion.
Let me ask Geoff about the specific kinds of scenarios, to simplify
things a bit. (I'm curious, too.)
Would the visible examples be adjacent prefixes (suitable for
aggregation) originated by one specific ASN?
yes
Or, would the visible examples be adjacent prefixes from two ASNs,
being
*proxy* aggregated by a third ASN?
yes - I had a quick scan through the routing table this afternoon and
saw two
potential instances of this.
Or some other variation involving one or two ASNs?
I do not believe
Try as I might, I am unable to figure out any way to split a block
more
than one way.
And for two blocks to be able to be aggregated (without covering other
prefixes, i.e. not a proxy aggregate for any third parties), they have
to be adjacent.
Which means the two entities giving those blocks, would have to give
the
*whole* block (in both cases) to the recipient, with nothing left over
for the giver or the giver's other customers.
A=CIDR(x/n) -> B=CIDR(x/n+1) + C=CIDR(x+foo/n+1)
RIR split A, gives B to Bob and C to Carol. Bob gives B to Dave, and
Carol gives C to Dave. Dave can now join B+C to get A again.
Nothing else works, unless B is passed down through Eric, Franz, and
Greg, and C is passed down through Harriet, Ian, and James. In each
case, without taking anything from B or C.
Is this known to have happened, and is it visible in the routing
table??
If you have a detailed look at the RIR's stats files you find that the
older address space is somewhat fragmented across RIRs. If you also
try and take into account a certain amount if NIR fragmentation what
you have is the basic set of prefixes and their associated
certification path.
Now construct this table of allocations for every day for the past,
say year.
Then pull the set of all BGP updates for the same period (route views
is a decent source of all such updates over the past year)
Now look up each updated prefix in the relevant daily table and see if
the prefix fits within a single allocation space.
Report anomalies.
There may be more efficient approaches.
Geoff
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
