Subject: [armd] ARMD

From: "Susan Hares" <[email-masked]>
Date: Thu, 6 Oct 2011 12:28:41 -0400

Thomas:
 
Comments below. Does this help you refine the problem statement on pain
points? 
By the way, will we be seeing the first draft of the problems statement this
week. 
 
Sue 
 
------
 
Sue,
 
There is a third layer/level of addressing.
 
The addresses a VM uses internal to the overlay are private (or can
be, but that is not required).
 
If the VM needs to communicate with the outside world, it will need a
public address. This can be done via standard NAT (as is done today,
if the VM is not using the public address directly). 
 
I would expect the NAT translation to be done at the edge of the
overlay, i.e., as part of being decapsulated in order to exit the
overlay.
---[Sue] NAT works this way, but it is also important to provide an
---[Sue] non-NAT solution if you are using global addresses.  
 
I.e., if a packet exits an overlay network, the addresses it uses
outside of the overlay needs to have meaning outside of the
overlay. If the VM address (as used within the overlay) is a globally
unique public address, there is nothing to do. If it is a private
address, you'd need to NAT it.
--- [Sue] agreed if private address. 
 
The bigger point is that when a packet leaves on overlay, its a normal
IP packet (no longer encapsulated). Whatever techniques are used
currently with IP can then still be used outside of the overlay.
 
Make sense?
--- yes it makes sense with the caveats on NAT/Non-NAT. 

Thomas
 
> Thomas:
 
> Linda's comment about a applications which communicate outside the data
center indicates that the address outside the data center are likely not to
share the IP addresses within the data center.
 
> This is a scenario we have heard from Igor at yahoo.  It is a scenario I
have seen in some goggle slides at nanog.
 
> External addresses in these scenarios need to be resolved.
 
> Does this make sense?
 
> If so, we can go on to dc connected by by mpls le vpns.
 
> Sue
> Sent via BlackBerry by AT&T
 
> -----Original Message-----
> From: Thomas Narten <narten at us.ibm.com>
> Sender: armd-bounces at ietf.org
> Date: Tue, 04 Oct 2011 12:09:28 
> To: Linda Dunbar<linda.dunbar at huawei.com>
> Cc: armd at ietf.org<armd at ietf.org>
> Subject: Re: [armd] Call for Participation: Using IP Overlays to provide
L2
>       Virtualization
 
> Hi Linda.
 
> > I agree that "Overlay push some of the L2 scaling concerns" in your
> > draft. But this statement should not be listed under the sub-section
> > of ARMD.
 
> I will tweak this in the next version.
 
> > Overlay is to hide VMs' addresses from network interior
> > nodes.
 
> Agreed.
 
> > Address Resolution is to map VMs' IP addresses to physical
> > addresses.
 
> Yes, but. Address resolution is also a sort of generic term and can
> mean more than this. Anytime you have to map an "upper layer" address
> to a "lower layer" address, you need address resolution or address
> mapping. We usually think of ARP/ND doing address resolution between
> an IP address and a physical (ethernet) address.
 
> But, with overlays, you will have multiple layers doing address
> mapping. In the overlay context, you will have the VM's IP address,
> which needs to be mapped into the infrastructure IP address where that
> VM current resides (and where packets can be tunneled to). That is
> something that is handled at the overlay level. Separately, at some
> point, a router/gateway will need to map that infrastructure IP
> address into a physical address (just as is done today). I assume this
> is what you mean by "address resolution".
 
> The "mapping function" that the problem statement draft uses is a form
> of Address Resolution.
 
> > Applications (or VMs) within Data center need to communicate with
> > peers outside data center. Regardless of overlay is deployed within
> > the data center or not, the Gateway routers still need to resolve
> > physical addresses for all VMs which have external communications.
 
> I'm not sure I understand this fully (see above). There are two
> IP addresses in use (private within the overlay and
> infrastructure). Which IP addresses do you mean above?
 
> > Therefore, Address resolution and Overlay are orthogonal to each
> > other.
 
> If you mean address resolution as in the ARP/ND sense vs. "mappings"
> in the overlay sense, I agree.
 
> > Overlay can only make address resolution more complex,
> > because Gateway router not only needs to resolve physical address
> > for each VM's IP, it also needs to resolve the overlay edge address
> > for each VM's IP.
 
> Yes. If the gateway is at the edge of the overlay, it will need to
> encap/decap packets and perform address mappings. Separately, it will
> need to do address resolution for infrastructure addresses.
 
> Thomas
> _______________________________________________
> armd mailing list
> armd at ietf.org
> https://www.ietf.org/mailman/listinfo/armd