[db-wg] Problem definition for new NWI (12?) - NRTM service

RRDP was designed in the light of experience with NRTM. It has good
fast convergence, TLS protection, fits the CDN model, and we have
deployment experience.

RDAP mirroring protocol is a design in early test, for RDAP to do NRTM
like mirroring, which was informed by RRDP.

I would like to suggest that a design of an NRTM replacement could
reflect on RRDP, and on the emerging JSON/RDAP mirroring activity.

APNIC is of course interested in the NRTM re-design work: we have
significant investment in NRTM both as an information provider, to
people who want NRTM, and specifically to RADB and RIPE, and for
coordination of Whois data with the NIR, and with two IRR sources
operating in region: JPIRR and IDNIC's new IRR.

cheers

-George

On Mon, Nov 16, 2020 at 10:38 PM denis walker via db-wg <db-wg at ripe.net> wrote:
>
> Hi Stavros
>
> Thanks for starting this off with a draft problem statement. As there
> has been a lot of interest in this recently we will initiate "NWI-12
> NRTMv4". Ed can you set that up on the NWI web page?
>
> We would welcome comments from other community members on this problem
> statement.
>
> cheers
> denis
> co-chair DB-WG
>
> On Fri, 13 Nov 2020 at 21:58, Stavros Konstantaras via db-wg
> <db-wg at ripe.net> wrote:
> >
> > Dear db-wg community,
> >
> > Please find below the problem definition for the (upcoming) NWI-12 item as we have discussed it and envisioned it for this project.
> >
> >
> > Problem definition:
> >
> > Back on October 2019 during the RIPE 79 meeting in Rotterdam, we discussed about the  need to move forward with a next generation of NRTM service. Upon the completion of NWI-9 and the lifting of the legal restrictions, we can now proceed to design the new solution. As we discussed preciously, the version 3 of the current NRTM solution is not suitable anymore for network operations on 2020. A summary of the reasons are:
> >
> > -Is a Telnet based protocol, thus:
> > • No keep alive mechanism is adopted,
> > • It provides plain text/unencrypted transport of data
> >
> > -The bootstrap process is not always trivial and sometimes is slow
> > -Long time synchronisation is complicated and users need to re-synchronise after a couple of weeks.
> > -No well specified protocol (There is just a PDF doc that describes it)
> >
> > For all the reasons above (and reasons that we might have not think about yet but you are welcome to share), it becomes a necessity for the community to proceed with a new implementation that will be easily adopted by modern tools and last for the years to come.
> >
> >
> > I hope the above text is sufficient for the db-wg chairs to kick off the process and the community to share its feedback.
> >
> >
> > Best regards,
> >
> > Stavros Konstantaras | Sr. Network Engineer | AMS-IX
> > M +31 (0) 620 89 51 04 | T +31 20 305 8999
> > ams-ix.net
> >
>