afrinic rpki issue

[Randy Bush]

From: PacketVis 
Date: Sun, 20 Nov 2022 04:30:44 +

Possible TA malfunction or incomplete VRP file: 73.95% of the ROAs disappeared 
from afrinic

See more details about the event:
https://packetvis.com/#/bgp/event/905ec8b7d37e89a2d7b547bca99fd57e-372b0bf3-9056-407e-9e8d-e986567155fc/4f309cb51ba9314fafa64da53d007e342faca613

Re: ipv4/25s and above

[Owen DeLong via NANOG]

>> But see the crux above. If your RiR isnt frowning on such behavior then its 
>> poor strategy to implement it.
> 
> I might have missed the part where RIR's tell me how to operate.

Allow me to help:

https://afrinic.net/ast/pdf/services/afrinic-rsa-en-201801.pdf
afrinic-rsa-en-201801
PDF Document · 128 KB

Specifically, I refer you to sections 2(b), 2(c), 2(d), 4, 6, and 7.

Owen

Re: ipv4/25s and above

[Rubens Kuhl]

On Sat, Nov 19, 2022 at 5:13 PM Douglas Fischer
 wrote:
>
> I do not like mikrotik, but I need to say that RouterOS does support /31.
>
> All that you need to do, beyond set /31 at address for netmask, is check if 
> the other address is defined at the network address.


Is /31 supported only in bleeding-edge versions such as v7 or in the
more conventional RouterOS versions ?


Rubens

Re: ipv4/25s and above

[Bryan Fields]

On 11/19/22 3:12 PM, Douglas Fischer wrote:
> I do not like mikrotik, but I need to say that RouterOS does support /31.
> 
> All that you need to do, beyond set /31 at address for netmask, is check if
> the other address is defined at the network address.

Can you show some docs on this?  I gave a subnet config to my customer of
255.255.255.254 and it wouldn't take it.  I reconfigured it to a /30 (.252)
and it worked for them.  This was a on a RB2011 about 3 months ago.

I search at the time showed it was a know issue.  We laughed about it and
moved on.

-- 
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net

Re: ipv4/25s and above

[Douglas Fischer]

I do not like mikrotik, but I need to say that RouterOS does support /31.

All that you need to do, beyond set /31 at address for netmask, is check if
the other address is defined at the network address.



Em sáb., 19 de nov. de 2022 15:58, Denis Fondras 
escreveu:

> Le Sat, Nov 19, 2022 at 01:39:59PM -0500, Bryan Fields a écrit :
> > On 11/18/22 6:44 AM, Joe Maimon wrote:
> > >> We could, but many of our DIA customers have all manner of CPE's that
> > >> may or may not support this. Having unique designs per customer does
> > >> not scale well.
> > > its almost 2023. /31 support is easily mandatory. You should make it
> > > mandatory.
> >
> > Mikrotik still doesn't support /31 addressing.  I had a customer who was
> > configuring their "router" the other day and we found this out.  Has to
> move
> > to a /30 on the link.
> >
>
> You cannot configure a /31 on a Mikrotik yet you can play with /32 to
> overcome
> this limit.
>

Re: ipv4/25s and above

[Denis Fondras]

Le Sat, Nov 19, 2022 at 01:39:59PM -0500, Bryan Fields a écrit :
> On 11/18/22 6:44 AM, Joe Maimon wrote:
> >> We could, but many of our DIA customers have all manner of CPE's that 
> >> may or may not support this. Having unique designs per customer does 
> >> not scale well.
> > its almost 2023. /31 support is easily mandatory. You should make it 
> > mandatory.
> 
> Mikrotik still doesn't support /31 addressing.  I had a customer who was
> configuring their "router" the other day and we found this out.  Has to move
> to a /30 on the link.
> 

You cannot configure a /31 on a Mikrotik yet you can play with /32 to overcome
this limit.

Re: ipv4/25s and above

[Bryan Fields]

On 11/18/22 6:44 AM, Joe Maimon wrote:
>> We could, but many of our DIA customers have all manner of CPE's that 
>> may or may not support this. Having unique designs per customer does 
>> not scale well.
> its almost 2023. /31 support is easily mandatory. You should make it 
> mandatory.

Mikrotik still doesn't support /31 addressing.  I had a customer who was
configuring their "router" the other day and we found this out.  Has to move
to a /30 on the link.

He's in Africa, and I'm 100% certain Mikrotik is a go to customer router
there.  There's people peering on Mikrotik even!
-- 
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net

ipv4/25s and above

[Sylvain Baya]

