On Tue, Dec 18, 2012 at 4:24 PM, Dongting Yu <dongting...@cl.cam.ac.uk> wrote:
> [apologies if I am sending this multiple times, having trouble with replying]
>
> A concept that could be borrowed from DNS side is the ability for
> anyone to go from the top and skip the cache(s) on an ad hoc basis.

stop... no.

The architecture as laid out is, from 'roa creator' to 'roa consumer', roughly:
  A publication point (nominally one per roa-creator)
  B gatherers (nominally one per roa-consumer)
  C internal-cache-systems (some number per roa-consumer)
  D routers

(yes, there is the iana->rir part of the tree
 yes, there are are more than just ROAs in the repositories)

So, the part that Randy and Danny and Eric are talking about is, as
far as the global system, is the A -> B conversation. Once you get
beyond B (to C and D) the problem is entirely inside some operator's
network and nothing on the outside matters.

Essentially the problem here is distribution of 10k of data to ~40k
endpoints (today, it'll grow tomorrow, fine) in ~2 mins time (or 5
mins or 10 mins or ... someone draw a line in the sand so we know what
the target is)

> Perhaps we need a similar capability here, for anyone to query from
> the top. This way, a new announcement can (for example) carry a flag
> that says "this may look invalid but if you skip the cache you will
> see that it is", and suggests the receiving party to validate it from
> the top.

at the router? no, don't do that.

>
> Of course, two things will soon follow: some will always ask others to
> skip the cache, which would defeat the purpose of caching (but I would

once you have QOS, everything is EF!

> argue that it is not hard to figure out who are wasting others'
> bandwidth and cpu, by comparing the non-cached versions as requested
> and the cached versions), and this mechanism itself can be used to
> launch a DDoS (to which I would argue the RIRs already has enough
> resources to handle it, or some tricks can be perhaps applied to make

do they?

> this problem less significant in the first place).
>
> Dongting
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Reply via email to