Hi, I think Nick meant API to query the local BGP RIB of the router itself not the LG.
For DNS domain there are couple of options. For example we could register new root domain .bgp which would be reserved to be allocated automatically with well known names like ASN.bgp by RIR which allocates ASN. Then lg.[ASN].bgp would be what you are looking for. > The in-band approach solves this by having the BGP speaker forward the LG address of peers that announcements have been forwarded to. Sorry but I assume you know your peers and their ASNs. So not sure I get the benefit of same session (not even guaranteed) autodiscovery. Besides in looking glass you normally do not have access to specific ASBR's RIB ... maybe POP. If so I assume you know which POP to check. Do you rather mean that you want to autodiscover your peer's POP and in the case of LG per POP you want to get specific Looking Glass server address serving that POP ? Keep in mind that accepting the announcement does not mean it is going to be used in forwarding or propagated by BGP upstream. If you are looking for the assurance of the latter I would rather use data plane tools with wisely chosen src address of say enhanced trace to make sure what you announced is installed and used by the peer. Cheers, R, On Mon, Jul 26, 2021 at 2:03 PM Rayhaan Jaufeerally (IETF) <i...@rayhaan.ch> wrote: > 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
