how would draft-ymbk-opsawg-finding-geofeeds work in noam
randy at psg.com
Sat Sep 12 23:30: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.
> Then there is no more need to host HTTP server. 1 HTTP request per
> inetnum/inetnum6 object seems a bit tedious.
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?
> 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
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.
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?
note that use of the remarks: attribute is for rpsl services which do
not implement the specific geofeed: attribute. [ e.g. see the PR for
IIRDv4 https://github.com/irrdnet/irrd/issues/396 ]
> Specific to the north american RIR, NetHandle is in registry (not in
> irr) abd bulk access requires application
> download requires cookies and takes ~10 mins. imo this could be made
> easier like https://ftp.ripe.net/ripe/dbase/split/ripe.db.inetnum.gz
there are a lot of things arin could make life more easy for operators.
and cash could fall from the sky.
> NetHandle is not exactly inetnum (e.g. comments instead of remarks
> field, different prefix format). Would the RIR provide converted
> inetnum objects or the users would be expected to handle this?
i currently fear a custom stub to do just this for consumers of north
More information about the NANOG