Dear NANOG-ers,
Hope this email finds you in good health!
Please see my comments below, inline...
Thanks.

Le samedi 19 novembre 2022, Owen DeLong via NANOG  a
écrit :

> >
> >> Either you have lots of fallow ground or very few customers.
> >
> > A bit of both.
>
> Regarding the former, perhaps you should return some of that to AFRINIC as
> required in your RSA before throwing stones at other providers in the
> region.


>
Hi Owen,
Thanks for your email, brother!

Please, could you elaborate on the above?
Remark! you may need to start a separate thread :-/
...yes! i have already read your next email.

Shalom,
--sb.



> Owen
>
>

-- 

Best Regards !
__
baya.sylvain[AT cmNOG DOT cm]|
Subscribe to Mailing List: 
__
#‎LASAINTEBIBLE‬|#‎Romains15‬:33«Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ soit avec vous
tous! ‪#‎Amen‬!»
‪#‎MaPrière‬ est que tu naisses de nouveau. #Chrétiennement‬
«Comme une biche soupire après des courants d’eau, ainsi mon âme soupire
après TOI, ô DIEU!»(#Psaumes42:2)

Re: Alternative Re: ipv4/25s and above

[Mark Tinka]

On 11/19/22 05:50, Abraham Y. Chen wrote:


Dear Owen:

1) "... Africa ... They don’t really have a lot of alternatives. ...": 
Actually, there is, simple and in plain sight. Please have a look at 
the below IETF Draft:


It's most amusing, to me, how Africa needs to be told how to be...

Some folk just can't help themselves.

Mark.

Re: ipv4/25s and above

[Mark Tinka]

On 11/18/22 13:44, Joe Maimon wrote:



its almost 2023. /31 support is easily mandatory. You should make it 
mandatory.


I don't make the gear.


How many customer addressing designs does that total, 2? So that would 
be 1 more than you have already? Dont buy it.


That's fine.




Its 2023, your folk should be able to handle addressing more advanced 
than from the 90s.


Customers will do what they do.



And your betting the future on IPv6?


Actually, yeah.


The only issue with it is traceroute although that isnt necessarily a 
problem.


We and some of our customers find that useful.




And the CPE sourced traffic should either be all internal or sourced 
from the loopback.


It's not my CPE, I don't get to make the rules.




OTOH CoPP protection becomes a lot easier when fewer of the CP 
addressing is globally routed.


As does not connecting any cables to the device.

Seriously, all good points. We just have more pressing issues to deal with.


Truth is the real issue isnt CPE support, its user support. Most 
users(even their "IT" folk) really cant wrap their brain around more 
than the bare basic concepts, if that much.


And you can simply say, IPv4 is limited, this is the base model 
addressing included with the service, if your inabilities are 
preventing you from using networking techniques that have been 
standardized and usable for decades, then feel free to pony up for 
either for your comfort level or for support of your inabilities.


Okay.


This is the crux. So long as you can obtain more, justifiable 
consumption is rewarded with additional resources, dis-incentivizing 
any addressing efficiency progress from the ancient /30 p2p + /29(or 
larger) routed block.


You may wish to lay groundwork to nibble backwards when runout occurs 
for you.


Its on Afrinic to try and preserve their pool if they wish to by doing 
things such as getting it across that progress in addressing 
efficiency is an important consideration in fulfilling requests for 
additional resources.


We aren't really going to expend too many resources on trying to delay 
the use of IPv6. I understand that I am speaking from a place of 
priviledge, having as much IPv4 as we do, but even then, we will connect 
as many as we connect using either "efficient" or "inefficient" 
techniques, and neither will prevent run-out, eventually.


We want to be able to keep servicing customers, long after we are gone. 
That is what we care about.





If they need more, they pay more and they get more. Most of the rest 
of the world is operating or moving to operate in that fashion.


It's fine for most of the world to do what it wants. I won't begrudge 
them that. Over here, we will do what we feel works for us.





You would still require them to submit a formal request documenting 
their need. And paying more is likely to mean that its a more honest 
request.


We do this already, only without asking them for cash.




But see the crux above. If your RiR isnt frowning on such behavior 
then its poor strategy to implement it.


I might have missed the part where RIR's tell me how to operate.




Although, if you can get away with it, allocating the /30 + /29 and 
implementing it in an easy-to-clawback approach might be a good strategy.


There is reasonable customer movement between competitors that address 
space comes and goes.



Thats a question of internal discipline without motivating external 
factors. Odds are those factors will arrive and I would advise 
preparedness for them.


Have you ever been in sales :-)?

Mark.