<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p><font size="4">Hi, Tomas:</font></p>
<p><font size="4">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.<br>
</font> </p>
<font size="4"> </font>
<p><font size="4">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 <b><i>personal
property</i></b>, instead of regarding it as a <b><i>natural
resources</i></b>. 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. <br>
</font></p>
<p><font size="4">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.</font></p>
<p><font size="4">Regards,</font></p>
<p><font size="4"><br>
</font></p>
<p><font size="4">Abe (2022-03-17 10:28) <br>
</font></p>
<p><font size="4"></font><br>
</p>
<pre class="moz-quote-pre" wrap=""><div class="moz-txt-sig">------------------------------</div><div class="moz-txt-sig">
Resumen de LACNOG, Vol 171, Envío 16</div><div class="moz-txt-sig">
Message: 3
Date: Thu, 17 Mar 2022 00:14:43 -0400
From: Tomas Lynch <a class="moz-txt-link-rfc2396E" href="mailto:tomas.lynch@gmail.com"><tomas.lynch@gmail.com></a>
To: "Abraham Y. Chen" <a class="moz-txt-link-rfc2396E" href="mailto:aychen@avinta.com"><aychen@avinta.com></a>
Cc: Latin America and Caribbean Region Network Operators Group
<a class="moz-txt-link-rfc2396E" href="mailto:lacnog@lacnic.net"><lacnog@lacnic.net></a>, "Chen, Abraham Y." <a class="moz-txt-link-rfc2396E" href="mailto:AYChen@alum.mit.edu"><AYChen@alum.mit.edu></a>
Subject: Re: [lacnog] Making Use of 240/4 NetBlock Re 202203162312.AYC
Message-ID:
<a class="moz-txt-link-rfc2396E" href="mailto:CAGEujU91wGoWgF2Dpfc-DvjA0yRWfoyr-kkAnn6Su2oWtvxV+A@mail.gmail.com"><CAGEujU91wGoWgF2Dpfc-DvjA0yRWfoyr-kkAnn6Su2oWtvxV+A@mail.gmail.com></a>
Content-Type: text/plain; charset="utf-8"
On Wed, Mar 16, 2022 at 11:25 PM Abraham Y. Chen <a class="moz-txt-link-rfc2396E" href="mailto:aychen@avinta.com"><aychen@avinta.com></a> wrote:
</div></pre>
<blockquote type="cite" style="color: #007cff;">
<pre class="moz-quote-pre" wrap="">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?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">No, the question is if we need 204/4 or not. My opinion is no for the
motives I explained in other emails.
</pre>
<blockquote type="cite" style="color: #007cff;">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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.
</pre>
<blockquote type="cite" style="color: #007cff;">
<pre class="moz-quote-pre" wrap="">Regards,
Abe (2022-03-16 23:25)
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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.
</pre>
<blockquote type="cite" style="color: #007cff;">
<pre class="moz-quote-pre" wrap="">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 <a class="moz-txt-link-rfc2396E" href="mailto:aychen@avinta.com"><aychen@avinta.com></a>
wrote:
</pre>
<blockquote type="cite" style="color: #007cff;">
<pre class="moz-quote-pre" wrap="">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 <a class="moz-txt-link-rfc2396E" href="mailto:tomas.lynch@gmail.com"><tomas.lynch@gmail.com></a> <a class="moz-txt-link-rfc2396E" href="mailto:tomas.lynch@gmail.com"><tomas.lynch@gmail.com></a>
To: Latin America and Caribbean Region Network Operators Group
<a class="moz-txt-link-rfc2396E" href="mailto:lacnog@lacnic.net"><lacnog@lacnic.net></a> <a class="moz-txt-link-rfc2396E" href="mailto:lacnog@lacnic.net"><lacnog@lacnic.net></a>
Subject: Re: [lacnog] Making Use of 240/4 NetBlock Re:
202203112350.AYC
Message-ID:
<a class="moz-txt-link-rfc2396E" href="mailto:CAGEujU8MwZx7-PzmKHpyOWjDj9gUSRa6aGsOwB_XVEB86yOd6w@mail.gmail.com"><CAGEujU8MwZx7-PzmKHpyOWjDj9gUSRa6aGsOwB_XVEB86yOd6w@mail.gmail.com></a> <a class="moz-txt-link-rfc2396E" href="mailto:CAGEujU8MwZx7-PzmKHpyOWjDj9gUSRa6aGsOwB_XVEB86yOd6w@mail.gmail.com"><CAGEujU8MwZx7-PzmKHpyOWjDj9gUSRa6aGsOwB_XVEB86yOd6w@mail.gmail.com></a>
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.
<a class="moz-txt-link-rfc2396E" href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon"><https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon></a> Virus-free.
<a class="moz-txt-link-abbreviated" href="http://www.avast.com">www.avast.com</a>
<a class="moz-txt-link-rfc2396E" href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link"><https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link></a>
<#m_-7466899796481095408_m_5374399823432330978_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <a class="moz-txt-link-rfc2396E" href="https://mail.lacnic.net/pipermail/lacnog/attachments/20220317/3fc379b6/attachment.htm"><https://mail.lacnic.net/pipermail/lacnog/attachments/20220317/3fc379b6/attachment.htm></a>
------------------------------
Subject: Pié de página del digest
_______________________________________________
LACNOG mailing list
<a class="moz-txt-link-abbreviated moz-txt-link-freetext" href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a>
<a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a>
Cancelar suscripcion: <a class="moz-txt-link-abbreviated moz-txt-link-freetext" href="mailto:lacnog-unsubscribe@lacnic.net">lacnog-unsubscribe@lacnic.net</a>
------------------------------
Fin de Resumen de LACNOG, Vol 171, Envío 16
*******************************************
</pre>
</body>
</html>