Re: [Sidrops] rfc8210bis further review - question 1

[Claudio Jeker <[e-mail]>]

On Sat, Mar 09, 2024 at 05:40:29PM +0100, Job Snijders wrote:
> On Sat, 9 Mar 2024 at 17:35, Claudio Jeker <[e-mail]> wrote:
> 
> > 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.
> 
> 
> 
> The friction here can be resolved if the cache imposes total ordering, and
> the router checks for the order (doable in a single pass). Imposing total
> ordering also helps with potential for some race conditions.

If you enforce total ordering then the router can check if the previous
object is strictly smaller than the current one. Right now the standard
does not enforce any ordering of objects so this can not be enforced for
version 0 and 1. So the enforcement can only happen in a newer version.
 
> 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.
> 
> 
> 
> So if the MUST is violated, what’s the appropriate error code?

I can't answer this question, I guess you can pick one at random since the
RFC does not specify it.

-- 
:wq Claudio