Re: [Sidrops] rfc8210bis further review - question 2

["Borchert, Oliver (Fed)" <[e-mail]>]

Our implementation kept it as a session per client-server.

On 3/15/24, 3:38 AM, "Job Snijders" <[e-mail]> wrote:

On Thu, Mar 14, 2024 at 01:22:07PM +0000, Borchert, Oliver (Fed) wrote:
> Others might/do implement the session between a cache and its clients
> in a more traditional sense, where a session ID is not only bound to
> the protocol version but also to the single session between the cache
> instance and a client instance. That means following this approach, if
> the cache instance has five clients, it has five separate sessions, each
> session with its own unique session ID per client and protocol version
> used. This approach fulfills the requirements specified in the draft as
> well. I do not agree with having the documented approach made mandatory;
> it is one of many solutions to how one implements the protocol.

Yes, I too think the session-per-client-per-version approach meets
the objectives, but might be more complicated (the RTR server
would have to keep track of when to consider a Session dead and do
garbage collection). Question out of curiosity: do you know of any
implementation that does things in the way you describe?

My main point was that RTR server implementers need not (SHOULD NOT?)
generate just a single Session ID, but for robustness, generate a
Session ID per protocol version. The approach you describe goes a step
further and is something I wouldn't want to disallow, but perhaps also
not explicitly describe or recommend.

Perhaps:

     """
     Session ID:
     When a cache server is started, it generates one or more Session IDs
     to uniquely identify the instance of the cache. It is RECOMMENDED to
     generate one unique Session ID for each of the different protocol
     versions the cache supports, to bind it to the sequence of Serial
     Numbers that cache instance will generate. This allows the router to
     restart a failed session knowing that the Serial Number it is using
     is commensurate with that of the cache.
     """

Kind regards,

Job


>
> Oliver
>
>
> On 3/9/24, 6:54 AM, "Sidrops" <[e-mail]> wrote:
>
> Dear all,
>
> Question 2
> ==========
>
> nit: Section 7 s/the ache can support/the cache can support/
>
> In section 2 there is: """A Serial Number is not commensurate between different
> caches or different protocol versions, nor need it be maintained across resets
> of the cache server."""
>
> And text in section 7 states: """Since Session ID and Serial Number values are
> specific to a particular protocol version, the values in the notification are
> not useful to the router."""
>
> But, the above to me seems to bury the lede a bit.
>
> The cache is well-positioned to impress upon the router implementation
> that Session IDs are specific to protocol version by generating a
> different Session ID for each protocol the cache supports. This need not
> be a RTR-client-side-only thing.
>
> In StayRTR we're experimenting with Session ID's that are spaced 100
> apart based on the protocol version, for robustness:
> https://github.com/bgp/stayrtr/pull/110/files#diff-f7fbf82427d380e634a805b4847b4b7b31984a37307ebd85683e183afd8c610aR169-R173
>
> Perhaps worthwhile to document approach or even make it mandatory? This
> approach seems to help in the face of RTR client implementations that
> got version negotiation slightly wrong.
>
> So perhaps in Section 2, Glossary:
>
>     """
>     Session ID:
>     When a cache server is started, it generates Session IDs to uniquely
>     identify the instance of the cache, one unique Session ID for each
>     of the different protocol versions the cache supports, to bind it to
>     the sequence of Serial Numbers that cache instance will generate.
>     This allows the router to restart a failed session knowing that the
>     Serial Number it is using is commensurate with that of the cache.
>     """
>
> Kind regards,
>
> Job
>
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsidrops&data=05%7C02%7Coliver.borchert%40nist.gov%7C18b0fe0b842b4efa17e808dc44c2e3c4%7C2ab5d82fd8fa4797a93e054655c61dec%7C0%7C0%7C638460851051336505%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=zIGKTHBI%2F8KrDzCc0xvrYt%2FGIEu2AjW9TlESxApalwc%3D&reserved=0<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsidrops&data=05%7C02%7Coliver.borchert%40nist.gov%7C18b0fe0b842b4efa17e808dc44c2e3c4%7C2ab5d82fd8fa4797a93e054655c61dec%7C0%7C0%7C638460851051343655%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=9h%2BvEHMzNSwv4tKIwZZhz85zyft%2F%2FfeGBYztOQBt0l0%3D&reserved=0><https://www.ietf.org/mailman/listinfo/sidrops>