[lacnog] IP Privadas en sesiones PNI y número de IP para CDN

[Alejandro Guzman]

Además de lo que menciona Arturo, creo que es importante anotar que la
cantidad de IPs no depende de lo "conservador" que sea el proveedor de
caches. Depende de la cantidad de máquinas que forma el nodo y de la
multiplexación máxima de requests que se pueden manejar por IP según la
cantidad, el tipo de servicios y aplicaciones y contenidos que se sirven de
los caches. Si no se ha reducido más el requerimiento no es por falta de
que se anime a los CDNs a hacerlo, ya se ha reducido al mínimo actualmente
posible.

Saludos


Alejandro

El lun., 30 mar. 2020 a las 12:59, Arturo Servin (<arturo.servin en gmail.com>)
escribió:

>
> IPv6 y el bloque de IPv4 necesario pasa de un /26 a cero.
>
>
> Saludos
>
> On Mon, 30 Mar 2020, 19:05 Fernando Frediani, <fhfrediani en gmail.com>
> wrote:
>
>> Gracias Tomas.
>> Tienes razón en la forma en que lo expresas. Posible es que no hay
>> problemas técnicos, pero puede haber un problema operativo y de retraso.
>> También he visto casos de uso para otros prefijos fuera de RFC1918, pero
>> creo que en este caso el problema de encontrar uno que no entre en
>> conflicto es el mismo.
>>
>> Creo que el mayor problema sigue siendo los bloques muy grandes que
>> algunos CDN solicitan al ISP. En tiempos de escasez, necesitan ajustar sus
>> políticas para adaptarse a esta realidad y hacer un mejor uso de estos
>> recursos y trabajar con /30 y /31 tanto como sea posible.
>>
>> Saludos
>> Fernando
>> On 30/03/2020 11:35, Tomas Lynch wrote:
>>
>> On Sat, Mar 28, 2020 at 3:29 PM Fernando Frediani <fhfrediani en gmail.com>
>> wrote:
>>
>>> Estimados colegas
>>>
>>> Me gustaría consultar a todos para conocer el punto de vista sobre un
>>> tema que parece estar cada vez más en discusión debido a la escasez de
>>> direcciones IPv4.
>>>
>>>
>> <snip>
>>
>> La otra pregunta que me gustaría hacer es sobre los PNI. ¿Alguien ve,
>>> desde un punto de vista técnico, algún impedimento para usar direcciones
>>> privadas en estos P2P?
>>>
>>>
>> El viejo problema de unir dos redes que utilizan direccionamiento
>> RFC1918. Peer A utiliza 10.1.0.0/16 para peerings, Peer B utiliza ese
>> mismo bloque para la red de monitoreo out-of-bound de sus equipos. Peer B
>> no puede usar ese bloque para peering, Peer A le pide entonces otro bloque,
>> Peer B le dice que usen 192.168.0.0/16 pero Peer A ya lo utiliza para
>> sus peerings en Europa, etc.
>>
>> En algún momento se van a poner de acuerdo pero va a retrasar el peering,
>> cada PNI sería un caso único, la documentación sería única, etc. Ni hablar
>> si hay scripts auditando configuraciones, estos deberían contemplar estas
>> excepciones también. Es decir, se puede, pero hay que tener otras
>> consideraciones.
>>
>>
>>
>>> Se puede decir que estamos hablando de unos pocos /30, pero creo que
>>> incluso para un ISP de tamaño mediano, varios PNI y CDN terminan
>>> consumiendo IPv4 públicos que podría utilizarse mejor para otros usos
>>> sin ninguna pérdida de calidad en la conexión, si solo cuente con la
>>> comprensión de ambos lados.
>>>
>>> Que piensas ?
>>>
>>> Fernando
>>>
>>> _______________________________________________
>>> LACNOG mailing list
>>> LACNOG en lacnic.net
>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>>
>>
>> _______________________________________________
>> LACNOG mailing listLACNOG en lacnic.nethttps://mail.lacnic.net/mailman/listinfo/lacnog
>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>
>> _______________________________________________
>> LACNOG mailing list
>> LACNOG en lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lacnog
>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20200330/898a23d9/attachment-0001.html>