Re: [Sidrops] rfc8210bis further review - question 1

[Claudio Jeker <[e-mail]>]

On Sat, Mar 09, 2024 at 12:36:37PM +0100, Job Snijders wrote:
> Dear all,
> 
> I have some questions about rfc8210bis
> 
> Question #1
> ===========
> 
> In Section 8.2:
> 
>     Cache                         Router
>       ~                             ~
>       | -------- Notify ----------> |  (optional)
>       |                             |
>       | <----- Serial Query ------- | R requests data
>       |                             |
>       | ----- Cache Response -----> | C confirms request
>       | ------- Payload PDU ------> | C sends zero or more
>       | ------- Payload PDU ------> |   IPv4 Prefix, IPv6 Prefix,
>       | ------- Payload PDU ------> |   ASPA. or Router Key PDUs
>       | ------- End of Data ------> | C sends End of Data
>       |                             |   and sends new serial
> 
> and section 5.6 "IPv4 Prefix" states
> 
>     """
>     The cache server MUST ensure that it has told the router client to have one
>     and only one IPvX PDU for a unique {Prefix, Len, Max-Len, ASN} at any one
>     point in time.  Should the router client receive an IPvX PDU with a
>     {Prefix, Len, Max-Len, ASN} identical to one it already has active, it
>     SHOULD raise a Duplicate Announcement Received error.
>     """
> 
> Imagine the cache emits the following sequence of PDUs:
> 
>    Cache                                   Router
>    ~                                       ~
>      <-- Serial Query                       
>    Cache response                      -->
>    Announce 2001:db8::/32 Origin 65535 -->
>    Withdraw 2001:db8::/32 Origin 65535 -->
>    Announce 2001:db8::/32 Origin 65535 -->
>    End of Data w/ new serial           -->
> 
> A VRP for 2001:db8::/32 is announced, withdrawn, and announced again.
> 
> Should the above sequence of PDUs trigger the 'Duplicate Announcement
> Received' error?
> 
> I'd take "only and only at any one point in time" where 'point in time'
> is the window between the last serial and the next serial? To what
> extend can routers expect caches to provide a consistent view within a
> single Cache Response?

This is covered in section 5.3 Serial Query:

   When replying to a Serial Query, the cache MUST return the minimum
   set of changes needed to bring the router into sync with the cache.
   That is, if a particular prefix or router key underwent multiple
   changes between the Serial Number specified by the router and the
   cache's current Serial Number, the cache MUST merge those changes to
   present the simplest possible view of those changes to the router.
   In general, this means that, for any particular prefix or router key,
   the data stream will include at most one withdrawal followed by at
   most one announcement, and if all of the changes cancel out, the data
   stream will not mention the prefix or router key at all.

So the above violates the MUST in the first sentence.
 
Now OpenBGPD as a RTR client does not try to track down such issues. It
requires a to complex data structure and in the end as long as the per-RTR
state is consisten we do not care. As mentioned in an other mail the
per-RTR state is atomically applied to the global config once the End of
Data PDU is received.

-- 
:wq Claudio