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 <[email protected]> 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 > <[email protected]> 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 > > >
