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