Mon, Apr 26, 2021 at 01:16:55AM +0200, Rayhaan Jaufeerally (IETF): > > 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?
IMO, if you wish to formalize/define the "output" in rfc8522, do so. let the LG API (via http/whatever) retrieve information from the devices via net/restconf. I do not support adding such an interface to routers or dispersing LG locations in BGP. Place LG info in peeringdb.com & peeringdb's api. _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow