> 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) <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 <grow-boun...@ietf.org> *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
