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

[Job Snijders <[e-mail]>]

Hi Marco,

On Wed, Dec 17, 2025 at 02:38:01PM +0100, Marco Marzetti wrote:
> I am working on a Python implementation of a RTR Cache, and I noticed
> some ambiguity around how session mismatch should be handled.

Thank you for your implementation work and document review. I think your
message yet again demonstrates the incredible value of actually
implementing specifications before publishing them as RFC. This is
something other WGs could learn from (looking at you, OPSAWG!).

> 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?

The use of an Error Report forces the Router to flush all data, while on
the other hand the Section 5.3 text makes it so that the data could be
retained - until the Reset procedure is complete, or the Expire Interval
timer is reached.

In other words, AIUI, forcing a reset has a graceful aspect, while an
Error Report causes an immediate deletion of data on the router's side.

If a router is configured to use multiple caches then there likely is
continuity because of the data from other caches, but in case of a
router using a single cache, then a restart of that single cache causes
the validated payload data to first be deleted and then be (re)learned
(if an error report is send instead jumping to the reset procedure).

I believe code 0 ("Corrupt Data") reports primarily are intended for
things that don't neatly fit in any other error report category.

I suspect that the section 5.3 approach causes less churn in the BGP
control-plane.

In any case, I agree with you that there is friction between Section 5.1
and Section 5.3 and that needs resolving.

What do others think?

Kind regards,

Job