how would draft-ymbk-opsawg-finding-geofeeds work in noam
randy at psg.com
Mon Sep 14 03:08:26 UTC 2020
>> we are not expecting these lookups to be done frequently. i agree that
>> would hammer servers, both rpsl and geofeed. do you have stronger words
>> to suggest than
>> 5. Operational Considerations
>> An entity fetching geofeed data through these mechanisms MUST NOT do
>> frequent real-time look-ups to prevent load on RPSL servers. And do
>> not fetch at midnight, because everyone else may.
>> i agree that we do not want the DDoS that is currently happening to RPKI
>> publication servers. perhaps explicit time limits, e.g daily?
> I am more concerned about clients having to make large amount of HTTP
> requests if this field gets widely used
i have a, possibly mistaken, model that the fetchers are few, content
and similar providers such as netflix, news and sports media, ... and
there are not many, maybe O(1,000). and they make a pass once a week
or less frequently, as the data do not change much and their pushing
data out to their infrastructure is not frequent.
given O(10^5) inetnum:s with geofeed refs, and a sweep rate of once a
week or less, that seems pretty trivial. the rpsl server damping could
>> 3. inetnum: Class
>> the syntax of a Geofeed remarks: attribute which contains a URL of a
>> geofeed file. The format MUST be as in this example, "remarks:
>> Geofeed " followed by a URL which will vary.
> ---> probably add clarification here that Geofeed MUST be the only
> value in this particular remarks field, nothing before/after it
between the MUST and the example, i do not see the wiggle room you
More information about the NANOG