Re: [Sidrops] rfc8210bis further review - question 2

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

Hi Job,

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.

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%7C044f467e351a454a7ed208dc402fa0ac%7C2ab5d82fd8fa4797a93e054655c61dec%7C0%7C0%7C638455820528777145%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=eMgqFnbS0SuxN%2FmBhZgcvcz3PkKV82fqzVBVYuGtZjU%3D&reserved=0<https://www.ietf.org/mailman/listinfo/sidrops>