Dear all,

I've yet to make up my mind about this proposal, but I wanted to point
out an error in the interpretation of how RPKI based BGP Origin
Validation works.

On Wed, Aug 28, 2019 at 04:04:25PM -0700, Owen DeLong wrote:
> > On Aug 28, 2019, at 13:44 , Aftab Siddiqui <> wrote:
> > On Thu, 29 Aug 2019 at 6:33 am, Javed Khan < 
> > <>> wrote:
> > We may think we are living in a perfect world but we are not.
> > 
> > of course 
> > 
> > With this proposal I'm more worried about the network downtime as
> > managing an AS0 ROA by an RIR may be prone to errors as we all do
> > regardless if its a manual or automated solution.
> > 
> > Would you like to explain how AS0 ROA can create network downtime? 
> One possible way I can think of (I’m sure there are others)…
> ISP Q is issued 2001:db8::/32 by APNIC.
> ISP Q does not participate in RPKI and does not create ROAs.
> APNIC accidentally issues an incorrect AS 0 ROA for
> 2001:db8:8000::/33, taking down some fraction (up to half) of ISP Q’s
> customers and possibly their infrastructure.


In the above example, if ISP Q announces 2001:db8::/32 in the BGP
Default-Free Zone, the presence (or absense) of a ROA covering only
2001:db8:8000::/33 (or longer) will not influence the propagation of the

Should APNIC create a ROA "2001:db8:8000::/33, maxlength 128, origin AS
0" this ROA will *not* take down some fraction of ISP Q's customers. A
ROA covering only a *fraction* of a covering "VALID" or "UNKNOWN" BGP
announcement does not influence said covering BGP route.

Now, it's of course another story if APNIC creates an AS 0 ROA for
2001:db8::/32, or if ISP Q wants to announce 2001:db8:8000::/33 for
traffic-engineering reasons.

ROAs only influence BGP announcements where the NLRI in the BGP UPDATE
is an exact match, or where the BGP NLRI is a more-specific of the ROA.
Not the other way around.

Kind regards,

*              sig-policy:  APNIC SIG on resource management policy           *
sig-policy mailing list

Reply via email to