Subject: [Ideas] A comment on the use case draft

From: "O. Ozan Koyluoglu" <[email-masked]>
Date: Tue, 21 Mar 2017 21:55:31 +0000

There is a use case in data center networks, which could be discussed here.
Using such an ID-based technology and a directory system (such as GRIDS),
services and virtual machines can migrate to any desired server much easily
without a need of an explicit IP address change between VMs, by keeping the
same ID. In this context, location address can be composed of the address
of the top of the rack switch that a server connects to and an additional
server number.

Directory system can also be utilized for load balancing in this scenario.
See, e.g., the paper titled “VL2: A scalable and flexible data center
network”.

---

From: Tom Herbert <[email-masked]>
Date: Tue, 21 Mar 2017 15:10:57 -0700

On Tue, Mar 21, 2017 at 2:55 PM, O. Ozan Koyluoglu
<[email-masked]> wrote:
> same ID. In this context, location address can be composed of the address of
> the top of the rack switch that a server connects to and an additional
> server number.
>
Yes. That is essentially the use case we developed at Facebook and is
being deployed. ILA is being used for that, the mapping service is
still TBD to get to the goal of being able to migrate and task or VM.

Tom

> _______________________________________________
> Ideas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ideas
>

---

From: Hesham ElBakoury <[email-masked]>
Date: Wed, 22 Mar 2017 08:35:57 +0000

Cisco uses LISP to support VM migration between data centers w/o changing its IP address. Please see the attached white paper.

Hesham

From: Ideas [mailto:[email-masked]] On Behalf Of O. Ozan Koyluoglu
Sent: Tuesday, March 21, 2017 2:56 PM
To: [email-masked]
Subject: [Ideas] A comment on the use case draft

There is a use case in data center networks, which could be discussed here. Using such an ID-based technology and a directory system (such as GRIDS), services and virtual machines can migrate to any desired server much easily without a need of an explicit IP address change between VMs, by keeping the same ID. In this context, location address can be composed of the address of the top of the rack switch that a server connects to and an additional server number.
Directory system can also be utilized for load balancing in this scenario. See, e.g., the paper titled “VL2: A scalable and flexible data center network”.

---

From: "Liubingyang (Bryan)" <[email-masked]>
Date: Wed, 22 Mar 2017 08:50:46 +0000

Do other DCs have any mapping problems in operating their virtual networks (e.g., VXLAN)?

From: Ideas [mailto:[email-masked]] On Behalf Of Hesham ElBakoury
Sent: Wednesday, March 22, 2017 4:36 PM
To: O. Ozan Koyluoglu <[email-masked]>; [email-masked]
Subject: Re: [Ideas] A comment on the use case draft

Hesham

From: Ideas [mailto:[email-masked]] On Behalf Of O. Ozan Koyluoglu
Sent: Tuesday, March 21, 2017 2:56 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Ideas] A comment on the use case draft

---

From: Hesham ElBakoury <[email-masked]>
Date: Wed, 22 Mar 2017 17:23:59 +0000

Hi Bryan,

The basic use case for VXLAN (RFC 7348) is to connect two or more layer three (L3) networks and make them look like they
share the same layer two (L2) domain. For  example VxLAN allows  virtual machines to live in two disparate networks yet still
operate as if they were attached to the  same L2 network.

Mapping is needed if the communicating VMs use VM IDs instead of IP addresses. One way to do this is for the source VM to send a multicast
request, which has the ID of the destination VM, to all VMs in the same VN. Upon receiving this request, the destination VM returns its IP and MAC addresses.
Another way is for the source VM to use a mapping system such as GRIDS to get the IP address of the destination VM using its ID. The source VM then sends
an ARP request using IP multicast to get the MAC address of the destination VM.

Hesham
From: Liubingyang (Bryan)
Sent: Wednesday, March 22, 2017 1:51 AM
To: Hesham ElBakoury; O. Ozan Koyluoglu; [email-masked]
Subject: RE: [Ideas] A comment on the use case draft

Hesham

---

From: "Liubingyang (Bryan)" <[email-masked]>
Date: Thu, 23 Mar 2017 00:22:03 +0000

Thank you Hesham!

Yes, mapping VM ID to IP is a use scenario. However, I think, mapping virtual network addresses into physical network address (overlay to underlay) is used more broadly. Actually (tenant net ID, VM IP) tuple can be treated as a VM ID, which is mapped into (VXLAN ID, Physical IP). So my question is that if the current practices have any problems with operating the mapping (maybe maintained in data plane forwarding tables as well as control plane), and the GRIDS can solve them better? That could be a good use case of GRIDS.

Thanks,
Bryan

From: Hesham ElBakoury
Sent: Thursday, March 23, 2017 1:24 AM
To: Liubingyang (Bryan) <[email-masked]>; O. Ozan Koyluoglu <[email-masked]>; [email-masked]
Subject: RE: [Ideas] A comment on the use case draft

Hi Bryan,

Hesham
From: Liubingyang (Bryan)
Sent: Wednesday, March 22, 2017 1:51 AM
To: Hesham ElBakoury; O. Ozan Koyluoglu; [email-masked]<mailto:[email-masked]>
Subject: RE: [Ideas] A comment on the use case draft

From: Ideas [mailto:[email-masked]] On Behalf Of Hesham ElBakoury
Sent: Wednesday, March 22, 2017 4:36 PM
To: O. Ozan Koyluoglu <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Ideas] A comment on the use case draft

Hesham

---

From: Hesham ElBakoury <[email-masked]>
Date: Fri, 24 Mar 2017 20:08:09 +0000

Hi Bryan,

I think you raised a good point about how to define an ID for an endpoint.  I am not sure if VM IP should be used to define an ID. A given VM may be part of more than one VN and may have different IP addresses
in each VN.  VM may also move and change its IP address. The ID should be independent of the location of the VM and VNs it is part of.

Thanks

Hesham

From: Liubingyang (Bryan)
Sent: Wednesday, March 22, 2017 5:22 PM
To: Hesham ElBakoury; O. Ozan Koyluoglu; [email-masked]
Subject: RE: [Ideas] A comment on the use case draft

Thank you Hesham!

Thanks,
Bryan

From: Hesham ElBakoury

Hi Bryan,

Hesham

Hesham