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

[Mike McBride <[e-mail]>]

Anoop,

On Fri, Feb 10, 2012 at 6:12 PM, Anoop Ghanwani <[e-mail]> wrote:
> 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.

A directory could eliminate any reliance upon IP Multicast for MAC to
tunnel end point binding but would not eliminate the need for IP
Multicast in the network. You would still want the dynamic nature of
joining and pruning along with the efficient data delivery across the
overlay network. Good solutions will take mcast applications into
proper consideration.

> 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).

You are probably right but, either way, a directory approach is
probably worth further exploration.

mike

> 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
>>
> _______________________________________________
> armd mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/armd