Re: [armd] address resolution requirement from hosts to overlay edge nodes. Any opinion?

[Anoop Ghanwani <[e-mail]>]

I think this is a very interesting problem.  If BOTH the MAC-to-IP binding,
and the MAC-to-tunnel-end-point binding can be resolved using a directory
service, it would eliminate the need for IP multicast support from the network,
provided there are no multicast applications.

If both cannot be done and ARP/ND must still be used to find the MAC-to-IP
binding, then I don't see much value in a directory service to get only the
MAC-to-tunnel-end-point mapping since that can be inferred from the ARP
traffic itself (as long as a MAC address sits behind only a single
tunnel end point).

Anoop

On Fri, Feb 10, 2012 at 1:28 PM, Linda Dunbar <[e-mail]> wrote:
> We all believe that the current trend for Data Center network is going
> towards overlay network, be it TRILL, MAC-in-MAC (SPB), NV03, etc. In
> Overlay network, each Overlay Border Node (OBN) has to map the destination
> address of a data packet to an egress Overlay Border Node. Very much like
> ARP/ND which is to resolve physical addresses (i.e. MAC Addresses) from
> target IP addresses.
>
>
>
> Here are some distinct characteristics of hosts in Data Center:
>
> 1.  Even though the communication between DC hosts to external peers may be
> small in volume comparing with the east-west (intra-data center) traffic,
> majority of hosts in data center still do communicate with external peers.
>
>
>
> 2.  Traffic entering/exiting the Data Center Overlay could be via multiple
> Overlay Border nodes.
>
>
>
> 3.  The placement of VMs/hosts to server racks is orchestrated by Management
> Entities. So Overlay Border Nodes can, at least in theory, get the hosts <->
> OverlayBorderNode mapping information from directory server(s). There could
> be multiple directory servers serving a very large data center.
>
>
>
> From the very high level view, the directory providing mapping from hosts to
> Overlay Border Node seems very straight forward. However, if you look
> deeper, following issues come out:
>
>
>
> -   When hosts can enter or exit the overlay network via multiple OBNs, is
> it necessary for each OBN to be aware of which egress OBN can reach the
> target? Or, is it necessary for each OBN to advertise its connectivity
> status of all the attached hosts to all other OBNs?
>
>
>
> -   When migration is orchestrated by management entity (or entities), there
> could be multiple instances of directory servers
>
> o   is it necessary for each directory server to have full information? What
> if some directory servers only have partial information (for very large DC
> environment)?
>
> o   Is it necessary for each OBN to report connectivity status of all the
> attached hosts to directory servers?
>
> o   Should resolution requests be load balanced among them?
>
>
>
> -   A data frame arriving at OBN normally might have an VID in the data
> frame, the egress OBN might have a different VID value for the  same virtual
> network instance. Original VID loses its meaning when traversing to Egress
> overlay border. Proper Ingress VID -> overlay network instance ID - >to
> Egress VID  resolution (or mapping) is needed.
>
>
>
> -   Etc.
>
>
>
> It was suggested that ARMD WG should have a requirement draft on Address
> Resolution from data center host addresses to Overlay Border Node addresses
> so that the industry can have a common requirement for various types of
> overlay for data center environment.
>
>
>
> A draft on this topic could potentially trigger more input on various
> constraints or requirement for hosts <-> OBN mapping in data center
> environment.
>
>
>
> Any opinion on this?
>
>
>
> Linda Dunbar
>
>
>
>
> _______________________________________________
> armd mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/armd
>