Hi, Tom:
1) " .... better to have that conversation via the appropriate IETF
channels. ": Thanks for the recommendation. I would appreciate very much
if you could guide us to the specific contact. Before we attempt to do
so, however, it would be prudent to report the history of our team's
experience:
A. The first IETF Draft on EzIP Project started from 2016-12 as
instructed by the ISE (Independent Submission Editor). Although, at that
time Working Group SunSet4 had been in session for awhile. But, we were
not aware of, nor being informed about such.
B. In Summer of 2018, we discovered that SunSet4 had Concluded.
We contacted the person in charge of keeping an eye on possible future
IPv4 activities, but did not receive any instruction to revise our course.
C. Recently, we were made aware of the Int-Area activities.
Attempts to reach the Group Chairs have not received any responses.
D. I just received an Int-Area Digest Vol 199, Issue 14
requesting IETF to reactivate the IPv4 support.
Hope you can help us to close the loose ends.
2) In the meantime, we realized that the simplest implementation of
the EzIP proposal is to replace the 100.64/10 netblock used by CG-NAT
with the 240/4 netblock. Next, taking advantage of the much larger
address pool to begin practicing static address assignment related
disciplines, a "packetized PSTN" is realized. From such a base, the EzIP
powered CG-NAT behaving as an overlay network in parallel to the
existing Internet for providing the same services, many of the drawbacks
in the latter are mitigated! So, we decided to discuss the EzIP proposal
directly with the NANOG colleagues, because the EzIP deployment can
actually be rather stealthy.
I look forward to your thoughts.
Regards,
Abe (2022-03-15 16:26)
On 2022-03-14 14:48, Tom Beecher wrote:
If you want to garner discussion or support for your draft RFC, it's
probably better to have that conversation via the appropriate IETF
channels.
On Mon, Mar 14, 2022 at 2:43 PM Abraham Y. Chen <ayc...@avinta.com> wrote:
Hi, Fred:
0) Thank you for a set of references.
1) We cited only one IETF Draft (Wilson, et al.) among them,
because it was the first and only one that clearly stated its
limitation (Section 2. Caveats of Use). More importantly, it was
written by three top APNIC officials. Later efforts on this topic
have not introduced (based on my reading) any more essence to the
topic.
2) "... I was there for those discussions, and I'm not sure
how to put it more simply.... ": With your knowledge of the
past, you are uniquely qualified to critique on our work. However,
it would be more expedient for everyone, if you could first read
through at least the Abstract and the Conclusions of the EzIP IETF
Draft, before commenting. This is because EzIP proposal is based
on the same general idea as the references you cited, but with a
slight extra step that produced a series of surprising results. In
particular, we took the "Caveats" above to our hearts before
proceeding. So, please put such issues behind you while reviewing
our work. Thanks,
Regards,
Abe (2022-03-14 14:39)
------------------------------ NANOG Digest, Vol 170, Issue 15
Message: 17 Date: Sun, 13 Mar 2022 21:26:11 -0700 From: Fred Baker
<fredbaker.i...@gmail.com> <mailto:fredbaker.i...@gmail.com> To:
"Abraham Y. Chen" <ayc...@avinta.com> <mailto:ayc...@avinta.com>,
William Herrin <b...@herrin.us> <mailto:b...@herrin.us> Cc: NANOG
<nanog@nanog.org> <mailto:nanog@nanog.org> Subject: Re:
202203071610.AYC Re: Making Use of 240/4 NetBlock Message-ID:
<79746dec-8c8b-4d6d-b1d6-cb0a0003a...@gmail.com>
<mailto:79746dec-8c8b-4d6d-b1d6-cb0a0003a...@gmail.com>
Content-Type: text/plain; charset=us-ascii On Mar 12, 2022, at
8:15 AM, Abraham Y. Chen <ayc...@avinta.com>
<mailto:ayc...@avinta.com> wrote:
2) On the other hand, there was a recent APNIC blog that specifically
reminded us of a fairly formal request for re-designating the 240/4 netblock
back in 2008 (second grey background box). To me, this means whether to change
the 240/4 status is not an issue. The question is whether we can identify an
application that can maximize its impact.
https://blog.apnic.net/2022/01/19/ip-addressing-in-2021/
I think there might be value in reviewing the discussion of the related
Internet Drafts
https://datatracker.ietf.org/doc/html/draft-deshpande-intarea-ipaddress-reclassification-03
https://mailarchive.ietf.org/arch/search/?q=draft-deshpande-intarea-ipaddress-reclassification
https://datatracker.ietf.org/doc/html/draft-wilson-class-e-02
https://mailarchive.ietf.org/arch/search/?q=draft-wilson-class-e
https://datatracker.ietf.org/doc/html/draft-fuller-240space-02
https://mailarchive.ietf.org/arch/search/?q=draft-fuller-240space
The walkaway I had from these discussions was that while changing the
definition of the address space would allow RIRs to sell more IPv4 address
space for a few weeks (such as happened to APNIC when the last /8's were handed
out), there were not enough addresses in the identified pools to solve the
address shortage. So it was in the end a fool's errand. If you want to have
address space to address the current shortage, you need an addressing
architecture with more addresses.
I was there for those discussions, and I'm not sure how to put it more
simply.
------------------------------
<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_-3820859315811704609_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
