Subject: [dc] new drafts

From: "Ashish Dalela (adalela)" <[email-masked]>
Date: Fri, 30 Dec 2011 16:30:45 +0530

Folks,

I have posted 2 drafts for this group to review.

http://www.ietf.org/id/draft-dalela-dc-requirements-00.txt

http://www.ietf.org/id/draft-dalela-dc-approaches-00.txt

The first draft captures 10 requirements / problems to be addressed in
the datacenter space. These were described over the email earlier. 

The second draft discusses various approaches to addressing these
requirements. This draft analyzes the scaling properties of various
approaches and makes recommendations at the end for future work that can
be taken by this group.

Request your feedback and discussion.

Thanks, Ashish

---

From: Aldrin Isaac <[email-masked]>
Date: Fri, 30 Dec 2011 17:37:03 -0500

Hi Ashish,

How would you address gratuitous ARP when using the hierarchical MAC addressing with a registry to store MAC-IP bindings?

Also, when using MAC prefixes in complex L2VPN topologies how could we address the risk of a hub forwarding into the wrong spoke context on the leaf switch?  Each egress port on the leaf switch may be in a different context (ex: EVI in EVPN).

Thanks -- aldrin

On Dec 30, 2011, at 6:00 AM, Ashish Dalela (adalela) wrote:

> The first draft captures 10 requirements / problems to be addressed in the datacenter space. These were described over the email earlier.
>  
> The second draft discusses various approaches to addressing these requirements. This draft analyzes the scaling properties of various approaches and makes recommendations at the end for future work that can be taken by this group.
>  
> _______________________________________________
> dc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dc

---

From: "Ashish Dalela (adalela)" <[email-masked]>
Date: Sat, 31 Dec 2011 07:24:13 +0530

Hi Aldrin,

>> How would you address gratuitous ARP when using the hierarchical MAC
addressing with a registry to store MAC-IP bindings?

We should ideally have a protocol that maps ARP messages into the
registry and vice versa. Why new protocol? Greater security and
reliability plus avoiding ARP broadcasts. Gratuitous ARP doesn't have an
acknowledge, so if you want to perform some actions based on this, you
need to get an "acknowledge" for it. Gratuitous ARP can get dropped. 

The other issue is that a user can misuse it do MAC hijacking. But if
you have a hierarchical MAC you can't hijack because network knows your
location. Things like dot1x which solved these issues in the campus
space are not used in datacenter. 

>> Also, when using MAC prefixes in complex L2VPN topologies how could
we address the risk of a hub forwarding into the wrong spoke context on
the leaf switch?  Each egress port on the leaf switch may be in a
different context (ex: EVI in EVPN).

We should avoid building any kind of VRF at the control plane, because
that's just not scalable. With hierarchical MAC, you have global L2
addressing so from a forwarding perspective it looks like static L3
routing and anyone can send packets anywhere. When a VM moves, this
doesn't change the global forwarding table (unless a virtual switch
moves - which is also possible). To segment customers we tag packets
with some tenant id, and it will be dropped at destination. The tags
will be present both at ingress and egress ports.

There are only two possible approaches - drop at source or drop at
destination. If we try to drop at source, we need a mapping to which
destinations are allowed (too many, and the scale is unpredictable). If
we drop at destination, we still need to know which destinations are
allowed, but that's just comprised of local host entries (no new
entries). 

I'm not totally certain if I answered your question, so let me know.

Thanks, Ashish

From: Aldrin Isaac [mailto:[email-masked]] 
Sent: Saturday, December 31, 2011 4:07 AM
To: Ashish Dalela (adalela)
Cc: [email-masked]
Subject: Re: [dc] new drafts

Hi Ashish,

How would you address gratuitous ARP when using the hierarchical MAC
addressing with a registry to store MAC-IP bindings?

Also, when using MAC prefixes in complex L2VPN topologies how could we
address the risk of a hub forwarding into the wrong spoke context on the
leaf switch?  Each egress port on the leaf switch may be in a different
context (ex: EVI in EVPN).

Thanks -- aldrin

 

Folks,

Thanks, Ashish