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

"Liubingyang (Bryan)" <liubingyang@huawei.com> Thu, 23 March 2017 00:22 UTC

Return-Path: <liubingyang@huawei.com>
X-Original-To: ideas@ietfa.amsl.com
Delivered-To: ideas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0367C1293E0 for <ideas@ietfa.amsl.com>; Wed, 22 Mar 2017 17:22:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuXI5gWc9UiN for <ideas@ietfa.amsl.com>; Wed, 22 Mar 2017 17:22:23 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1657C128AB0 for <ideas@ietf.org>; Wed, 22 Mar 2017 17:22:21 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJJ65019; Thu, 23 Mar 2017 00:22:18 +0000 (GMT)
Received: from SZXEMI404-HUB.china.huawei.com (10.82.75.40) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 23 Mar 2017 00:22:17 +0000
Received: from SZXEMI508-MBS.china.huawei.com ([169.254.10.152]) by SZXEMI404-HUB.china.huawei.com ([10.82.75.40]) with mapi id 14.03.0235.001; Thu, 23 Mar 2017 08:22:03 +0800
From: "Liubingyang (Bryan)" <liubingyang@huawei.com>
To: Hesham ElBakoury <Hesham.ElBakoury@huawei.com>, "O. Ozan Koyluoglu" <ozan.koyluoglu@berkeley.edu>, "ideas@ietf.org" <ideas@ietf.org>
Thread-Topic: [Ideas] A comment on the use case draft
Thread-Index: AQHSoo4jiFvCF3nCukOU35ULE3FG9qGgA26AgACJuBCAAAnQgIAA9+ZA
Date: Thu, 23 Mar 2017 00:22:03 +0000
Message-ID: <C1CE72EE84AF224E94DA21AE134209EE010250C3@SZXEMI508-MBS.china.huawei.com>
References: <CAL8GJ8x6VMfx9gN7SWZ-q=bGJ1NxXbnGcfvhVMjf+zKVbMZFww@mail.gmail.com> <C3855D43D6701846AD1151A536E7A058240027E4@SJCEML701-CHM.china.huawei.com> <C1CE72EE84AF224E94DA21AE134209EE01022D0A@SZXEMI508-MBS.china.huawei.com> <C3855D43D6701846AD1151A536E7A058240076DA@SJCEML701-CHM.china.huawei.com>
In-Reply-To: <C3855D43D6701846AD1151A536E7A058240076DA@SJCEML701-CHM.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.130.168.116]
Content-Type: multipart/alternative; boundary="_000_C1CE72EE84AF224E94DA21AE134209EE010250C3SZXEMI508MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.58D3153B.0152, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.10.152, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 9632ff7e4fdb52bec3bdf1744fdf5127
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/XTO2BFXJRws_ffXp70xhAbGVbIM>
Subject: Re: [Ideas] A comment on the use case draft
X-BeenThere: ideas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." <ideas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ideas>, <mailto:ideas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ideas/>
List-Post: <mailto:ideas@ietf.org>
List-Help: <mailto:ideas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ideas>, <mailto:ideas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Mar 2017 00:22:26 -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) <liubingyang@huawei.com>; O. Ozan Koyluoglu <ozan.koyluoglu@berkeley.edu>; ideas@ietf.org
Subject: RE: [Ideas] A comment on the use case draft

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; ideas@ietf.org<mailto:ideas@ietf.org>
Subject: RE: [Ideas] A comment on the use case draft

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

From: Ideas [mailto:ideas-bounces@ietf.org] On Behalf Of Hesham ElBakoury
Sent: Wednesday, March 22, 2017 4:36 PM
To: O. Ozan Koyluoglu <ozan.koyluoglu@berkeley.edu<mailto:ozan.koyluoglu@berkeley.edu>>; ideas@ietf.org<mailto:ideas@ietf.org>
Subject: Re: [Ideas] A comment on the use case draft

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:ideas-bounces@ietf.org] On Behalf Of O. Ozan Koyluoglu
Sent: Tuesday, March 21, 2017 2:56 PM
To: ideas@ietf.org<mailto:ideas@ietf.org>
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”.