Re: [Sidrops] [WGLC] draft-ietf-sidrops-roa-considerations-01

Hi Zhiwei,

> On 24 Apr 2022, at 04:43, YAN Zhiwei <yanzhiwei@cnnic.cn> wrote:
> 
> Hello, Christopher, 
> Yepp.
> 
> And all, 
> Then if there is any special scenario (from either CA or RP consideration) in which aggregation can maintain stability, please feedback.

I provided you with motivated scenarios in an off-list thread.

Instead of a call for more explanation about scenarios where aggregation
increases stability I feel that the draft should first try to clarify what risks
the advice tries to guard against.

For example, in this thread, you mentioned overclaiming. In the off-list thread,
you mentioned, "if one ROA was signed mistakenly, the influence can be reduced
if “one-prefix-per-ROA”". It helps if these scenarios are clarified and included
in the draft.

Kind regards,
Ties

> BR,
> 
> YAN Zhiwei
>  
> From: Christopher Morrow <mailto:christopher.morrow@gmail.com>
> Date: 2022-04-22 22:56
> To: YAN Zhiwei <mailto:yanzhiwei@cnnic.cn>
> CC: Rob Austein <mailto:sra@hactrn.net>; keyur <mailto:keyur@arrcus.com>; sidrops <mailto:sidrops@ietf.org>
> Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-roa-considerations-01 - Ends 10/March/2022
> 
> 
> On Sun, Apr 17, 2022 at 10:52 PM YAN Zhiwei <yanzhiwei@cnnic.cn <mailto:yanzhiwei@cnnic.cn>> wrote:
> Hello, guys,
> 
> As Rob, George, Di and others mentioned, there are two sides to everything. Especially for a security service, the basic motivation of RPKI is for more secured routing system, while it will surely introduce other new risks. We want to optimize it during its designing, but it’s more important to deploy and test it with a more simple logic. I totally agree with Tim, there are some specific situations (…AS0 ROAs for unallocated space that some RIRs publish…) where the resources are more stable and with low risk wrt overclaim, it’s worthy to pack the ROAs together to improve the RP’s efficiency. Then if we have rough consensus about this principles, what we need to do are:
> 
> 1) Describe the one-prefix-per-ROA as a basic advice of CA operation;
> 
> 2) List the specific scenarios which have low risk wrt overclaim as the optimization situations CA may consider.
> 
> 
> sounds like your advice is: "largely do 1 / prefix", with guidance on when to expand that, perhaps an algorithm even...
> Is it worth noting that at the top levels there may be more skew toward aggregating  vs singular records? (or would that fall out of the research being done perhaps?)
> I'm pretty sure a 'one size fits all' will not work :) so your plan seems reasonable to me.
>  
> BR,
> 
> YAN Zhiwei
>  
> From: Rob Austein <mailto:sra@hactrn.net>
> Date: 2022-03-07 09:06
> To: Keyur Patel <mailto:keyur@arrcus.com>
> CC: sidrops@ietf.org <mailto:sidrops@ietf.org>
> Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-roa-considerations-01 - Ends 10/March/2022
> I support publication of this draft.
>  
> Two comments, for whatever they're worth:
>  
> 1) In retrospect, the ability to specify multiple prefixes in a single
>    ROA seems like premature optimization: it's solving a problem I'm
>    not convinced we really have, at the expense of creating a new one.
>  
> 2) I tend to think about the multiple-prefix ROA problem in terms of
>    "fate sharing": unless all the prefixes involved are in some way so
>    closely tied to each other that there will never be a change to one
>    of them that isn't a change to all, they should be separate ROAs.
>  
>  
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org <mailto:Sidrops@ietf.org>
> https://www.ietf.org/mailman/listinfo/sidrops <https://www.ietf.org/mailman/listinfo/sidrops>
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops