Re: [Sidrops] [WGLC] draft-ietf-sidrops-roa-considerations-01 - Ends 10/March/2022

[George Michaelson <[e-mail]>]

I am not a BGP speaker and I don't forward packets. I no longer have a
role in the Registry RPKI service delivery here at APNIC so in many
respects my comments are superfluous. That noted, I support
publication.

I was asked by one of the authors to comment, otherwise I would have
remained silent given my lack of role in things: On the whole, I think
it is better for the BGP speakers, the RP and CA developers, to be the
voices heard here these days.

I have read this draft, and I think it provides useful information
regarding the distribution of ROA and contents under each TA, as of
last year. It also provides non normative recommendations to single
prefix per ROA. Any quibbles I have to language could be dealt with,
and have no impact on the semantic intent of the document: I would be
amazed if they aren't ironed-out in the publication process anyway.

The analysis shows that many ROA are made by hosted services in two
RIR (RIPE and APNIC) as of 2021 so  we probably need to reflect on
what has to change to stop grouping up the contents, or how to specify
if you want this not to be done as a delegate controlling resources.
This may be OBE anyway, understanding the producer side code
behaviours would be good but doesn't really hinder publication noting
that the document is non normative advice. Thats for other people to
speak to, I no longer occupy the role which has to determine what to
do here.

I think Rob's comment to "premature optimisation" is a good one.
Allowing multiple prefix per ROA was done for good intent, that it
turns out to be counter-productive is a shame, but reality trumps.

I do have some concerns about the impact of unwinding the multiple
prefix per ROA model, but this has to go to scale/time questions not
absolute ones: we can expect the volume of ROA to increase anyway so
this is about changing the rate of update and volume of discrete
objects, and consequence to RRDP delta size, and rsync serial fetch
size/delay which was going to be met anyway in due course.  I think RP
implementations which unpick VRP to then subsequently re-assert
validity possibly need to change to do more of the 'hysteresis'
preserving behaviour in FIB and RIB we see in BGP seeking to limit
change. To me, this goes to the 'all information, not atoms' idea
behind the repository fetch model that we have. It would not be this
document which helped fix or ameliorate that problem so I see no
barrier to publication.

-George