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

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
(https://www.afrinic.net/press/214-creating-customer-assignments),
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
objects.

>
> > 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
>    reference.
>
> is there more specific wording that would help clarify?
see above

Yang