Re: [Sidrops] rfc8210bis further review - question 2

[Job Snijders <[e-mail]>]

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