Dear group,

I think NWI-9 needs to be reworded, it in part has been over taken by
current events. Rereading 
https://www.ripe.net/ripe/mail/archives/db-wg/2019-April/006236.html
what is described there actually already has completed.

RIPE NCC's NRTM servers are open to the public (this was not the case in
april 2019 yet). The NRTM servers can be used to *subscribe* to changes
in the RIPE database. When the NRTM client remains connected, it will
receive NRTM updates as they come in. THIS IS IN-BAND, AND FAST. The
rate of object change is very low compared to most information systems.

Looking at 
https://ripe79.ripe.net/presentations/118-NWI-9_S.Konstantaras_DB-WG.pdf
it is not clear to me what the problem definition is and how it relates
to the wording of NWI-9. The proposed optimisations are either not in
the RIPE IRR -> Cache layer (as NRTM is really near-real-time when
implemented correctly) but elsewhere in the end-to-end route server
functionality. From this perspective NWI-9 has already been completed!

Now, there is plenty to be left desired about NRTM v3. Even though it is
both a push and pull protocol and very fast (the push can measured in
single digit seconds), NRTM v3 clearly is an ancient protocol and the
operational community would benefit from a re-design of NRTM.

WORK IS UNDER WAY: LACNIC has committed funding for IRRd's NRTM v4
implementation. RIPE NCC's 'good for the Internet' community fund has
also been requested. That decision is still pending with the committee
operating that fund.

So what we have so far:

    - A collective desire to replace NRTM v3 with something else
    - The *only* two IRR server code bases of this industry have
      (partial) funding to make changes possible: IRRd and RIPE WHOIS server
    - A standardisation forum to publish the new spec: IETF
    - Multiple forums for input: RIPE DB-WG, IETF, *NOG, IRC, etc

If NWI-9 is kept open I would request it is reworded to the extend that
this working group requests RIPE NCC to commit to help design,
implement, test & adhere to what will become "NRTM v4".

I read Stavros' presentation where the above plan is listed as
'Langzaam' :-) but the characterization may be a little bit off: there
is no Legal aspect to deal with: RIPE NCC made NRTM  freely,
contract-less, publicly and in real-time available already. Also keep in
mind that any new protocol will indeed need to be tested (even if
general purpose components such as JSON, HTTPS and WebSockets are
used!).

NRTM v4's design will have nothing to do with how NRTM v3 looks and
feels. NRTM v4 will be HTTPS based, I guarantee it! This project has
'NRTM v4' as name to make it clear to the IRR operational community
where in the internet-stack this protocol belongs, but that it is an
improvement over version 3.

NRTM v4 can easily be something that is finished and deployed in 2021.
What needs to be done is fairly straight-forward, and lots of existing
tools can be used to make the job easier (like HTTPS and JSON).

Kind regards,

Job

On Thu, Oct 29, 2020 at 05:22:10PM +0100, denis walker via db-wg wrote:
> Hi Stavros
> 
> Thanks for the comment. I have let Ed know about your interest.
> 
> cheers
> denis
> co-chair DB-WG
> 
> On Thu, 29 Oct 2020 at 17:11, Stavros Konstantaras via db-wg
> <db-wg@ripe.net> wrote:
> >
> > Hi WG chairs,
> >
> >
> > I would like to declare that from our side we are still interested to team 
> > up with Ed and RIPE NCC colleagues to continue the work on NWI-9 item
> > in order to modernise the NRTM service with something better and more 
> > suitable for our current needs.
> >
> > As far as I can recall, Ed and his team have several ideas to proceed 
> > forward with this subject, so I believe that we would be able to draw a 
> > clear development plan.
> > And as a kind reminder, not only us (AMS-IX) but the European IXP community 
> > has expressed interest on proceeding with that subject.
> >
> >
> > Thank you and we are looking forward to discuss further steps on the 
> > subject.
> >
> >
> >
> > Best regards,
> >
> > Stavros Konstantaras | Sr. Network Engineer | AMS-IX
> > M +31 (0) 620 89 51 04 | T +31 20 305 8999
> > ams-ix.net
> >
> 

Reply via email to