how would draft-ymbk-opsawg-finding-geofeeds work in noam

Yang Yu yang.yu.list at
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 (
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: # example
>        remarks: Geofeed
>    Any particular inetnum: object MAY have, at most, one geofeed
>    reference.
> is there more specific wording that would help clarify?
see above


More information about the NANOG mailing list