Re: [GROW] BGP Looking Glass Capability
Rayhaan wanted to know if the peer accepted his route. A looking glass is a different thing in many ways. Several years ago Ignas pointed out that you can use this information to know whether to install a backup on your side for the route. Backup routes in the forwarding hardware are expensive, so it would be good to know if your peer is using your route before installing a backup for it. BGP has a peer-to-peer only signaling mechanism: ORF. Can we invent an ORF for it? Rayhaan, please let me know if I'm on or off track for your use case. Regards, Jakob. -Original Message- From: GROW On Behalf Of heasley Sent: Monday, April 26, 2021 4:23 PM To: Christopher Morrow Cc: grow@ietf.org grow@ietf.org Subject: Re: [GROW] BGP Looking Glass Capability Mon, Apr 26, 2021 at 06:25:44PM -0400, Christopher Morrow: > (as normal netizen) > > On Mon, Apr 26, 2021 at 3:33 PM Randy Bush wrote: > > > > Place LG info in peeringdb.com & peeringdb's api. > > > > +1 > > > > huh,I had thought this was already actually included in peeringdb? > >Looking Glass URL http://route-server.ip.att.net > afict, its just a string, which does not provide a standard way to represent location/geo. i presume from earlier comments, that something more structured is desired. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] BGP Looking Glass Capability
Mon, Apr 26, 2021 at 06:25:44PM -0400, Christopher Morrow: > (as normal netizen) > > On Mon, Apr 26, 2021 at 3:33 PM Randy Bush wrote: > > > > Place LG info in peeringdb.com & peeringdb's api. > > > > +1 > > > > huh,I had thought this was already actually included in peeringdb? > >Looking Glass URL http://route-server.ip.att.net > afict, its just a string, which does not provide a standard way to represent location/geo. i presume from earlier comments, that something more structured is desired. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] BGP Looking Glass Capability
(as normal netizen) On Mon, Apr 26, 2021 at 3:33 PM Randy Bush wrote: > > Place LG info in peeringdb.com & peeringdb's api. > > +1 > huh,I had thought this was already actually included in peeringdb? Looking Glass URL http://route-server.ip.att.net ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] BGP Looking Glass Capability
> I do not support adding such an interface to routers or dispersing LG > locations in BGP. maybe dns? rpki? x.400? :) > Place LG info in peeringdb.com & peeringdb's api. +1 randy --- ra...@psg.com `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` signatures are back, thanks to dmarc header butchery ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] BGP Looking Glass Capability
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=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
Re: [GROW] BGP Looking Glass Capability
Yes I mentioned this case in one of the subsequent emails - LG can be per region etc ... You just register not one by many such looking glass server addresses. Some may be independent .. some may be a pool of servers under same IP. Thx On Mon, Apr 26, 2021 at 5:59 AM Alejandro Acosta < alejandroacostaal...@gmail.com> wrote: > Hello, I guess you have already mentioned this, however I have not found > it yet. Please consider many AS have many different views. That's it. > > Alejandro, > > On Sun, Apr 25, 2021, 8:03 AM Robert Raszuk wrote: > >> >> > for example: 23456.lookingglass for AS 23456. >> >> >> I was just about to propose to define a notion of well known URL for >> looking glass. >> >> >> Let's grab bgp.io domain (it seems available) and allow each domain to >> submit their IP to well known name mapping. In fact looking glasses may be >> just one of many such well known tools to help with operational aspects of >> the Internet. >> >> >> In such cases no signalling would be necessary at all and you can always >> go to 23456.lookingglass.bgp.io with an obvious alias (23456.lg.bgp.io) >> to see if your routes made it via peer's policy/best path etc ... In case >> ASN has more then one LG in each region same thing ... you define a few >> such addresses to indicate each server or LG server pool. >> >> >> Thx, >> R. >> >> >> PS. However if we want to down the BGP inline signalling for this I >> recommend we take a look at: >> https://tools.ietf.org/html/draft-ietf-idr-operational-message-00 Seems >> to me like defining new TLV there would be very good fit for what is being >> proposed here. >> >> >> >> On Sun, Apr 25, 2021 at 7:55 AM Jakob Heitz (jheitz) > 40cisco@dmarc.ietf.org> wrote: >> >>> This is a great thing to do, but I would not use a BGP capability to do >>> it. >>> >>> The capability is signaled only in the BGP OPEN message, at the start of >>> the session. >>> >>> Changes cannot be signaled without bouncing the session. >>> >>> The BGP capability is only exchanged with neighbors. >>> >>> Perhaps we could do it with a new address family or >>> >>> standardize the form of the URL, say invent a new top level domain: >>> .lookingglass >>> >>> and then the URL could be the ASN followed by the TLD, for example: >>> >>> 23456.lookingglass for AS 23456. >>> >>> >>> >>> Regards, >>> >>> Jakob. >>> >>> >>> >>> *From:* GROW *On Behalf Of * Rayhaan >>> Jaufeerally (IETF) >>> *Sent:* Saturday, April 24, 2021 6:38 AM >>> *To:* grow@ietf.org >>> *Subject:* [GROW] BGP Looking Glass Capability >>> >>> >>> >>> Dear GROW chairs and participants, >>> >>> >>> >>> I would like to propose draft-jaufeerally-bgp-lg-cap-00 ( >>> https://datatracker.ietf.org/doc/draft-jaufeerally-bgp-lg-cap/) as a >>> mechanism for in-band dissemination of looking glass endpoints in BGP, >>> using a new OPEN message capability. >>> >>> >>> >>> The rationale behind this is to facilitate automation around eBGP >>> peering, for example to make it possible to automatically detect if the >>> peer has accepted some routes which are expected to be accepted. >>> >>> >>> >>> I'm aware that the underlying RFC8522 is an informational RFC and leaves >>> some details unspecified for the response format (i.e. a schema for the >>> queries/responses) but I believe that can be further refined in other works >>> independent to this proposal. >>> >>> >>> >>> I would like to hear what the WG thinks, if this is a reasonable >>> proposal which fits into the broader charter of GROW? >>> >>> >>> >>> Thanks, >>> >>> Rayhaan >>> ___ >>> GROW mailing list >>> GROW@ietf.org >>> https://www.ietf.org/mailman/listinfo/grow >>> >> ___ >> GROW mailing list >> GROW@ietf.org >> https://www.ietf.org/mailman/listinfo/grow >> > ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
