Hi Job,
AFAIK (and perhaps I'm missing something) an NRTM feed has a few drawbacks:
1. It still is a pull rather than a push mechanism
2. It doesn't allow any granularity to receiving only specific objects:
We would
need to receive all of the database as-set and aut-num objects and parse
them for the ones we're interested in
3. It needs some red tape before being able to consume it
Kind regards,
Aris
Job Snijders wrote on 23/03/2019 20:05:
Dear Aris,
Did you consider consuming a NRTM feed? That’s an approach that
already exists.
Kind regards,
Job
On Sat, Mar 23, 2019 at 19:22 Aris Lambrianidis via db-wg
<[email protected] <mailto:[email protected]>> wrote:
Hi Denis,
We, and other IXPs, create filters (prefix-lists) for services
such as route servers, by parsing aut-num and as-set objects from
IRR databases, such as the RIPE database, using tools such as bgpq3.
Right now, to the best of my knowledge, the only way to maintain
those filters up to date for all of our route server peers, is to
periodically poll IRR databases for changes.
IMO it would seem more efficient if the database itself notified
us of any changes, rather than us constantly asking the same
question(s).
Does this make sense?
That said, I can also think of other use cases in which interested
parties having no direct relationship to certain objects and their
maintainers are interested in finding out of any changes,
especially in the field of research, but let me not delve into
this and keep things simple for the time being.
Kind regards,
Aris
[email protected] <mailto:[email protected]> wrote on
23/03/2019 02:26:
Hi Aris
Can you clarify one point about this. Are you saying you want to
be notified if someone changes their data that you have no direct
relationship with? So if I maintain a set object and you are not
part of my company and have no direct business relationship with
me and I have no idea who you are, but if I modify this object
you want to be notified?
cheers
denis
co-chair DB-WG
On Saturday, 23 March 2019, 01:02:48 CET, Aris Lambrianidis via
db-wg <[email protected]> <mailto:[email protected]> wrote:
Hi Wilfried,
Thank you for the effort in helping out!
Unfortunately this will not do as:
1. It notifies via an "out-of-band" method (i.e. email). This makes
it difficult (but not impossible) to handle with automation.
Nonetheless, the
more elegant way would be through an API leveraging a push mechanism.
but more importantly:
2. the "notify:" attribute has to actually be configured with an
address
of the
interested party for it to work.
However I'm looking for mechanism for interested parties to be
notified of
any changes in objects independently to what the maintainer has
configured
as a notify address.
Kind regards,
Aris
Wilfried Wöber wrote on 22/03/2019 21:50:
> Hi Aris!
>
> Is this what you are looking for?
>
>
https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/notifications/9-2-notification-messages/9-2-1-notification-attributes
>
> I may be off-track, of course :-)
> Wilfried
>
> On 22/03/2019 20:29, Aris Lambrianidis via db-wg wrote:
>> Dear all,
>>
>> Back in the day, RFC1996 introduced the NOTIFY mechanism in
DNS, which significantly helped with information propagation delay,
>> as it facilitated the transition from a pull (poll) to a push
(interrupt) model.
>>
>> The problem we, as AMS-IX, are facing is quite similar when it
comes to polling the RIPE database for changes. This seems
>> inefficient.
>>
>> Although the analogy breaks down quickly, as there are no RIPE
database "clients" similar to DNS slave servers
>> parsing NOTIFY messages, we would love to see any RIPE API
created or extended, or any other mechanism implemented by which
>> a client "registers interest" for any objects it wants to be
notified of changes.
>>
>> As a simple example, if we were to "register interest" (e.g.
via a REST POST or PUT method) for the AS-AMS-IX-SET as-set
object, we would be
>> programmatically notified whenever the "last-modified" field
of the as-set was changed.
>>
>> Based on the above, I have 3 questions:
>> 1. Does something like what is described above already exist?
>> 2. If it doesn't exist, would others be interested on such
functionality?
>> 3. If it doesn't exist, while knowing that this is only a high
level overview of the concept and many details are missing, is
this generally feasible?
>>
>> Kind regards,
>> Aris Lambrianidis
>> AMS-IX
>>
