Switch back to RTR version 1 - RFC 8210; the ASPA work still is in flux hindering users

[job]

Switch to RTR version 1 by default (RFC 8210); the ASPA work still is in flux hindering users.

We can revisit this choice in a few months

[job]

@cjeker what do you think?

[ties]

What issues do we see? Is the version negotiation failing?

…

On Tue, Aug 6, 2024, 07:30 Job Snijders ***@***.***> wrote: @cjeker <https://github.com/cjeker> what do you think? — Reply to this email directly, view it on GitHub <#124 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABQTERE3CDKZRAWQO63E2TZQDMYRAVCNFSM6AAAAABMCOZFVOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENZRGQ2DANRZGM> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[job]

@ties In environments where mixes of older and newer versions are used (OpenBGPD, Routinator, StayRTR), we've now received a number of reports about confusion and things not working as people expect them to work.

Since the ASPA PDU format is not stable: there still are outstanding issues, the authors appear to be very busy with other non-ASPA things, I think we need to cut our losses and let the users come first.

It's easy to change this in the future once ASPA RTR is more fleshed out.

Related and ignored: https://mailarchive.ietf.org/arch/msg/sidrops/F5DJRF9Mkqef1pONEOcSqahVWok/

[ties]

It feels like we burned a version number by having a potential format change after the first release of the support. In a protocol with weak version negotiation. Yikes.

…

On Tue, Aug 6, 2024, 07:51 Job Snijders ***@***.***> wrote: @ties <https://github.com/ties> In environments where mixes of older and newer versions are used (OpenBGPD, Routinator, StayRTR), we've now received a number of reports about confusion and things not working as people expect them to work. Since the ASPA PDU format is not stable: there still are outstanding issues, the authors appear to be very busy with other non-ASPA things, I think we need to cut our losses and let the users come first. It's easy to change this in the future once ASPA RTR is more fleshed out. Related and ignored: https://mailarchive.ietf.org/arch/msg/sidrops/F5DJRF9Mkqef1pONEOcSqahVWok/ — Reply to this email directly, view it on GitHub <#124 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABQTETDECUE3BMWUJK5CQLZQDPHTAVCNFSM6AAAAABMCOZFVOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENZRGQ4DQMRSGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[job]

It feels like we burned a version number by having a potential format change after the first release of the support. In a protocol with weak version negotiation. Yikes.

Yes. Could’ve been avoided if the development cycle was slightly faster than changing spec once every 14 months

[cjeker]

@cjeker what do you think?

Why Version 0 instead of 1 (RFC8210)? RFC 8210 includes a different 'End of Data' PDU which includes the timing params.
I think StayRTR should default to 1 even though nobody needs the BGPSec keys.

[job]

@cjeker what do you think?

Why Version 0 instead of 1 (RFC8210)? RFC 8210 includes a different 'End of Data' PDU which includes the timing params. I think StayRTR should default to 1 even though nobody needs the BGPSec keys.

You make a good point, thanks for the clue bat

[cjeker]

Looks good to me.