Hi Robert, On Sun, Apr 25, 2021 at 3:46 PM Robert Raszuk <[email protected]> wrote:
> 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 :) > I don't think it's a concern for one entity, but when coming up with a proposal to be used across the internet by many parties, I think it's a concern since switching the domain at a later point in time would incur some overhead for everyone involved and that's something I would be interested in minimizing. > > > - 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. > Ah right I see, seems like there might be an impedence mismatch to define a new BGP message type in a document focusing on propagating looking glass addresses, but I guess that would flip the document around to having the main focus being the operational message that just happens to define the looking glass element in it. > 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 :) > Makes sense, one thing which I'm still wondering is if it makes more sense to use a new BGP message type or to go with the aforementioned new address family which I presume would use the multiprotocol path attribute to carry the operational payload. The multitude of uses the operational message type would have though could make a case for introducing it at the top level though. I guess a good starting point would be to reach out to IDR folks / authors of the operational message draft and get their input as to why it didn't progress further since that would be useful to guide any revival attempts. Cheers, Rayhaan > Cheers, > Robert. > > > > > On Sun, Apr 25, 2021 at 2:59 PM Rayhaan Jaufeerally (IETF) < > [email protected]> 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 <[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
