Hi Rayhaan, Two follow up comments:
> In the bgp.io case it would depend on .io being available Is this a concern ? My company's domain ntti3.io is using .io TLD :) > - Seems to have never progressed past the initial -00 draft and it is a much larger effort to revive that What I meant is not to force implementation of the entire draft draft-ietf-idr-operational-message-00. Just take the draft and make all current messages optional and define yours. So willing implementation can add new AFI/SAFI and just your new LG Message. Done. Reason being that as this is really an operational message it fits there nicely. "Burden" to implement everything (all or nothing) does not really need to be the case. And while in waiting for implementations state this is already IDR WG document too :) Cheers, Robert. On Sun, Apr 25, 2021 at 2:59 PM Rayhaan Jaufeerally (IETF) <i...@rayhaan.ch> wrote: > Thanks Jakob and Robert for the insights, > > > Not using BGP Capability to do it > > That's a great point and does raise some fundamental questions on how this > information will be propagated, I had limited my initial proposal to only > considering propagating this information to direct peers since that was a > good starting point, and would answer the question of "Has this prefix been > accepted by my peer" in the context of turning up a new link. However, now > that you mention it I can also see the benefits of checking specific > networks for reachability, e.g. if the prefix has been accepted by Tier 1 > networks for instance (although in that case it could be argued that an > in-band mechanism is not necessary). > > > Changes cannot be signaled without restarting the session > > Yup that totally makes sense for not using a capability, and especially if > this is going to be used to propagate looking glass information more than > one hop away, some other mechanisms should be used, > > There are a bunch of ideas to consider here so I thought it'd be easier to > make a list: > > - New address family > - + Innovative solution to propagate this information, > - + I can see the case for making something more generic if we go > down this path, since there can be other useful information to > propagate in > addition to the LG URL, specifically things which the Operational > message > type wanted to achieve, but putting it into this AF instead of a new BGP > message > - Well known URL / .lookingglass / subdomain of bgp.io > - + Easy to set up / could be something like peeringdb (which > already does have looking glass URL, but that's not API standardized in > any > way and is for human debugging) > - - Hands control / failure domain of this mechanism to a third > party. > - In the bgp.io case it would depend on .io being available and > AS operators registering with whatever mechanism for announcing the > URL of > the looking glass > - In the .lookingglass TLD option, the TLD needs to be applied > for and the ICANN TLD fees etc, then there needs to be a registrar > which > will process registrations for this TLD > - In both the above cases it seems like manual additional work > is required, which does not yield direct benefit to the AS operator > which > makes me wonder how many operators would take the time to set it up > - New optional path attribute > - + In band, updatable anytime, propagates together with the > prefixes, so upon receiving any prefix from a distant peer, the LG URL > is > also available, which the Operational message or Notification message > extension aren't as amenable to > - - There would need to be some mechanism to limit the propagation > of this attribute to each peer per source AS, because otherwise it would > waste a lot of space in update messages repeatedly sending the same URL > on > every Update message. > - Operational message type > - + Good design fit for the application here > - - Seems to have never progressed past the initial -00 draft and > it is a much larger effort to revive that > - Adding a new Notification message type > - This is kind of a middle ground between a new AF and a path > attribute > - + Not tied directly to Update messages so can be decoupled from > that logic in implementations > > Given the above I am most intrigued by the opportunities that adding a new > AF would provide, particularly since it could cover some additional use > cases, for example I can imagine in the transition to dropping RPKI invalid > routes and future routing security mechanisms, could be useful to relay > back information that a particular prefix has been dropped for $reason. > > If the new AF is something that others see promise in I would be happy to > start drafting some thoughts on how it could work, and rework this > particular draft to use that mechanism. > > Have a great Sunday, > Rayhaan > > On Sun, Apr 25, 2021 at 2:03 PM Robert Raszuk <rob...@raszuk.net> 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= >> 40cisco....@dmarc.ietf.org> 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 <grow-boun...@ietf.org> *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 >>> >>
_______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
