[Sidrops] Re: draft-ietf-sidrops-8210bis-23 is ambiguous session mismatch handling

[Ralph Covelli <[e-mail]>]

Hi,

The 5.3 wording was added because of me.  Perhaps it can use a little 
more tweaking.

Both Reset Queries and Serial Queries can be the first command issued.

When the Serial Query is the *first command issued* and the session ID 
numbers do not match the RTR cache, then the RTR cache should send a 
Cache Reset.

If a later Serial Query is issued and the session ID number somehow 
changes the RTR cache must terminate the session.

Thanks!

Ralph Covelli
Network Engineer
Hurricane Electric / AS6939

On 12/17/2025 8:38 AM, Marco Marzetti wrote:
> Dear members of the SIDROPS WG,
>
> I am working on a Python implementation of a RTR Cache, and I noticed 
> some ambiguity around how session mismatch should be handled.
>
> At 5.1. (Fields of a PDU) the draft states that:
>       If, at any time after the
>       protocol version has been negotiated (Section 7), either the
>       router or the cache finds that the value of the Session ID is not
>       the same as the other's, the party which detects the mismatch MUST
>       immediately terminate the session with an Error Report PDU with
>       code 0 ("Corrupt Data"), and the router MUST flush all data
>       learned from that cache.
>
> While at 5.3. (Serial Query), the it states:
>    The Session ID tells the cache what instance the router expects to
>    ensure that the Serial Numbers are commensurate, i.e., the cache
>    session has not been changed.  If the Session ID does not match, the
>    cache MUST respond with a Cache Reset.
>
>
> Does that mean that the Cache should send the Error Report PDU in all 
> cases but not in response to a Serial Query?
>
> Thanks
>
> -- 
> Marco
>
> _______________________________________________
> Sidrops mailing list [e-mail]
> To unsubscribe send an email [e-mail]