I totally agree that an API for programmatically querying the LG would be
the next step on the road to implementing the overall goal, but I picked
this smaller task of discovering the looking glass first, before designing
the broader ecosystem.
I thought of the following concerns when evaluating the DNS approach (I
think it's been discussed earlier too):
- You need to have some DNS zone for the AS, and there's no guarantee
that AS 65534 can get a domain like as65534.net
- You could use something like reverse DNS zones in in-addr.arpa for
example to map the IP of the ASBR to an SRV record or something, but
- That requires a coordination between the DNS zone management and
looking glass / BGP operations, and in larger organizations it might be
more work to set that up which I fear will impede adoption,
- In the DNS approach you don't know to which peers a route announcement
was forwarded to, so how would you then know which ASes to look up the
looking glass for? The in-band approach solves this by having the BGP
speaker forward the LG address of peers that announcements have been
forwarded to. That way the downstream AS can discover which upstream peers
exist and query the LG and probe reachability that way,
I think the last point is the most concerning for me, the fact that it's
all self contained is more of a nice to have, but I think not knowing
programatically what peers announcements are being forwarded to would limit
the usefulness of the DNS approach, I'm happy to be convinced otherwise
though :).
Cheers,
Rayhaan
On Mon, Jul 26, 2021 at 11:31 AM Nick Hilliard <n...@foobar.org> wrote:
> Robert Raszuk wrote on 26/07/2021 00:04:
> > I am still not sure what is wrong using DNS for this type of discovery.
> > If I were to tackle this problem I would start with DNS.
>
> ^^^ this, but I'm not convinced that dynamic discovery of LG endpoints
> is a pressing issue to start with. What's more important is a
> functional API which can retrieve the rib info dynamically (netconf or
> otherwise).
>
> Nick
>
_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
