Alternative Re: ipv4/25s and above Re: 202211232221.AYC

Sat Nov 26 21:34:00 UTC 2022

Hi, Douglas:

0) Thanks for the feedback.

1)  I do not sort eMail with any tools. Other than important ones that 
do I save a copy off the system as a document for long term reference, I 
only flag those of substance for the keeps and allow the rest to 
"expire" (I do house cleaning every three months or so.). Consequently, 
I have no idea about the terminologies that you mentioned.

2)  My basic understanding is, an eMail in its entirety is the original 
work of its composer / writer / sender. As such, a receiver is free to 
do anything with it, but not to impose certain "rules" back onto the 
writing. Through the years, eMail writing styles have diversified from 
the business letter protocols that I knew so much that I had to develop 
my own conventions of writing that enabled me to organize my eMails for 
retrieval. They seem to be tolerated by most parties that communicated 
with except NANOG. If you have certain clear rules that can pass my 
"logistics" considerations, I will definitely learn and follow.

Regards,

Abe (2022-11-24 16:00 EST)

On 2022-11-24 06:51, Douglas Fischer wrote:
> Hello Abraham!
>
> I believe your e-mail client (MUA) is splitting every message on a new 
> thread.
> I'm not sure if it is happening with everyone, but using Gmail as MUA, 
> it isn't aggregating the mails on the same thread.
>
> Cloud you please check the confs of your tool to avoid it?
>
> Thanks in advance.
>
> Em qui., 24 de nov. de 2022 às 05:56, Abraham Y. Chen 
> <aychen at avinta.com> escreveu:
>
>     Dear Joe:
>
>     0) Allow me to share my understanding of the two topics that you
>     brought up.
>
>     1) "... https://www.google.com/intl/en/ipv6/statistics.html, it looks
>     like we’ve gone from ~0% to ~40% in 12 years.... ":  Your numbers
>     may be
>     deceiving.
>
>        A. The IPv6 was introduced in 1995-12, launched on 2012-06-06 and
>     ratified on 2017-07-14. So, the IPv6 efforts have been quite a few
>     years
>     more than your impression. That is, the IPv6 has been around over
>     quarter of a century.
>
>        B. If you read closely, the statement  "The graph shows the
>     percentage of users that access Google over IPv6." above the graph
>     actually means "equipment readiness". That is, how many Google users
>     have IPv6 capable devices. This is similar as the APNIC statistics
>     whose
>     title makes this clearer. However, having the capability does not
>     mean
>     the owners are actually using it. Also, this is not general data, but
>     within the Google environment. Since Google is one of the stronger
>     promoters of the IPv6, this graph would be at best the cap of such
>     data.
>
>        C. The more meaningful data would be the global IPv6 traffic
>     statistics. Interestingly, they do not exist upon our extensive
>     search.
>     (If you know of any, I would appreciate to receive a lead to
>     such.) The
>     closest that we could find is % of IPv6 in AMS-IX traffic statistics
>     (see URL below). It is currently at about 5-6% and has been
>     tapering off
>     to a growth of less than 0.1% per month recently, after a ramp-up
>     period
>     in the past. (Similar saturation behavior can also be found in the
>     above
>     Google graph.)
>
>     https://stats.ams-ix.net/sflow/ether_type.html
>
>        D.  One interesting parameter behind the last one is that as an
>     Inter-eXchange operator, AMS-IX should see very similar percentage
>     traffic mix between IPv6 and IPv4. The low numbers from AMS-IX
>     does not
>     support this viewpoint for matching with your observation. In
>     addition,
>     traffic through IX is the overflow among backbone routers. A couple
>     years ago, there was a report that peering arrangements among
>     backbone
>     routers for IPv6 were much less matured then IPv4, which meant that
>     AMS-IX should be getting more IPv6 traffic than the mix in the
>     Internet
>     core. Interpreted in reverse, % of IPv6 in overall Internet traffic
>     should be less than what AMS-IX handles.
>
>        E. This is a quite convoluted topic that we only scratched the
>     surface. They should not occupy the attention of colleagues on this
>     list. However, I am willing to provide more information to you
>     off-line,
>     if you care for further discussion.
>
>     2)  "...
>     https://lore.kernel.org/lkml/[email protected]/
>     ...":  My basic training was in communication equipment hardware
>     design.
>     I knew little about software beyond what I needed for my primary
>     assignment. Your example, however, reminds me of a programing course
>     that I took utilizing APL (A Programming Language) for circuit
>     analysis,
>     optimization and synthesis. It was such a cryptic symbolic
>     language that
>     classmates (mostly majored in EE hardware) were murmuring to express
>     their displeasure. One day we got a homework assignment to do
>     something
>     relatively simple. Everyone struggled to write the code to do the
>     job.
>     Although most of us did get working codes, they were pages long. The
>     shortest one was one full page. Upon reviewed all homework, the
>     professor smiled at us and told us to look for the solution
>     section at
>     the end of the text book. It turned out to be the answer for a
>     problem
>     in the next chapter to be covered. The code was only three lines
>     long!
>     Although it did not have the codes for debugging purposes, it covered
>     all error messages expected. It was such a shocker that everyone
>     quieted
>     down to focus on the subject for the rest of the semester. During my
>     first employment, we had the need to optimize circuit designs.
>     Since I
>     was the only staff who knew about it, I ended up being the
>     coordinator
>     between several hardware designers and the supporting programmer.
>     From
>     that teaching, I am always looking for the most concise solution
>     to an
>     issue, not being distracted or discouraged by the manifestation on
>     the
>     surface.
>
>     https://en.wikipedia.org/wiki/APL_(programming_language)
>
>     3) Fast forward half a century, I am hoping that my "one-line code"
>     serves the purpose of "there exists" an example in proofing a
>     mathematical theorem for  inspiring software colleagues to review the
>     network codes in front of them for improvement, instead of presenting
>     such as a valid hurdle to progress.
>
>
>     Regards,
>
>
>     Abe (2022-11-24 03:53 EST)
>
>
>
>
>
>     On 2022-11-21 19:30, Joe Maimon wrote:
>     >
>     >
>     > David Conrad wrote:
>     >> Barry,
>     >>
>     >> On Nov 21, 2022, at 3:01 PM, bzs at theworld.com wrote:
>     >>> We've been trying to get people to adopt IPv6 widely for 30 years
>     >>> with very limited success
>     >>
>     >> According to
>     https://www.google.com/intl/en/ipv6/statistics.html, it
>     >> looks like we’ve gone from ~0% to ~40% in 12 years.
>     >> https://stats.labs.apnic.net/ipv6 has it around 30%. Given an
>     >> Internet population of about 5B, this can (simplistically and
>     >> wrongly) argued to mean 1.5-2B people are using IPv6. For a
>     >> transition to a technology that the vast majority of people who
>     pay
>     >> the bills will neither notice nor care about, and for which the
>     >> business case typically needs projection way past the normal
>     >> quarterly focus of shareholders, that seems pretty successful
>     to me.
>     >>
>     >> But back to the latest proposal to rearrange deck chairs on the
>     IPv4
>     >> Titanic, the fundamental and obvious flaw is the assertion of
>     >> "commenting out one line code”. There isn’t “one line of code”.
>     There
>     >> are literally _billions_ of instances of “one line of code”,
>     the vast
>     >> majority of which need to be changed/deployed/tested with
>     absolutely
>     >> no business case to do so that isn’t better met with deploying
>     >> IPv6+IPv4aaS. I believe this has been pointed out numerous
>     times, but
>     >> it falls on deaf ears, so the discussion gets a bit tedious.
>     >>
>     >> Regards,
>     >> -drc
>     >>
>     > Had the titanic stayed afloat some hours more, many more would have
>     > survived and been rescued when assistance eventually arrived. So
>     that
>     > makes this a debate over whether this is deck chair
>     re-arrangement or
>     > something more meaningful.
>     >
>     > As I and others have pointed out, it depends on how it is used. And
>     > perhaps the attempt should be made regardless of knowing in advance
>     > which it will be.
>     >
>     > You assertion needs some back of the envelope numbers, which once
>     > provided, I suspect will render your estimate grossly incorrect.
>     >
>     > You can hardly attempt to convince anybody that 240/4 as unicast
>     would
>     > not be the more trivial change made in any of these products
>     natural
>     > life cycle points.
>     >
>     > Especially as we have examples of what that type of effort might
>     look
>     > like. IGTFY and here
>     >
>     > https://lore.kernel.org/lkml/[email protected]/
>     >
>     > The burdensome position is ridiculous even more so when stated
>     with a
>     > straight face.
>     >
>     > Joe
>     >
>     >
>     >
>
>
>     -- 
>     This email has been checked for viruses by Avast antivirus software.
>     www.avast.com <http://www.avast.com>
>
>
>
> -- 
> Douglas Fernando Fischer
> Engº de Controle e Automação