Re: [db-wg] Interest to continue NWI-9

[Sasha Romijn via db-wg]

Hello Denis,

A new NWI sounds reasonable.

Working towards a solution that can then be implemented fairly quickly in
IRRd and the RIPE database is great, because it’ll allow us to reach fairly
wide adoption on a relatively short timescale.

I can’t make the proposed call, but I’ll wait to see what comes out of that
first - as the person who implemented NRTMv3 in IRRd and will be writing
on IRRd’s NRTMv4 implementation, I do have opinions :)

Sasha


> On 30 Oct 2020, at 08:36, Stavros Konstantaras via db-wg  
> wrote:
> 
> Hi Dennis, 
> 
> I agree to close NWI-9 and proceed with opening of NWI-12 in order to explore 
> ways
> to modernise the NRTM service. With that said, please consider my interest 
> also for
> NWI-12. 
> 
> 
> Best regards,
> 
> Stavros Konstantaras | Sr. Network Engineer | AMS-IX 
> M +31 (0) 620 89 51 04 | T +31 20 305 8999
> ams-ix.net 
> 
>> On 29 Oct 2020, at 18:30, denis walker > > wrote:
>> 
>> Hi Job
>> 
>> I would agree that NWI-9 is finished, according to the way it is
>> worded. I would suggest we create NWI-12 to move forward with a new
>> version of NRTM. Perhaps you could write the first draft of the
>> problem statement?
>> 
>> cheers
>> denis
>> co-chair DB-WG
>> 
>> On Thu, 29 Oct 2020 at 18:09, Job Snijders > > wrote:
>>> 
>>> 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 

Re: [db-wg] Interest to continue NWI-9

[Stavros Konstantaras via db-wg]

Hi Dennis, 

I agree to close NWI-9 and proceed with opening of NWI-12 in order to explore 
ways
to modernise the NRTM service. With that said, please consider my interest also 
for
NWI-12. 


Best regards,

Stavros Konstantaras | Sr. Network Engineer | AMS-IX 
M +31 (0) 620 89 51 04 | T +31 20 305 8999
ams-ix.net

> On 29 Oct 2020, at 18:30, denis walker  wrote:
> 
> Hi Job
> 
> I would agree that NWI-9 is finished, according to the way it is
> worded. I would suggest we create NWI-12 to move forward with a new
> version of NRTM. Perhaps you could write the first draft of the
> problem statement?
> 
> cheers
> denis
> co-chair DB-WG
> 
> On Thu, 29 Oct 2020 at 18:09, Job Snijders  wrote:
>> 
>> 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
>>>  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,