search

bgp / stayrtr

RPKI-To-Router server implementation in Go
BSD 3-Clause "New" or "Revised" License
91 stars 13 forks source link

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

Closed job closed 1 month ago

job commented 1 month ago

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 commented 1 month ago

@cjeker what do you think?

ties commented 1 month ago

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 https://github.com/bgp/stayrtr/pull/124#issuecomment-2271440693, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABQTERE3CDKZRAWQO63E2TZQDMYRAVCNFSM6AAAAABMCOZFVOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENZRGQ2DANRZGM . You are receiving this because you are subscribed to this thread.Message ID: @.***>

job commented 1 month ago

@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 commented 1 month ago

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 https://github.com/bgp/stayrtr/pull/124#issuecomment-2271488224, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABQTETDECUE3BMWUJK5CQLZQDPHTAVCNFSM6AAAAABMCOZFVOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENZRGQ4DQMRSGQ . You are receiving this because you were mentioned.Message ID: @.***>

job commented 1 month ago

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 commented 1 month ago

@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 commented 1 month ago

@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 commented 1 month ago

Looks good to me.