[DBWG] Fwd: NRTM replication inefficiencies

[Daniel Shaw]

Dear AFRINIC DB WG,

Just an FYI of something that came up in the RIPE NCC's WG below.

Interesting..

What does this group think about this?

Regards,
Daniel


> Begin forwarded message:
> 
> From: Job Snijders via db-wg <db-wg at ripe.net>
> Subject: [db-wg] NRTM replication inefficiencies
> Date: 8 November 2017 at 02:11:17 GMT+4
> To: db-wg at ripe.net
> Reply-To: Job Snijders <job at instituut.net>
> 
> Dear all,
> 
> There may be some improvement opportunity for NRTMv3.
> 
> The problem with the RIPE NRTMv2/NRTMv3 format is that it has no
> 'end-of-stream' indicator, thus making the only way to know that the
> output has ended (vs. hung/stalled/server dead) is either by observing a
> time-out & reconnect & compare last serial, or by using single-command
> connections to the NRTM server - which means even worse performance.
> 
> When connecting to the RIPE NRTM service and issuing a command like:
> 
>    "-g RIPE:3:11012700-LAST -k"
> 
> It would be good that when the RIPE NRTM server is done sending its
> inital blurp of backlogged data, the end of that phase of the stream of
> objects is marked by the server sending something like: 
> 
>    "%CURRENT $TS You are now up to date" ($TS can be a unix timestamp)
> 
> after this server message the client knows that it can stay connected
> and that it has received all information so far.
> 
> I would also welcome an investigation into alternative approaches, (some
> not-via-WHOIS replication mechanisms), perhaps something over HTTPS can
> be done? Either way, something more robust would be useful.
> 
> Kind regards,
> 
> Job
> 
> ps. An analogy can be made between BGP route refresh as described in RFC
> 2918 and Enhanced Route Refresh as described in RFC 7313. One first one
> didn't have an "End of blurp" marker which negatively impacted its
> usefulness, the later RFCintroduced the End-of-RIB marker which is
> very useful.
> 
>