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

Reply via email to