Hi,
On Mon, Jul 26, 2021 at 2:49 PM Robert Raszuk <[email protected]> wrote: > Hi, > > I think Nick meant API to query the local BGP RIB of the router itself not > the LG. > I was under the impression that the LG would provide a view of the RIB of the ASBR? > > 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. > That would be a neat solution and I can imagine other uses for such a domain name, e.g. RPKI certificate hosting, peering policy etc, so it might be worth looking into as a broader effort. It still requires coordination with some kind of authoritative DNS service though so it would not be standalone from the point of the BGP speakers. > > > > 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. > Yes you know the direct peers that you have established sessions with, but whom they decide to forward announcements to may also be of interest. Consider a leaf AS which buys IP transit from a local ISP, which then has a mix of 3 tier-1 upstreams. I think it would be useful for the leaf AS to automatically discover what tier-1 ASes the announcement gets forwarded to, so that they can check for reachability in them to make sure they are not filtered out due to having a misisng IRR or bad RPKI config, or whatever other policy reason. > > 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 ? > Yes that is what I was trying to do with the router query parameter from RFC8522, and once you know which "router" or PoP to query, my assumption would be that if you peer with any ASBR in that PoP then the looking glass should, if the route was accepted, display it when you look the prefix up? > > 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. > Sure of course there's no guarantee that it will be used in the FIB, but my rationale was, if it's not in the RIB then it's for sure not in the FIB, so let's check that the desired routes are in the RIB by looking through the LG. Cheers, Rayhaan > > Cheers, > R, > > > On Mon, Jul 26, 2021 at 2:03 PM Rayhaan Jaufeerally (IETF) < > [email protected]> 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 <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/grow
