Subject: Re: [Int-area] [int-area Draft: ]IP address space reclassification - Kindly review

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 2 Oct 2018 08:47:20 +0200 (CEST)

On Tue, 11 Sep 2018, vineet deshpande wrote:

> Hi,
> I have submitted the updated version on the draft for IP address space reclassification. Kindly review.

I started reading your draft:

"An AI based TCP IP model describes how Big Data is centered"

I then proceeded to try to read the rest of the draft. It's completely 
full of buzzwords that I do not know what they mean concretely, and it 
renders the document impossible for me to understand.

I've been involved in Internet routing for 20 years now, and sections such 
as:

"   o    The Big Data bottleneck lies between different Autonomous
         Systems. Due to the implicit life cycle between a Network,
         Internet and the Cloud which is time bound and unidirectional,
         the Network also needs to grow and scale to the Cloud to reap
         the benefits of Cloud such as Datacenter virtualization,
         scaling and high availability."

I just don't understand.

"   o    For such scaling to occur from both ends a Virtual address
         space is needed in between. The limitations brought about by
         the present classification of IP address space into public,
         private and the almost mandatory usage of NAT in the Internet
         and Cloud architecture leads to suggest that translating or
         mapping of the IP address into another Virtual address space
         cannot be avoided."

"almost mandatory usage of NAT". This is being restored to originally 
intended state by IPv6 where we do not need NAT anymore (NAT wasn't a 
thing until around 2000, before that we didn't do any NAT).

"   o   The Network cannot be de-classified from the cloud. The
        Network needs to grow and scale towards the Cloud."

"The Cloud" is just someone elses computer. Virtualising something doesn't 
change anything concretely from it being run on metal.

Please re-write the draft and use concrete terms instead of just a lot of 
buzzwords.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: vineet deshpande <[email-masked]>
Date: Tue, 2 Oct 2018 08:04:52 +0000 (UTC)

Hi Mikael,
Appreciate your inputs. Point taken regarding the buzz words. However need some clarification about the almost mandatory usage of NAT. I think It is fair to say that NAT is almost always used where Web servers and Load balancers are involved. I have a few comments on NAT starting with RFC 4864. RFC 4864: "Although there are many perceived benefits to Network Address Translation (NAT), its primary benefit of "amplifying" available address space is not needed in IPv6."
However NAT is still being used for load balancing (is this reverse amplification?) with IPv6. 
Is NAT being considered dispensable because of the implicit firewall deny/allow characteristics present due to inside and outside interface configuration ? NAT configuration is similar to an access rule that only allows particular private IP to be translated to a public IP or vice versa.
However an implicit deny is present in most Firewalls. 
Also NAT local and global definitions appear to be misleading.  Taking cue from your comment about the Cloud being just another computer (host):Inside Network (or Cloud) and Outside Network (or Cloud) ? Dual Cloud and Dual Network ?This local and global definition was adopted for IPv6 replacing private and public IPv4 classification.
So how will NAT be eliminated ? 
Is IPv6 striving to eliminate NAT completely or is it only to avoid NAT usage for conserving address space ?
Thanks & Regards,Vineet Deshpande

    On Tuesday, 2 October 2018, 12:17:48 pm GMT+5:30, Mikael Abrahamsson <[email-masked]> wrote:  

I just don't understand.

_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 2 Oct 2018 14:58:12 +0200 (CEST)

> Is IPv6 striving to eliminate NAT completely or is it only to avoid NAT usage for conserving address space ?

NAT was invented to handle IPv4 exhaustion. With IPv6 there is no address 
shortage, so no need for NAT to avoid address limitations.

The basic premise of the Internet is that it's interconnected networks 
with unique addresses. If you don't want something to talk to/from the 
Internet, then you firewall it or don't announce that address space to the 
Internet. There are some other variants, like ULA that amounts to the same 
thing.

If your load balancer re-writes addresses as part of its normal operation, 
that's up to you. There is no need to call the addresses before and after 
anything special, they're only special in IPv4 possibly due to address 
number limitations so they can be re-used in several locations. No need 
for this in IPv6 unless you absolutely want to. I would advise not to.

---

From: vineet deshpande <[email-masked]>
Date: Tue, 2 Oct 2018 15:23:01 +0000 (UTC)

Got it. NAT is more problematic than duplicate addresses in a private address space. 
I will try to rewrite the document with IPv6 in mind. I may have some concrete points to add to prove the need for the virtual address space and ip address reclassification.
One such point is about virtual neighborship through the virtual address space. For example virtual EBGP local neighborship and virtual EBGP global neighborship. I think this could be implemented with ULA secure Neighbor discovery and global IPv6 addresses. Through RR clusters dynamic path recalculations can be performed to resolve the congestion problems.However the virtual address space is still needed from my perspective as a local and global controller.

Thanks & Regards,Vineet Deshpande
    On Tuesday, 2 October 2018, 6:28:17 pm GMT+5:30, Mikael Abrahamsson <[email-masked]> wrote:

---

From: Joe Touch <[email-masked]>
Date: Thu, 4 Oct 2018 18:43:26 -0700

On 10/2/2018 5:58 AM, Mikael Abrahamsson wrote:
> NAT was invented to handle IPv4 exhaustion.
Perhaps, but at least part of the benefit is a way to enforce the
distinction between consumer and commercial-grade Internet (where you
can't run a server behind a NAT).
> With IPv6 there is no address shortage, so no need for NAT to avoid
> address limitations.
Not those, but to enforce the artificial consumer/commercial
distinction, there is and will be.
Joe

---

From: vineet deshpande <[email-masked]>
Date: Mon, 8 Oct 2018 14:23:08 +0000 (UTC)

Hi All,
I have re-written the document removing the buzz words and have added a glossary for any terms used. Request review.
https://datatracker.ietf.org/doc/draft-deshpande-intarea-ipaddress-reclassification/

Thanks & Regards,Vineet Deshpande
    On Friday, 5 October 2018, 7:14:44 am GMT+5:30, Joe Touch <[email-masked]> wrote:

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 8 Oct 2018 19:31:53 +0200 (CEST)

> https://datatracker.ietf.org/doc/draft-deshpande-intarea-ipaddress-reclassification/

You need to re-write the entire thing.

What is this? Why is it in the document? "2. The Mathematical premise for 
the electromagnetic equivalent"

"  9. IANA Considerations
    This document describes the need for IP address space
    reclassification"

It just doesn't. At least not in a way I can understand.

---

From: vineet deshpande <[email-masked]>
Date: Mon, 8 Oct 2018 22:07:00 +0000 (UTC)

I have 12 years of experience in this field. The reason I re-wrote the draft was to make clear the math behind the evolution of network  from wireless technologies. The reason why 'the mathematical premise for the electromagnetic equivalent" is in the draft is the same as was in the previous draft. To explain the limitations brought about by this evolution. As ietf is actively involved in multipath TCP and ipv6 research any imitations in design considerations is relevant for all to know. I would appreciate if you could read the draft in its entirety and comment at least on why the virtual address space with UlLA ipv6 and multipath tcp for  virtual bgp neighborship is not a practical solution. That would at least make the matter more concrete.Thanks and regards,Vineet Deshpande

Sent from Yahoo Mail on Android 

"  9. IANA Considerations

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 9 Oct 2018 07:07:24 +0200 (CEST)

On Mon, 8 Oct 2018, vineet deshpande wrote:

> I have 12 years of experience in this field. The reason I re-wrote the 
> draft was to make clear the math behind the evolution of network  from 
> wireless technologies. The reason why 'the mathematical premise for the 
> electromagnetic equivalent" is in the draft is the same as was in the 
> previous draft. To explain the limitations brought about by this 
> evolution. As ietf is actively involved in multipath TCP and ipv6 
> research any imitations in design considerations is relevant for all to 
> know. I would appreciate if you could read the draft in its entirety and 
> comment at least on why the virtual address space with UlLA ipv6 and 
> multipath tcp for  virtual bgp neighborship is not a practical solution. 
> That would at least make the matter more concrete.Thanks and 
> regards,Vineet Deshpande

I still don't understand why there is a need for this "reclassification".

You can classify parts of your IP space to have whatever meaning you want, 
there is no reason to involve the IETF and IANA for that, and nobody 
external to you need to know anything about it.

If the packets are internal to you, you can use the flow label for 
whatever you want. If you want to use the flow label for something 
globally significant, you're going to have a really hard time convincing 
people that this is useful. Your draft does not do that.

---

From: vineet deshpande <[email-masked]>
Date: Tue, 9 Oct 2018 05:57:24 +0000 (UTC)

>external to you need to know anything about it.

I have not involved IETF and IANA into anything. Not sure what you mean by that. how I can involve IETF or IANA into anything unless it is through IETF and IANA ?IETF and IANA are involved in IPv6, Multipath TCP and address assignment.
>people that this is useful. Your draft does not do that.

As per RFC6437 the expectation for flow label seems to be to have global significance
   o  This specification retains the rule that the flow label must not
      be changed en route but allows routers to set the label on behalf
      of hosts that do not do so.

    On Tuesday, 9 October 2018, 10:37:31 am GMT+5:30, Mikael Abrahamsson <[email-masked]> wrote:

---

From: vineet deshpande <[email-masked]>
Date: Wed, 10 Oct 2018 01:58:47 +0000 (UTC)

>I still don't understand why there is a need for this "reclassification"
Because it is not just a reclassification, it is a unique mapping

 

-- 
Mikael Abrahamsson    email: [email-masked]  _______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: Joe Touch <[email-masked]>
Date: Tue, 9 Oct 2018 20:26:16 -0700

> On Oct 8, 2018, at 7:23 AM, vineet deshpande <[email-masked]> wrote:
> 
> I have re-written the document removing the buzz words 

The buzzwords are still there.

They are exceeded only by the amount and extent of factual errors - a *partial* list of which is noted below.

Joe

-----

Section 2:
	- MIMO can occur with refraction or partial reflection; it does not need total internal reflection
	- MIMO requires multiple transmitters, whereas multipath routing can be leveraged using only one network interface

Section 3:
	- “machine” and “host” imply more similarity then difference
	- the Von Neumann bottleneck would be an artifact of a machine implementation; non-Von architectures, such as dataflow, do not suffer this fate (and are used in high-performance routers)

Section 4 (which isn’t even written out as paragraphs):
	- OSPF is incremental computation of a Ford-Fulkerson graph based on local information; whether code uses a heap, a stack, or any other data structure is an implementation detail
	- classful routing hasn’t been used in IPv4 since the early 1990s and CIDR; it was never part of IPv6
	- BGP runs OSPF on a graph transformation, where the networks of Autonomous Systems collapse to nodes in the transformed graph; nodes are not “inserted”, but computed 
	- a tree is a UAG where each node can have only one parent; while all trees are UAGs, not all UAGs are trees
	- A UAG whose underlying graph is a tree is — a tree.
	- BGP computes a graph determined by AS interconnectivity; whether this graph is strongly connected or not depends on the AS connectivity alone

----

---

From: vineet deshpande <[email-masked]>
Date: Wed, 17 Oct 2018 07:27:35 +0000 (UTC)

Thanks for your feedback. Answers inline:  -----
Section 2: > MIMO can occur with refraction or partial reflection; it does not need total internal reflection - Singlecore fiber transmission is essentially equivalent to SISO. Multicore is equivalent to MIMO. Both are based on TIR.  The reference to TIR is wrt to spartial frequency and not temporal frequency. > MIMO requires multiple transmitters, whereas multipath routing can be leveraged using only one network interface - If a multicore optic fiber has multiple cores similar to MIMO then the network interface also must have multiple sub-interface or multiple addresses for multipathing. Taking this point further,  in fact Multipath TCP might require multiple addresses on an interface. In fact this multipath TCP connections must be formed through the virtual address space with anycast ipv6 addressing. then the RR cluster to cluster communication is possible.          IEEE documentation online show that research is going on over the suitability of multicore for MIMO.
Section 3:         > “machine” and “host” imply more similarity then difference- Hence the reference to a step back. Host to host communication is end-to-end and happens at the Transport layer. Then taking a step back and observing that the machine to machine routing communication happens at the Internet layer then the node to node communication can also include cluster to cluster communication in the middle.A cluster being a cluster of nodes as explained in the MIMO routing principle.        > the Von Neumann bottleneck would be an artifact of a machine implementation; non-Von architectures, such as dataflow, do not suffer this fate (and are used in high-performance routers)- Von neumann architecture is simple and based on data and program simultaneously accessing a common memory space. The harvard architecture has separate address space for data and program with common access for memory (cache) (modified harvard).If the routing control plane can be considered as a centralized control plane then the routing control plane must have a common memory space. This concept can be stretched and we can consider the whole routing plane of the internet as a centralized control plane.If a centralized control plane is needed for the Internet then a common memory address space needs to be facilitated. Hence a Virtual address space is the only option. While the High performance routers may individually not be impacted at the Internet layer, the need for cluster to cluster communcation and a common and more advanced control plane between all the high performance routers cannot be ignored. The benefit is not exactly higher data flow but better control of the data flow through multipath.Anyway, primarily the reference to Van neumann bottleneck is wrt finding where the data is stuck or congested in the Internet. And the data can be stuck in transit between high performance routers.

Section 4 (which isn’t even written out as paragraphs):        -  Were divided in sections. I have mentioned additional points below.
  > OSPF is incremental computation of a Ford-Fulkerson graph based on local information; whether code uses a heap, a stack, or any other data structure is an implementation detail- I was referring to both EIGRP and OSPF. Specifically in EIGRP a local computation does not resolve any global routing challenges. Hence the feasibility condition.However this is applicable to OSPF as well. The Ford-Fulkerson graph is the max-flow-min-cut algorithm wherein the max flow is through the min-cut path. While an alternate  path is called an augmenting path. This is again mathematically anologous to path connectedness.
 >  classful routing hasn’t been used in IPv4 since the early 1990s and CIDR; it was never part of IPv6- Implication is that classful boundaries will exist due to classful summarization in routing protcols. While there may be no impact due to high performance routers, there will be traffic impact due to congestion and lack of control on summarization.This appears to be more of a concern without a solution in IPv6.
 >  BGP runs OSPF on a graph transformation, where the networks of Autonomous Systems collapse to nodes in the transformed graph; nodes are not “inserted”, but computed- Correct. BGP cannot insert routes. I need to change this and put the "insertion" bit as one of the possibilities through the virtual address space and virtual redistriibution.Another factor is that in OSPF a virtual link does not allow data transfer. Analogously virtual links through the network of autonomous systems can be interlinked to form a virtual address space and a central control plane. In turn, the virtual AS boundaries of the central control planes can be determined by the best effort reachability as calculated through k-Nearness algorthms.

 > a tree is a UAG where each node can have only one parent; while all trees are UAGs, not all UAGs are trees > A UAG whose underlying graph is a tree is — a tree. > BGP computes a graph determined by AS interconnectivity; whether this graph is strongly connected or not depends on the AS connectivity alone
This is mostly the duality that I have been referring. your comments are opposite to my comments.There is a duality between program control and state machine.This is analogous to the duality between an SDN controller and BGP PBB EVPN. this is derived by applying the Von neumann bottleneck to the TCP IP layers. The Ford fulkerson algorithm is based on max-flow min cut theorem which is in turn based on a duality theorem.
The IBGP mesh within an AS is strongly connected. If the interconnected AS is not strongly connected an attempt can be made to make it strongly connected by utilizing the IBGP full mesh within an AS.If the graph is restricted to being a UAG. An attempt must be made to make it a DAG for increased utilization of path vector attributes.Hence the polytree structure (the virtual address space on top interconnecting autonomous systems)
While the virtual address space may appear to be a best effort traffic optimization solution it may be critical in solving future congestion and traffic bottleneck problems due to mathematical limitations.

    On Wednesday, 10 October 2018, 8:56:24 am GMT+5:30, Joe Touch <[email-masked]> wrote:  

The buzzwords are still there.
They are exceeded only by the amount and extent of factual errors - a *partial* list of which is noted below.
Joe
-----
Section 2: - MIMO can occur with refraction or partial reflection; it does not need total internal reflection - MIMO requires multiple transmitters, whereas multipath routing can be leveraged using only one network interface
Section 3: - “machine” and “host” imply more similarity then difference - the Von Neumann bottleneck would be an artifact of a machine implementation; non-Von architectures, such as dataflow, do not suffer this fate (and are used in high-performance routers)
Section 4 (which isn’t even written out as paragraphs): - OSPF is incremental computation of a Ford-Fulkerson graph based on local information; whether code uses a heap, a stack, or any other data structure is an implementation detail - classful routing hasn’t been used in IPv4 since the early 1990s and CIDR; it was never part of IPv6 - BGP runs OSPF on a graph transformation, where the networks of Autonomous Systems collapse to nodes in the transformed graph; nodes are not “inserted”, but computed  - a tree is a UAG where each node can have only one parent; while all trees are UAGs, not all UAGs are trees - A UAG whose underlying graph is a tree is — a tree. - BGP computes a graph determined by AS interconnectivity; whether this graph is strongly connected or not depends on the AS connectivity alone
----

---

From: Joe Touch <[email-masked]>
Date: Wed, 17 Oct 2018 07:06:01 -0700

Vineet,

> On Oct 17, 2018, at 12:27 AM, vineet deshpande <[email-masked]> wrote:
> 
> 
> 
> 	> MIMO can occur with refraction or partial reflection; it does not need total internal reflection
>  - Singlecore fiber transmission is essentially equivalent to SISO. Multicore is equivalent to MIMO.

Both use single transmitters and single receivers, thus neither is MIMO. If you have a point to make, you need to explain why you think your analogy is useful and correct.

> Both are based on TIR.  The reference to TIR is wrt to spartial frequency and not temporal frequency.

Fibers use TIR but MIMO exists without fibers. If there is a point to your analogy, you need to explain why this issue (TIR) is relevant.

> 	> MIMO requires multiple transmitters, whereas multipath routing can be leveraged using only one network interface
>  - If a multicore optic fiber has multiple cores similar to MIMO

It is not, as I have explained. You have not explained otherwise.

This is the problem with your discussion in general. Simply repeating a statement doesn’t make it either correct or useful as an analogy.

If you want to engage further, you need to use analogies that begin as being correct and end as being useful.

Joe

---

From: vineet deshpande <[email-masked]>
Date: Wed, 17 Oct 2018 14:52:27 +0000 (UTC)

Optimal route reflector usage with clusters should be the benefit. TIR analogy for the same. I have made sufficient design recommendations which I thought were useful. If found to be not useful that is fine and I will delay discussion till some practical proof of benefit is found or POC  is built. 
Sent from Yahoo Mail on Android 
 
  On Wed, 17 Oct 2018 at 19:36, Joe Touch<[email-masked]> wrote:   Vineet,

Thanks for your feedback. Answers inline:  -----
Section 2: > MIMO can occur with refraction or partial reflection; it does not need total internal reflection - Singlecore fiber transmission is essentially equivalent to SISO. Multicore is equivalent to MIMO.

 > MIMO requires multiple transmitters, whereas multipath routing can be leveraged using only one network interface - If a multicore optic fiber has multiple cores similar to MIMO