Hi, Pascal:
1) " ... for the next version. ... ": I am not sure that I can
wait for so long, because I am asking for the basics. The reason that I
asked for an IP packet header example of your proposal is to visualize
what do you mean by the model of "realms and shafts in a multi-level
building". The presentation in the draft sounds okay, because the
floors are physically isolated from one another. And, even the building
is isolated from other buildings. This is pretty much how PBX numbering
plan worked.
2) When you extend each floor to use the whole IPv4 address pool,
however, you are essential talking about covering the entire surface of
the earth. Then, there is no isolated buildings with isolated floors to
deploy your model anymore. There is only one spherical layer of physical
earth surface for you to use as a realm, which is the current IPv4
deployment. How could you still have multiple full IPv4 address sets
deployed, yet not seeing their identical twins, triplets, etc.? Are you
proposing multiple spherical layers of "realms", one on top of the other?
2) When I cited the DotConnectAfrica graphic logo as a visual model
for the EzIP deployment over current IPv4, I was pretty specific that
each RAN was tethered from the current Internet core via one IPv4
address. We were very careful about isolating the netblocks in terms of
which one does what. In other words, even though the collection of RANs
form a parallel cyberspace to the Internet, you may look at each RAN as
an isolated balloon for others. So that each RAN can use up the entire
240/4 netblock.
Please clarify your configuration.
Thanks,
Abe (2022-04-01 17:44)
On 2022-04-01 10:55, Abraham Y. Chen wrote:
On 2022-04-01 10:00, Pascal Thubert (pthubert) wrote:
Makes sense, Abe, for the next version.
Note that the intention is NOT any to ANY. A native IPv6 IoT device
can only talk to another IPv6 device, where that other device may use
a YATT address or any other IPv6 address.
But it cannot talk to a YADA node. That’s what I mean by baby steps
for those who want to.
Keep safe;
Pascal
*From:* Abraham Y. Chen <ayc...@avinta.com>
*Sent:* vendredi 1 avril 2022 15:49
*To:* Vasilenko Eduard <vasilenko.edu...@huawei.com>; Pascal Thubert
(pthubert) <pthub...@cisco.com>; Justin Streiner <strein...@gmail.com>
*Cc:* NANOG <nanog@nanog.org>
*Subject:* Re: Let's Focus on Moving Forward Re: V6 still not
supported re: 202203261833.AYC
Hi, Pascal:
What I would appreciate is an IP packet header design/definition
layout, word-by-word, ideally in bit-map style, of an explicit
presentation of all IP addresses involved from one IoT in one realm
to that in the second realm. This will provide a clearer picture of
how the real world implementation may look like.
Thanks,
Abe (2022-04-01 09:48)
On 2022-04-01 08:49, Vasilenko Eduard wrote:
As I understand: “IPv4 Realms” between “Shaft” should be capable
to have a plain IPv4 header (or else why all of these).
Then Gateway in the Shaft should change headers (from IPv4 to IPv6).
Who should implement this gateway and why? He should be formally
appointed to such an exercise, right?
Map this 2 level hierarchy to the real world – you may fail with
this.
Ed/
*From:* Pascal Thubert (pthubert) [mailto:pthub...@cisco.com
<mailto:pthub...@cisco.com>]
*Sent:* Friday, April 1, 2022 3:41 PM
*To:* Vasilenko Eduard <vasilenko.edu...@huawei.com>
<mailto:vasilenko.edu...@huawei.com>; Justin Streiner
<strein...@gmail.com> <mailto:strein...@gmail.com>; Abraham Y.
Chen <ayc...@avinta.com> <mailto:ayc...@avinta.com>
*Subject:* RE: Let's Focus on Moving Forward Re: V6 still not
supported re: 202203261833.AYC
Hello Eduard:
Did you just demonstrate that POPs cannot exist? Or that there
cannot be a Default Free Zone?
I agree with your real world issue that some things will have to
be planned between stake holders, and that it will not be easy.
But you know what the French say about “impossible”.
Or to paraphrase Sir Arthur, now that we have eliminated all the
impossible transition scenarios, whatever remains…
There will be YADA prefixes just like there are root DNS. To be
managed by different players as you point out. And all routable
within the same shaft.
Keep safe;
Pascal
*From:* Vasilenko Eduard <vasilenko.edu...@huawei.com>
*Sent:* vendredi 1 avril 2022 14:32
*To:* Pascal Thubert (pthubert) <pthub...@cisco.com>; Justin
Streiner <strein...@gmail.com>; Abraham Y. Chen <ayc...@avinta.com>
*Subject:* RE: Let's Focus on Moving Forward Re: V6 still not
supported re: 202203261833.AYC
Hi Pascal,
In general, your idea to create a hierarchy is good.
In practice, it would fail because you have created a virtual
hierarchy that does not map to any administrative border. Who
should implement gateways for the “Shaft”? Why?
If you would appoint Carrier as the Shaft responsible then it is
not enough bits for Shaft.
If you would appoint Governments as the Shaft responsible then
would be a so big scandal that you would regret the proposal.
Hence, I do not see proper mapping for the hierarchy to make YADA
successful.
Eduard
*From:* NANOG
[mailto:nanog-bounces+vasilenko.eduard=huawei....@nanog.org
<mailto:nanog-bounces+vasilenko.eduard=huawei....@nanog.org>] *On
Behalf Of *Pascal Thubert (pthubert) via NANOG
*Sent:* Friday, April 1, 2022 2:26 PM
*To:* Justin Streiner <strein...@gmail.com>; Abraham Y. Chen
<ayc...@avinta.com>
*Cc:* NANOG <nanog@nanog.org>
*Subject:* RE: Let's Focus on Moving Forward Re: V6 still not
supported re: 202203261833.AYC
For the sake of it, Justin, I just published
https://datatracker.ietf.org/doc/draft-thubert-v6ops-yada-yatt/.
The first section of the draft (YADA) extends IPv4 range in an
IPv4-only world. For some people that might be enough and I’m
totally fine with that.
Keep safe;
Pascal
*From:* NANOG <nanog-bounces+pthubert=cisco....@nanog.org> *On
Behalf Of *Justin Streiner
*Sent:* dimanche 27 mars 2022 18:12
*To:* Abraham Y. Chen <ayc...@avinta.com>
*Cc:* NANOG <nanog@nanog.org>
*Subject:* Re: Let's Focus on Moving Forward Re: V6 still not
supported re: 202203261833.AYC
Abe:
To your first point about denying that anyone is being stopped
from working on IPv4, I'm referring to users being able to
communicate via IPv4. I have seen no evidence of that.
I'm not familiar with the process of submitting ideas to IETF, so
I'll leave that for others who are more knowledgeable on that to
speak up if they're so inclined.
Thank you
jms
On Sat, Mar 26, 2022 at 6:43 PM Abraham Y. Chen
<ayc...@avinta.com> wrote:
1) "... no one is stopping anyone from working on IPv4
... ": After all these discussions, are you still
denying this basic issue? For example, there has not been any
straightforward way to introduce IPv4 enhancement ideas to
IETF since at least 2015. If you know the way, please make it
public. I am sure that many are eager to learn about it. Thanks.
Image removed by sender.
<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>
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
