Yes I mentioned this case in one of the subsequent emails - LG can be per region etc ... You just register not one by many such looking glass server addresses. Some may be independent .. some may be a pool of servers under same IP.
Thx On Mon, Apr 26, 2021 at 5:59 AM Alejandro Acosta < [email protected]> wrote: > Hello, I guess you have already mentioned this, however I have not found > it yet. Please consider many AS have many different views. That's it. > > Alejandro, > > On Sun, Apr 25, 2021, 8:03 AM Robert Raszuk <[email protected]> wrote: > >> >> > 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= >> [email protected]> 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 <[email protected]> *On Behalf Of * Rayhaan >>> Jaufeerally (IETF) >>> *Sent:* Saturday, April 24, 2021 6:38 AM >>> *To:* [email protected] >>> *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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/grow >>> >> _______________________________________________ >> GROW mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/grow >> >
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
