Re: [armd] Fwd: New Version Notification for draft-wkumari-dcops-l3-vmmobility-00.txt

[Gary Berger <[e-mail]>]

I am not advocating any such thing.. I merely am trying to point to a bit of
history and the problem at hand; as noted in the ARMD Call for
Investigation:

One such aspect,being investigated by the ARMD working group, is the scaling
of address resolution between the network (L3) and link (L2) layers of
modern datacenter networks.

You cannot decouple the resolution and binding of addresses without
understanding the limitations in the current architecture. LISP doesn't
scale because of the path liveness problem, I am not familiar enough with
EIP or ILNP but I am sure that this issue is long-lived and unsolved and at
the root of our scaling challenges not just in DC but across the Internet..


-g



From:  <[e-mail]>
Date:  Fri, 12 Aug 2011 13:37:28 -0400
To:  Gary Berger <[e-mail]>
Cc:  <[e-mail]>
Subject:  RE: [armd] Fwd: New Version Notification for
draft-wkumari-dcops-l3-vmmobility-00.txt

Hi Gary,
 
Are you aware of the IETF work already in progress on that sort of
decoupling, e.g., LISP, HIP and ILNP?
 
I don¹t understand why another effort in this space would be useful.
 

Thanks,
--David
 

From: Gary Berger [mailto:[e-mail]]
Sent: Friday, August 12, 2011 10:02 AM
To: Black, David; [e-mail]
Cc: [e-mail]
Subject: Re: [armd] Fwd: New Version Notification for
draft-wkumari-dcops-l3-vmmobility-00.txt
 

I would hope that we can find a more elegant approach to the problem of
dealing with dynamic address learning and mobility instead of adding
overlays. 

 

We have created the L2 scaling problem (which shows itself in mobility and
control plane scalability) because of the fact that the data-link address,
IP Address and what we use to identify the host (I.e. The DNS name) are all
bound to the point of attachment. This created the desire for the "flat"
network which as we know doesn't scale. It would be great if part of this
working group can look from the point of view that the Internet is an
experiment and we never evolved to a clean implementation. Decoupling the
service (I.e. Where a socket call connects to) from the node address and the
point of attachment will go a long way to fixing the scaling challenges. A
better description  can be found in Saltzer, et al  RFC-1498
<http://tools.ietf.org/html/rfc1498> . Also, one of the chief OSI developers
John Day has an interesting perspective on this here
http://pouzin.pnanetworks.com/images/KoreaNamingFund100218.pdf

 

-g

 

