Subject: Re: [armd] Call for Participation: Using IP Overlays to provide L2 Virtualization

From: Linda Dunbar <[email-masked]>
Date: Tue, 04 Oct 2011 14:48:51 +0000

Thomas and Murari, 

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.  

Overlay is to hide VMs' addresses from network interior nodes. Address Resolution is to map VMs' IP addresses to physical addresses. 
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. 

Therefore, Address resolution and Overlay are orthogonal to each other. 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. 

Do you view it differently? I would like to know your view. 

Thanks, Linda

---------------------------------------

6. Related Work
6.1. ARMD
ARMD is chartered to look at data center scaling issues with a focus
on address resolution. ARMD is currently chartered to develop a
problem statement and is not currently developing solutions. While
an overlay-based approach may address some of the "pain points" that
have been raised in ARMD (e.g., better support for multitenancy), an
overlay approach may also push some of the L2 scaling concerns (e.g.,
excessive flooding) to the IP level (flooding via IP multicast).
Analysis will be needed to understand the scaling trade offs of an
overlay based approach compared with existing approaches. On the
other hand, existing IP-based approaches such as proxy ARP may help
mitigate some concerns.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Thomas Narten
> Sent: Friday, September 30, 2011 7:04 PM
> Subject: [armd] Call for Participation: Using IP Overlays to provide L2
> Virtualization
> 
> ------- Blind-Carbon-Copy
> 
> To: [email-masked]
> cc: [email-masked]
> Subject: Call for Participation: Using IP Overlays to provide L2
> Virtualization
> In-reply-to: <[email-masked]>
> References: <[email-masked]>
> Comments: In-reply-to IETF Secretariat <[email-masked]>
>    message dated "Thu, 29 Sep 2011 14:45:02 -0700."
> Date: Fri, 30 Sep 2011 20:03:34 -0400
> From: Thomas Narten <[email-masked]>
> 
> A new mailing list has been set up to explore possible IETF work in
> the area of providing L2 network virtualization service over an L3
> (IP) overlay network.
> 
> As background, there are a number of drafts that relate to this area,
> including:
> 
>     http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-00
>     http://tools.ietf.org/html/draft-sridharan-virtualization-nvgre-00
>     http://tools.ietf.org/html/draft-wkumari-dcops-l3-vmmobility-00
> 
> I've put together a first-cut at a problem statement that focuses on
> the issues and potential work areas, without getting into solution
> specifics.  See:
> 
>     http://tools.ietf.org/html/draft-narten-nvo3-overlay-problem-
> statement-00.txt
> 
> There have also been some related vendor announcements and
> presentations as well (these are ones I happen to know of, there are
> surely others). For example:
> 
>      http://blogs.cisco.com/datacenter/introducing-vxlan/
> 
> 
> http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9902/white
> _paper_c11-685115.html
> 
>      http://blogs.vmware.com/console/2011/08/towards-virtualized-
> networking-for-the-cloud.html
> 
>      http://channel9.msdn.com/Events/BUILD/BUILD2011/SAC-442T
> 
> The list is called nvo3, for "Network Virtualization Over L3", aka
> N-Vee-Oh-3 (we'll see how well that acronym sticks...).
> 
> I've put in a formal request to hold a BOF in Taipai, so we can
> explore whether it makes sense to form a WG in this area.
> 
> Subscription information for the mailing list can be found at
> 
>      List address: [email-masked]
>      Archive: http://www.ietf.org/mail-
> archive/web/nvo3/current/maillist.html
>      To subscribe: https://www.ietf.org/mailman/listinfo/nvo3
> 
> I look forward to your participation!
> 
> Thomas
> 
> ------- End of Blind-Carbon-Copy
> _______________________________________________
> armd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/armd

---

From: Thomas Narten <[email-masked]>
Date: Tue, 04 Oct 2011 12:09:28 -0400

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

---

From: Thomas Narten <[email-masked]>
Date: Wed, 05 Oct 2011 16:00:54 -0400

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.

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.

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?

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

> From: Thomas Narten <[email-masked]>
> Sender: [email-masked]
> Date: Tue, 04 Oct 2011 12:09:28 
> To: Linda Dunbar<[email-masked]>
> Cc: [email-masked]<[email-masked]>
> Subject: Re: [armd] Call for Participation: Using IP Overlays to provide L2
> 	Virtualization