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

[Tim Bruijnzeels <[e-mail]>]

Hi Randy,

As I said I don't oppose the single VRP per ROA recommendation. On the
contrary.


> On 10 Mar 2022, at 04:53, Randy Bush <[e-mail]> wrote:
> 
>> This is an issue if, per Randy's example, the entire ROA is withdrawn first,
>> the RPs fetches and revalidates and sends withdraws for VRPs to the router,
>> and then the new ROA is published later, validated, etc
> 
> no need.  CA publishes old an new ROAs.  RP fetches both and processes
> sequentially.  oups!
> 
> and now we can expect to hear folk suggest that the RP should swallow
> and digest the entire ROA set (think of the scale of this a few more
> years out), reconcile it all, and only then send the reconciled VRPs
> to the router.  if the current state of RP software is any indication,
> i would not want to bet my routing on this.

Indeed. Typically what happens in practice is:
1. CAs will publish objects as a set
2. RPs will fetch objects as a set (and reject failed fetches per mft-bis)
3. RPs will do a full analyis of fetched objects to make a set of VRPs
4. RTR servers will send the diff in VRPs to routers and do work to avoid
   duplicates and race conditions

I did not dig up all the normative language in specs, but in my understanding
the above is what is specified. There is a lot of text - some of it is being
discussed but not yet published as RFC - I may have missed something.

In any case if it's bugs or scaling issues that you are worried about,
then I think it would good to spell that out in the draft. I am not
opposing that at all - and indeed single VRPs per ROA may help to
keep things simple. But as written it seems to say that current implementations
do things they are (to my knowledge) not currently doing and I think
that is confusing.

Furthermore.. this draft is informational and avoids using normative
language.. so am I correct in concluding that it does not try to forbid
combining multiple prefixes? Essentially it gives advice to CAs.

For example the APNIC AS0 currently has close to 14k prefixes. They could
of course be split into as many objects but that's a lot of objects..

This is of course an extreme case. But what about a 100 for example?
Would that be enough to decide to combine prefixes in a single object?

It would be useful to me to hear from RP implementers what they believe
a good threshold value might be, or that they prefer to have separate
objects always.. it would help me to set sensible defaults in CA software.
Including possibly: don't aggregate unless specifically instructed by the
operator.

Thanks

Tim


> 
> randy
> 
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops