Thanks Nick, Paolo and Heasley for your insights, > Consistent API that serves RIB data
Initially I tried to avoid defining the exact API of the looking glass by pointing to https://tools.ietf.org/html/rfc8522, but unfortunately it does not strictly define the response format instead leaving it up to the implementation what to return to queries, which IMO is not very useful for automation. As y'all have pointed out there is a wealth of implementations out there that have tried to address this (and adding some others I've found): - Paolo's pmacct looking glass document: https://github.com/pmacct/pmacct/blob/master/docs/LOOKING_GLASS_FORMAT, - Birdseye https://github.com/inex/birdseye - CAIDA looking glass API https://www.caida.org/tools/utilities/looking-glass-api/ - DE-CIX: https://www.de-cix.net/en/resources/looking-glass (which is using https://github.com/alice-lg/alice-lg) - RIPEStat's API, e.g. https://stat.ripe.net/data/looking-glass/data.json?preferred_version=2.1&resource=2a0d:d740::/48 There's certainly value in going in and actually defining the data interchange format, but maybe that's worth doing in a different document to the propagation of the LG URL itself? > Implementation concerns re access, security, load etc I think whatever we come up with should take these concerns into consideration but not constrain the operator, as, if at the end of the day they'd like to restrict who can query the API that's a totally fine use case, I can imagine maybe at an internet exchange the API is only available on the peering LAN to members for instance. As Paolo mentioned there is a problem to solve between the router or data source and the LG frontend, I'm not sure what form that would take but I would propose having that separate from the document describing how to propagate the LG URL in BGP and the interface of the LG to external users, since these two things can be implemented independently of each other, is that reasonable? Cheers, Rayhaan On Sun, Apr 25, 2021 at 6:08 PM heasley <h...@shrubbery.net> wrote: > Sun, Apr 25, 2021 at 03:07:29PM +0100, Nick Hilliard: > > what we need from routers is a consistent API endpoint which serves RIB > > data, that can be consumed by client apps. > > isnt that called net/restconf? >
_______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
