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”.
- [Ideas] A comment on the use case draft O. Ozan Koyluoglu
- Re: [Ideas] A comment on the use case draft Tom Herbert
- Re: [Ideas] A comment on the use case draft Hesham ElBakoury
- Re: [Ideas] A comment on the use case draft Liubingyang (Bryan)
- Re: [Ideas] A comment on the use case draft Hesham ElBakoury
- Re: [Ideas] A comment on the use case draft Liubingyang (Bryan)
- Re: [Ideas] A comment on the use case draft Hesham ElBakoury