how would draft-ymbk-opsawg-finding-geofeeds work in noam
yang.yu.list at gmail.com
Sun Sep 13 04:52:23 UTC 2020
> > Why not publish RFC8805 Geofeed directly in inetnum remarks section?
> for some flat fan out last kilometer providers that could be the
> inetnum: object from hell. there are global providers which segment
> large prefixes over diverse areas. etc.
> i doubt the rpsl providers would like multi-megabyte inetnum:s. rpsl
> providers already throttle in defense.
I was thinking about geofeed on customer assignment objects for
networks that manage their own objects
only 1 line of geofeed remark needed on each object (more objects
should be created if used in different locations).
But not all RIR have customer assignment objects (can't create
sub-assignment objects on ARIN direct assignment resources). HTTP feed
does make sense when customer assignment object is not an option.
> 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, maybe some clients can just
read input like RPKI VRP (https://rpki.cloudflare.com/rpki.json)
Client can try to keep track of geofeed URLs and only download the
file during iteration, despite the same file referenced by multiple
> > How to handle other stuff that might exist in remarks field? Or the
> > draft would explicitly require Geofeed to be in its own remarks field?
> the document tries to be explicit that it is the latter. that is the
> intent of
> 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
> inetnum: 192.0.2.0/24 # example
> remarks: Geofeed https://example.com/geofeed.csv
> Any particular inetnum: object MAY have, at most, one geofeed
> is there more specific wording that would help clarify?
More information about the NANOG