<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix"><font size="4">Hi, Ant:</font></div>
<div class="moz-cite-prefix"><font size="4"><br>
</font></div>
<div class="moz-cite-prefix"><font size="4">1) As I Cc:'ed you, I
attempted to contact the author of the IPv4+ draft a few days
ago to offer my reading of his work. I have not heard any
response. In short, I believe that IPv4+ is paraphrasing the
scheme of the unsuccessful RFC1385 that EzIP Draft cited as
Informative Reference [12]. -- meaning that EzIP has avoided the
trap of such approach.<br>
</font></div>
<div class="moz-cite-prefix"><font size="4"><br>
</font></div>
<div class="moz-cite-prefix"><font size="4">2) I went back to
earlier versions of the IPv4+ drafts and discovered a surprising
trend. That is, through all eight revisions, there has been
hardly any actual write-up text changes! It appears that the
author is just keeping the six-months-timer ticking.</font></div>
<div class="moz-cite-prefix"><font size="4"><br>
</font></div>
<div class="moz-cite-prefix"><font size="4">3) Since you
indicated that IPv4+ was reported to NANOG, maybe you could
retrieve that thread and check with the author about what is the
status?</font></div>
<div class="moz-cite-prefix"><font size="4"><br>
</font></div>
<div class="moz-cite-prefix"><font size="4">4) "Have you
approached any vendors about the feasibility of IP Options being
used for switching at line rate in silicon? ": No. For the
first phase of implementing EzIP, the configuration is called
RAN (Regional Area Network). It is essentially a numbering plan
enhancement to CG-NAT. There is no change to the basic IPv4
Header. The only engineering effort is "disabling the program
code that has been disabling the use of the 240/4 netblock",
followed by retiring the NAT function. So that CG-NAT can
operate as simple routers, by having the </font><font size="4"><font
size="4">look-up state-tables capability as backup</font>.</font></div>
<div class="moz-cite-prefix"><font size="4"><br>
</font></div>
<div class="moz-cite-prefix"><font size="4">5) In the long run,
yes, processing of the Option Word needs be considered and
ideally be implemented in silicon to achieve the line rate
switching. Many claim, however, such end-to-end connectivity is
not needed according to the current trend, which is primarily
Server / Client model by CDN business. So, EzIP is actually a
forward looking two stage scheme. We can focus on the first
phase for now to relieve the underlying issues. There will be
plenty of lead time to upgrade the silicon when the demand for
end-to-end connectivity begins to build up. <br>
</font></div>
<div class="moz-cite-prefix"><font size="4"><br>
</font></div>
<div class="moz-cite-prefix"><font size="4">6) " ... but your
replies are practically illegible because of formatting. ...
": I am still learning the proper eMail etiquette on NANOG.
Could you please echo back some of my writings as you received?
So that I can see what they got transformed to.</font></div>
<div class="moz-cite-prefix"><font size="4"><br>
</font></div>
<div class="moz-cite-prefix"><font size="4">Thanks,</font></div>
<div class="moz-cite-prefix"><font size="4"><br>
</font></div>
<div class="moz-cite-prefix"><font size="4"><br>
</font></div>
<div class="moz-cite-prefix"><font size="4">Abe (2022-04-06 11:25)</font><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 2022-04-03 16:14, Anthony Newman
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:EC856D46-296C-49A2-809D-D7BDAA861635@antiphase.net">
<pre class="moz-quote-pre" wrap="">You should check out <a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/html/draft-tang-ipv4plus-08">https://datatracker.ietf.org/doc/html/draft-tang-ipv4plus-08</a> which is still dragging on
after receiving similar treatment here to EzIP (although less patented by its author) and equally unlikely
to be possible to implement in the real world in a timely fashion.
Have you approached any vendors about the feasibility of IP Options being used for switching at line rate in silicon?
Software IP stacks are the absolute least of your problem when proposing alterations to routing behaviour based on
packet contents. Apologies if this has been covered, but your replies are practically illegible because of formatting.
</pre>
</blockquote>
<p><br>
</p>
<div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br />
<table style="border-top: 1px solid #D3D4DE;">
<tr>
<td style="width: 55px; padding-top: 13px;"><a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon" target="_blank"><img src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif" alt="" width="46" height="29" style="width: 46px; height: 29px;" /></a></td>
<td style="width: 470px; padding-top: 12px; color: #41424e; font-size: 13px; font-family: Arial, Helvetica, sans-serif; line-height: 18px;">Virus-free. <a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link" target="_blank" style="color: #4453ea;">www.avast.com</a>
</td>
</tr>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"> </a></div></body>
</html>