On 8/11/21 2:29 AM, Leonard Crestez wrote:

On 8/10/21 11:41 PM, Dmitry Safonov wrote:

quoted

Hi Leonard,

On Tue, 10 Aug 2021 at 02:50, Leonard Crestez [off-list ref]
wrote:
[..]

quoted

+/* Representation of a Master Key Tuple as per RFC5925 */
+struct tcp_authopt_key_info {
+       struct hlist_node node;
+       /* Local identifier */
+       u32 local_id;

There is no local_id in RFC5925, what's that?
An MKT is identified by (send_id, recv_id), together with
(src_addr/src_port, dst_addr/dst_port).
Why introducing something new to already complicated RFC?

It was there to simplify user interface and initial implementation.

But it seems that BGP listeners already needs to support multiple
keychains for different peers so identifying the key by (send_id,
recv_id, binding) is easier for userspace to work with. Otherwise they
need to create their own local_id mapping internally.

any proposed simplification needs to be well explained and how it
relates to the RFC spec.