On 8/12/11 9:08 AM, "[e-mail]" <[e-mail]> wrote:

 
> 
> Hi Warren,
> 
>  
>> 
>>> > It is good to see the draft.
>> 
>> And it's good to see that someone has already read it :-P
> 
>  
> 
> Make that at least two someones ;-).  Thanks for getting the conversation
> started.
> 
>  
> 
> A detailed example of related technology can be found in draft-hasmit-otv-03
> 
> (http://www.ietf.org/id/draft-hasmit-otv-03.txt)  This L2-in-L3 functionality
> 
> (MAC-in-IP) is targeted at carrier/provider networks rather than data center
> 
> networks, and uses UDP encapsulation (e.g., as opposed to GRE).  Courtesy of
> 
> the focus on carrier/provider networks, one of the areas of design emphasis
> 
> is avoidance of flooding.
> 
>  
> 
> Please don't ask me about OTV details - the draft authors (e.g., Dino) would
> 
> be a better resource for those sorts of questions.
> 
>  
> 
> Thanks,
> 
> --David
> 
> ----------------------------------------------------
> 
> David L. Black, Distinguished Engineer
> 
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> 
> [phone]             FAX: [phone]
> 
> [e-mail]        Mobile: [phone]
> 
> ----------------------------------------------------
> 
>  
>> 
>> -----Original Message-----
>> 
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Warren Kumari
>> 
>> Sent: Friday, August 12, 2011 12:33 AM
>> 
>> To: Vishwas Manral
>> 
>> Cc: [e-mail]
>> 
>> Subject: Re: [armd] Fwd: New Version Notification for
>> draft-wkumari-dcops-l3-vmmobility-00.txt
>> 
>> On Aug 11, 2011, at 9:05 PM, Vishwas Manral wrote:
>> 
>>> > Hi Warren,
>> 
>>> > 
>> 
>>> > It is good to see the draft.
>> 
>> And it's good to see that someone has already read it :-P
>> 
>>> > I guess you can position this as an informational draft of how network
>>> operators are using
>> 
>> techniques to overcome big layer-2 issues (the ARP issues themselves are
>> resolved by the directory
>> 
>> mechanism). I think this approach has been discussed in VNRG for some time
>> now. May be you can use the
>> 
>> terms defined there.
>> 
>> Yup.
>> 
>>> > 
>> 
>>> > Also if I understand right, we are still using a big layer-2 network, only
>>> thing by using a
>> 
>> heirarchical overlay network we are doing away with the actual network
>> devices switches/ routers using
>> 
>> Layer-2?
>> 
>> Kinda -- the very high level view is that datacenters can be built with L3
>> designs (L2 designs, or
>> 
>> whatever design happens to exists), and then separate overlay networks, one
>> per customer.
>> 
>>> > 
>> 
>>> > As is well known "Overlay networks" have issues with scalability, which
>>> become worse as the number
>> 
>> of overlays increases (think of all IPsec VPN's).
>> 
>> Yes, but as the overlay is only built between the VM hosts (and only *those*
>> that are actually
>> 
>> communicating), the number of overlays that needs to be tracked *per device*
>> is fairly limited. Also,
>> 
>> the overlays are built on general purpose servers (and are invisible to the
>> network) and so you don't
>> 
>> have all of the standard scaling issues that happen with network devices...
>> 
>>> > How do we deal with the same? Also what about issues with fragmentation/
>>> management of hypervisor
>> 
>> based shim etc?
>> 
>> Yup, there is still lots of work to be done on specifying things like that --
>> who does fragmentation /
>> 
>> reassembly, a standard protocol for populating the directory, how the DS
>> informs the shims that a VM
>> 
>> has moved, etc are all (currently) coverd by hand-waving -- I do actually
>> have answers on most of
>> 
>> that, but I don't have them written down..
>> 
>>> > 
>> 
>>> > It would be good if you could give all such details.
>> 
>>> > 
>> 
>>> > Thanks,
>> 
>>> > Vishwas
>> 
>>> > On Thu, Aug 11, 2011 at 7:44 PM, Warren Kumari <[e-mail]> wrote:
>> 
>>> > Hi there all,
>> 
>>> > 
>> 
>>> > At two previous meetings (IETF in Quebec and NANOG in Denver) I threw a
>>> bit of a hissy fit about how
>> 
>> VM mobility can be implemented without the need for L2 between the hosts.
>> 
>>> > 
>> 
>>> > So, here is a very drafty draft, outlining the principle at a high level.
>> 
>>> > 
>> 
>>> > I have no real plans for this draft, it's more just an explanation of the
>>> idea.
>> 
>>> > 
>> 
>>> > W
>> 
>>> > 
>> 
>>> > 
>> 
>>> > Begin forwarded message:
>> 
>>> > 
>> 
>>>> > > From: [e-mail]
>> 
>>>> > > Date: August 11, 2011 5:53:35 PM PDT
>> 
>>>> > > To: [e-mail]
>> 
>>>> > > Cc: [e-mail], [e-mail]
>> 
>>>> > > Subject: New Version Notification for
>>>> draft-wkumari-dcops-l3-vmmobility-00.txt
>> 
>>>> > >
>> 
>>>> > > A new version of I-D, draft-wkumari-dcops-l3-vmmobility-00.txt has been
>>>> successfully submitted by
>> 
>> Warren Kumari and posted to the IETF repository.
>> 
>>>> > >
>> 
>>>> > > Filename:      draft-wkumari-dcops-l3-vmmobility
>> 
>>>> > > Revision:      00
>> 
>>>> > > Title:                 Virtual Machine mobility in L3 Networks.
>> 
>>>> > > Creation date:         2011-08-11
>> 
>>>> > > WG ID:                 Individual Submission
>> 
>>>> > > Number of pages: 8
>> 
>>>> > >
>> 
>>>> > > Abstract:
>> 
>>>> > >   This document outlines how Virtual Machine mobility can be
>> 
>>>> > >   accomplished in datacenter networks that are based on L3
>> 
>>>> > >   technologies.  It is not really intended to solve (or fully define)
>> 
>>>> > >   the problem, but rather to outline it at a very high level to
>> 
>>>> > >   determine if standardization within the IETF makes sense.
>> 
>>>> > >
>> 
>>>> > >
>> 
>>>> > >
>> 
>>>> > >
>> 
>>>> > > The IETF Secretariat
>> 
>>>> > >
>> 
>>> > 
>> 
>>> > _______________________________________________
>> 
>>> > armd mailing list
>> 
>>> > [e-mail]
>> 
>>> > https://www.ietf.org/mailman/listinfo/armd
>> 
>>> > 
>> 
>> _______________________________________________
>> 
>> armd mailing list
>> 
>> [e-mail]
>> 
>> https://www.ietf.org/mailman/listinfo/armd
> 
>  
> 
> _______________________________________________
> 
> armd mailing list
> 
> [e-mail]
> 
> https://www.ietf.org/mailman/listinfo/armd
> 
>