Re: [Sidrops] I-D Action: draft-ietf-sidrops-8210bis-11.txt

[Claudio Jeker <[e-mail]>]

On Thu, Sep 21, 2023 at 11:55:38PM -0700, [e-mail] wrote:
> Internet-Draft draft-ietf-sidrops-8210bis-11.txt is now available. It is a
> work item of the SIDR Operations (SIDROPS) WG of the IETF.
> 
>    Title:   The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2
>    Authors: Randy Bush
>             Rob Austein
>    Name:    draft-ietf-sidrops-8210bis-11.txt
>    Pages:   39
>    Dates:   2023-09-21
> 

Thanks for this update.
Here my feedback to the changes in -11:

4.  Operational Overview

   ... It is configured with a semi-ordered list of caches and establishes a
   connection to the most preferred cache, or set of caches, caches with that
   same priority, which accept the connections.

You added something about priority. Now this is the only time a priority
is mentioned in this whole document. There is no description on what such
a priority is and why it is required.

Again in 4. the new paragraph is indeed an interesting affect on how RTR
works but it does not only affect VRPs:

   A VRP is effective if it is in the fetched set from any of the
   currently preferred caches.  Therefore, a VRP takes effect on the
   router when the first cache serves that VRP, and the VRP is in effect
   until the last cache withdraws that VRP.  Thus, in a global sense,
   the effect of a VRP announcement propagates more quickly than a
   withdraw,

This needs to be reworded since it matters for VRP and Router-Keys.
Also ASPA PDUs are affected by this but there the situation is a bit more
complex. The ASPA PDU Provider Autonomous System Numbers are not part
of the object key and so multiple versions can coexist and need to be
merged. So for ASPA additions to the PAS array propagate more quickly then
any other operation.

Now to "5.12. ASPA PDU":

   The AFI Flags field is defined in Section 15 Currently, the two low
   order bits MUST always be set, i.e. 1, and the rest unset, i.e. 0.
   This allows the router to prepare for less change should the AFIs be
   separated in a future version.

First of all there is a '.' missing after Section 15.

But my main issue is with:
                                                Currently, the two low
   order bits MUST always be set, i.e. 1, and the rest unset, i.e. 0.
   This allows the router to prepare for less change should the AFIs be
   separated in a future version.

How should a router RTR implementation prepare for something that will
probably never happen?

Either the two low order bits MUST always be set (an then the 2nd sentence
is not needed -- since it will break the protocol if changed) or the two
bits can be set and all Routers need to implement something that will not
happen (now that is technical debt from the get go).

While it sounds great, I doubt what it suggests will be feasable without a
full new RFC update.

We will stick to the MUST and only implement a single ASPA database.
Because of this we  will issue an Error Code 0 PDU if the two LSB are not
set.  Having to implement code that is not in regular use and is therefor
not really tested will for sure end in desaster once someone start playing
with these bits.

Also this change is not backwards compatible with previous versions so one
could argue that a more breaking change to the ASPA PDU could be made and
integrating some of the feedback given by other people on SIDROPS.

Last but not least I like the clarification in Section 13.

Regards
-- 
:wq Claudio