[lacnog] Making Use of 240/4 NetBlock Re 202203170904.AYC
Abraham Y. Chen
aychen en avinta.com
Jue Mar 17 11:30:09 -03 2022
Hi, Tomas:
1) Re: Ur. Pt. 1) " ... the question is if we need 204/4 or not....
": I am afraid that you are putting the wagon in front of the horse.
For discussing a serious topic, we need to apply the "Divide and
Conquer" strategy. That is, we should make sure that all technical
aspects are fully understood by all parties involved, first. Then, the
choice of "yes or no" will have a clear and solid base. Otherwise, more
vague parameters, such as business strategies, vested business
interests, personal feelings, etc. will come into play. Decisions made
in the latter manner will lead to long term second-thoughts, such as
more than a couple Internet issues that have been keeping everyone busy
in the recent years.
2) Re: Ur. Pt. 2) " ... Looks like your personal preference is that
deploying IPv6 requires too much of an effort, ... ": Following the
above principle, I personally had no preconceived notion about IPv6 when
we started the EzIP Project. Initially, we were just curious about why
IPv4 address pool could be depleted so quickly. Upon figured out a way
to expand it by utilizing the third octet of 192.168.k/24, we started to
question the wisdom of trading IP addresses as */personal property/*,
instead of regarding it as a */natural resources/*. After discovered the
possibility of making use of 240/4 netblock to create an IPv4 based
address pool in the same of order of magnitude as IPv6, we began to
study what IPv6 really was and what were its merits. Before we dug into
such, the limited IPv6 traffic volume data, while serious efforts to
promote it persisted, alerted us to look for behind-the-scene stories.
At this moment, I am still not expressing any opinion about how to treat
IPv6. I am only conveying a potential game-changer approach to mitigate
the daily reported Internet issues.
3) "... Would you please please receive all the list emails instead
of the digest so it's easier to follow the thread? ... ": I
presume that you would like me to keep all the past exchanges in this
thread for you to look back? This is an interesting logistic issue.
eMail provides the facility of keeping all the old dialog in a long
thread for convenience. However, two extremes of behaviors follow. One
is keeping the tail forever, even after the discussion thread has
drifted far off the original topic. The other is responding like in a
live conversation, i.e., without any of the preceding messages, yet
without any brief reciting of the topic as in a traditional business
correspondence. Personally, I review and trim off the tail regularly to
avoid it growing too long. For the LACNOG discussion, because the daily
summary has its own serial numbering system for trace back, I believe
reciting the last incoming message would be suffice. I do include it at
the beginning of it the serial numbers for trace back if needed. My hope
is that this format will keep each message compact, yet the continuity
of the thread is maintained. If you like to see the entire old thread
every time, I will do so for your convenience. This is an optimization
process. Please give me your feedback for me to improve. Thanks.
Regards,
Abe (2022-03-17 10:28)
------------------------------
Resumen de LACNOG, Vol 171, Envío 16
Message: 3 Date: Thu, 17 Mar 2022 00:14:43 -0400 From: Tomas Lynch
<tomas.lynch en gmail.com> To: "Abraham Y. Chen" <aychen en avinta.com> Cc:
Latin America and Caribbean Region Network Operators Group
<lacnog en lacnic.net>, "Chen, Abraham Y." <AYChen en alum.mit.edu> Subject:
Re: [lacnog] Making Use of 240/4 NetBlock Re 202203162312.AYC
Message-ID:
<CAGEujU91wGoWgF2Dpfc-DvjA0yRWfoyr-kkAnn6Su2oWtvxV+A en mail.gmail.com>
Content-Type: text/plain; charset="utf-8" On Wed, Mar 16, 2022 at 11:25
PM Abraham Y. Chen <aychen en avinta.com> wrote:
> Hi, Tomas:
>
> 1) " If you are in operations everything is a burden. ": Of course,
> there is no free lunch. The question is, whether the proposed work delivers
> better performance or reduces the current, and perhaps including future,
> burdens?
>
No, the question is if we need 204/4 or not. My opinion is no for the
motives I explained in other emails.
> 2) " ... I'd rather spend my time deploying IPv6 ... ": This
> thread of exchanges is about discussing the technical merits of the EzIP
> scheme. It is not conducting a popularity polling of personal preferences
> which can be influenced by too many none-technical parameters.
>
I'm just answering your statement that says "Although this is not without
efforts, it would be finite compared to the IPv6 deployment...". Looks like
your personal preference is that deploying IPv6 requires too much of an
effort, mine is the opposite. But let's keep it on 204/4.
> Regards,
>
>
> Abe (2022-03-16 23:25)
>
Would you please please receive all the list emails instead of the digest
so it's easier to follow the thread? Answering on the daily summary is not
effective to follow your answers. Thanks.
> On 2022-03-16 19:52, Tomas Lynch wrote:
>
> If you are in operations everything is a burden. I'd rather spend my time
> deploying IPv6 than upgrading code in routers.
>
> On Sun, Mar 13, 2022 at 11:14 PM Abraham Y. Chen<aychen en avinta.com>
> wrote:
>
>> Hi, Tomas:
>> 1) " ... would have to plan the upgrade of all of our routers, spend
>> days programming the upgrade, spend nights in maintenance windows, maybe
>> pay for remote hands, etc. ...
>> the cost of the so-called EzIP is not minimal.": Perhaps you did not
>> recognize three characteristics of the EzIP scheme in this respect:
>>
>> A. It is an incremental enhancement (more addresses become
>> usable). It does not require end-user upgrade. So, it does not interfere
>> existing operations,
>>
>> B. It is localized within a RAN (Regional Area Network), or a
>> partial branch of such, and generally deploys down-stream. So, it should be
>> within one Network Operator's sole jurisdiction,
>> C. It is a "generic" type of software upgrade. That is, all
>> equipment from manufacturers using the same root software block are likely
>> making the same code change.
>>
>> As such, the software update for EzIP operation may be done as part
>> of periodical debugging type of down-loads, not extra burden on
>> operator's staff. Then, the added capability can be idle in the updated
>> equipment until down stream facility is ready to take advantage of the
>> expanded capability. From my knowledge of equipment maintenance, this is no
>> big deal. Although this is not without efforts, it would be finite compared
>> to the IPv6 deployment that requires wide spread compatibility through the
>> Internet (cooperation of both ends of a link), before the roll-out of the
>> capability is feasible.
>>
>> Hope this clarifies your concern.
>>
>>
>> Regards,
>>
>>
>> Abe (2022-03 13 23:13 EDT)
>>
>>
>> ----------------------------------------------------------------------
>> Resumen de LACNOG, Vol 171, Envío 10
>> Message: 1
>> Date: Sat, 12 Mar 2022 10:34:35 -0500
>> From: Tomas Lynch<tomas.lynch en gmail.com> <tomas.lynch en gmail.com>
>> To: Latin America and Caribbean Region Network Operators Group
>> <lacnog en lacnic.net> <lacnog en lacnic.net>
>> Subject: Re: [lacnog] Making Use of 240/4 NetBlock Re:
>> 202203112350.AYC
>> Message-ID:
>> <CAGEujU8MwZx7-PzmKHpyOWjDj9gUSRa6aGsOwB_XVEB86yOd6w en mail.gmail.com> <CAGEujU8MwZx7-PzmKHpyOWjDj9gUSRa6aGsOwB_XVEB86yOd6w en mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> This part of the proposal doesn't have in mind the operations of a network:
>>
>>
>> A. Disable the program codes in current routers that have been
>>
>> disabling the use of the 240/4 NetBlock. The cost of this software
>> engineering should be minimal.
>>
>> Yes, let's say that the cost for Vendor A could be minimal: they will
>> remove some lines in the code for version X.Y and release version X.Y-EzIP
>> without bugs triggered by removing those lines. Then, we, the operators,
>> would have to plan the upgrade of all of our routers, spend days
>> programming the upgrade, spend nights in maintenance windows, maybe pay for
>> remote hands, etc., just to extend for a few more days the inevitable agony
>> of IPv4.
>>
>> Thus, the cost of the so-called EzIP is not minimal.
>>
>>
>>
>>
>>
>>
>>
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon> Virus-free.
>> www.avast.com
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link>
>> <#m_-7466899796481095408_m_5374399823432330978_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL:<https://mail.lacnic.net/pipermail/lacnog/attachments/20220317/3fc379b6/attachment.htm>
------------------------------
Subject: Pié de página del digest
_______________________________________________
LACNOG mailing list
LACNOG en lacnic.net
https://mail.lacnic.net/mailman/listinfo/lacnog
Cancelar suscripcion:lacnog-unsubscribe en lacnic.net
------------------------------
Fin de Resumen de LACNOG, Vol 171, Envío 16
*******************************************
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20220317/9abc4258/attachment-0001.htm>
Más información sobre la lista de distribución LACNOG