Subject: Re: [arp222] ARP222 Charter statement and milestones

From: Linda Dunbar <[email-masked]>
Date: Fri, 13 Aug 2010 14:42:14 -0500

I forgot to clarify in my previous email that the charter statement and
milestones posted is for soliciting feedback before submitting to IESG to
request for a BOF for IETF79 (Beijing).  

We think the problem domain belongs to Internet Area. Therefore, once I get
your feedback, I will send the Charter Statement and milestones to the
Internet ADS (Ralph and Jari) to request for a BOF at the IETF79 (Beijing).
Our target is to have a working group by IETF 80.   

Linda Dunbar

  _____  

From: Linda Dunbar [mailto:[email-masked]] 
Sent: Thursday, August 12, 2010 6:14 PM
To: [email-masked]'
Subject: ARP222 Charter statement and milestones

Thank you all for coming to ARP222 Bar BOF at the 78th IETF and giving us
comments and suggestions on and between sessions. 

I put together the initial ARP222 Charter Statement and Milestones. Please
provide comments and suggestions.  

 

ARP 222: Address Resolution Protocol for Layer 2 to Anything to Layer 2

Description of Working Group:

As server virtualization is introduced to data centers, the number of hosts
in a data center can grow dramatically because each physical server, which
used to host one end-station, now can host many end-stations, or Virtual
Machines (20, 30, or hundreds of). Virtual Machines, with its flexible
add/delete and mobility features, not only makes it possible for achieving
better performance and better utilization on servers, they are also a very
important building block for Cloud Computing service to offer virtual
subnets and virtual hosts. The virtual subnets offered by Cloud Computing
service could allow clients to define their own subnets with its own IP
addresses and policies. 

This rapid growth of virtual hosts could tremendously impact to networks and
servers. One huge issue is frequent address resolution (IPv4) or neighbor
discovery (IPv6) requests from hosts. All hosts frequently send out those
requests due to their cache being aged out in minutes. With tens of
thousands of hosts (each with a distinct MAC address) in one Data Center,
the amount of address resolution packets per second is potentially more than
1,000 to 10,000/second. This rate imposes tremendous computational burden on
many hosts. 

Another big issue associated with huge number of virtual hosts in a data
center is potentially duplicated IP addresses within one VLAN which will
make traditional ARP or ND not working properly. Some load balance design
requires multiple hosts serving the same application to have the same IP
address but with different MAC addresses. Cloud Computing service could
allow users to have their own subnets with IP addresses and self defined
policies among those subnets. Some network designs need to put multiple
client subnets into one VLAN because the number of client subnets could be
in hundreds of thousands which is much more than 4095 VLANs. Under this
scenario, there could be duplicated IP addresses which are from different
client subnets ending up in one VLAN.  

The goal of this working group is to develop interoperable solutions to
solve those problems.  

The design should consider the following properties:

*        All solutions developed by ARP222 WG should not expect any behavior
changes on hosts, applications, or Virtual Machines being deployed in the
market. 

*        All solutions developed should not break DHCP. 

*        Evaluating the impact to IPv6 ND, and develop solutions accordingly
if needed. 

*        Should consider variety of solutions, including directory based,
proxy based, or cache based solutions. 

*        Include analysis of security concerns of IPv4 ARP requests from
malicious users. Evaluating potential security solutions and conclude if the
security threat can justify solutions. 

*        ARP222 assumes the direct links to individual hosts and virtual
machines are IEEE802.3 Ethernet links.  

*        Should consider scenarios of one Ethernet network being
interconnected by another network, which can be L2VPN, pure IP, Ethernet, or
others. 

*        Should consider address resolution solutions for one VLAN with
small number of duplicated IP addresses.  

Here are the items which should not be in the scope of the working group: 

*        Re-define DHCP behavior

*        Re-define security concern to IPv6 ND 

*        Direct links from hosts and virtual hosts are non Ethernet links 

*         

Goals and Milestones:

*        Charter statement

*        Problem Statements

*        Gap analysis 

*        Study of NHRP (RFC2332) & SCSP,  and their applicability to
Ethernet networks

*        Study and Analysis of MOOSE as a potential solution

*        Study and Analysis of SEATTLE as a potential solution.

Best Regards, Linda Dunbar

---

From: Anoop Ghanwani <[email-masked]>
Date: Fri, 13 Aug 2010 14:02:13 -0700

Hi Linda,

Would it be possible to provide references to actual protocols
that require duplicate IP addresses behind different MAC addresses?

Anoop

From: [email-masked] [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Friday, August 13, 2010 12:42 PM
To: [email-masked]
Subject: Re: [arp222] ARP222 Charter statement and milestones

I forgot to clarify in my previous email that the charter statement and milestones posted is for soliciting feedback before submitting to IESG to request for a BOF for IETF79 (Beijing).
We think the problem domain belongs to Internet Area. Therefore, once I get your feedback, I will send the Charter Statement and milestones to the Internet ADS (Ralph and Jari) to request for a BOF at the IETF79 (Beijing). Our target is to have a working group by IETF 80.

Linda Dunbar

________________________________
From: Linda Dunbar [mailto:[email-masked]]
Sent: Thursday, August 12, 2010 6:14 PM
To: [email-masked]'
Subject: ARP222 Charter statement and milestones

Thank you all for coming to ARP222 Bar BOF at the 78th IETF and giving us comments and suggestions on and between sessions.

I put together the initial ARP222 Charter Statement and Milestones. Please provide comments and suggestions.

As server virtualization is introduced to data centers, the number of hosts in a data center can grow dramatically because each physical server, which used to host one end-station, now can host many end-stations, or Virtual Machines (20, 30, or hundreds of). Virtual Machines, with its flexible add/delete and mobility features, not only makes it possible for achieving better performance and better utilization on servers, they are also a very important building block for Cloud Computing service to offer virtual subnets and virtual hosts. The virtual subnets offered by Cloud Computing service could allow clients to define their own subnets with its own IP addresses and policies.

This rapid growth of virtual hosts could tremendously impact to networks and servers. One huge issue is frequent address resolution (IPv4) or neighbor discovery (IPv6) requests from hosts. All hosts frequently send out those requests due to their cache being aged out in minutes. With tens of thousands of hosts (each with a distinct MAC address) in one Data Center, the amount of address resolution packets per second is potentially more than 1,000 to 10,000/second. This rate imposes tremendous computational burden on many hosts.

Another big issue associated with huge number of virtual hosts in a data center is potentially duplicated IP addresses within one VLAN which will make traditional ARP or ND not working properly. Some load balance design requires multiple hosts serving the same application to have the same IP address but with different MAC addresses. Cloud Computing service could allow users to have their own subnets with IP addresses and self defined policies among those subnets. Some network designs need to put multiple client subnets into one VLAN because the number of client subnets could be in hundreds of thousands which is much more than 4095 VLANs. Under this scenario, there could be duplicated IP addresses which are from different client subnets ending up in one VLAN.

The goal of this working group is to develop interoperable solutions to solve those problems.
The design should consider the following properties:
*         All solutions developed by ARP222 WG should not expect any behavior changes on hosts, applications, or Virtual Machines being deployed in the market.
*         All solutions developed should not break DHCP.
*         Evaluating the impact to IPv6 ND, and develop solutions accordingly if needed.
*         Should consider variety of solutions, including directory based, proxy based, or cache based solutions.
*         Include analysis of security concerns of IPv4 ARP requests from malicious users. Evaluating potential security solutions and conclude if the security threat can justify solutions.
*         ARP222 assumes the direct links to individual hosts and virtual machines are IEEE802.3 Ethernet links.
*         Should consider scenarios of one Ethernet network being interconnected by another network, which can be L2VPN, pure IP, Ethernet, or others.
*         Should consider address resolution solutions for one VLAN with small number of duplicated IP addresses.

Goals and Milestones:
*         Charter statement
*         Problem Statements
*         Gap analysis
*         Study of NHRP (RFC2332) & SCSP,  and their applicability to Ethernet networks
*         Study and Analysis of MOOSE as a potential solution
*         Study and Analysis of SEATTLE as a potential solution.

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 13 Aug 2010 16:43:35 -0500

Anoop, 

The scenario is Cloud Computing service selling client controlled (virtual)
subnets to clients. All the (virtual) hosts within the client controlled
subnets have their own IP addresses. The communications among those
(virtual) hosts are client specific. There might be same IP addresses in
different client controlled subnets. All those hosts will be assigned as a
virtual machine to a physical server and assigned to a VLAN in the actual
network in data center(s). There will be cases when one VLAN ends up having
(virtual) hosts with same IP address (but different MAC address). 

Linda 

  _____  

From: Anoop Ghanwani [mailto:[email-masked]] 
Sent: Friday, August 13, 2010 4:02 PM
To: Linda Dunbar; [email-masked]
Subject: RE: [arp222] ARP222 Charter statement and milestones

Hi Linda,

Anoop

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Linda Dunbar
Sent: Friday, August 13, 2010 12:42 PM
To: [email-masked]
Subject: Re: [arp222] ARP222 Charter statement and milestones

Linda Dunbar

  _____  

 

*     Evaluating the impact to IPv6 ND, and develop solutions accordingly if
needed. 

*     Should consider variety of solutions, including directory based, proxy
based, or cache based solutions. 

*     Should consider scenarios of one Ethernet network being interconnected
by another network, which can be L2VPN, pure IP, Ethernet, or others. 

*     Should consider address resolution solutions for one VLAN with small
number of duplicated IP addresses.  

*      

Goals and Milestones:

*     Charter statement

*     Problem Statements

*     Gap analysis 

*     Study of NHRP (RFC2332) & SCSP,  and their applicability to Ethernet
networks

---

From: Anoop Ghanwani <[email-masked]>
Date: Fri, 13 Aug 2010 16:19:16 -0700

Linda,

Do broadcasts from one client controlled subnet show up
in a different client controlled subnet?

Anoop

From: Linda Dunbar [mailto:[email-masked]]
Sent: Friday, August 13, 2010 2:44 PM
To: Anoop Ghanwani; [email-masked]
Subject: RE: [arp222] ARP222 Charter statement and milestones

Anoop,

The scenario is Cloud Computing service selling client controlled (virtual) subnets to clients. All the (virtual) hosts within the client controlled subnets have their own IP addresses. The communications among those (virtual) hosts are client specific. There might be same IP addresses in different client controlled subnets. All those hosts will be assigned as a virtual machine to a physical server and assigned to a VLAN in the actual network in data center(s). There will be cases when one VLAN ends up having (virtual) hosts with same IP address (but different MAC address).

Linda

Hi Linda,

Anoop

Linda Dunbar

Goals and Milestones:
*         Charter statement
*         Problem Statements
*         Gap analysis

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 23 Aug 2010 16:32:51 -0500

Anoop, 

No, it shouldn't. 

Linda

  _____  

From: Anoop Ghanwani [mailto:[email-masked]] 
Sent: Friday, August 13, 2010 6:19 PM
To: Linda Dunbar; [email-masked]
Subject: RE: [arp222] ARP222 Charter statement and milestones

Linda,

Anoop

Anoop, 

Linda 

  _____  

Hi Linda,

Anoop

Linda Dunbar

  _____  

 

* Include analysis of security concerns of IPv4 ARP requests from malicious
users. Evaluating potential security solutions and conclude if the security
threat can justify solutions. 

* ARP222 assumes the direct links to individual hosts and virtual machines
are IEEE802.3 Ethernet links.  

* Should consider scenarios of one Ethernet network being interconnected by
another network, which can be L2VPN, pure IP, Ethernet, or others. 

*  

Goals and Milestones:

* Charter statement

* Problem Statements

* Gap analysis

---

From: Anoop Ghanwani <[email-masked]>
Date: Mon, 23 Aug 2010 14:36:15 -0700

Linda,

If it broadcasts from one client controlled subnet do not
show up in another client controlled subnet, then this
should be a non-issue, no?

Anoop

From: Linda Dunbar [mailto:[email-masked]]
Sent: Monday, August 23, 2010 2:33 PM
To: Anoop Ghanwani; [email-masked]
Subject: RE: [arp222] ARP222 Charter statement and milestones

Anoop,

No, it shouldn't.

Linda

Linda,

Anoop

Anoop,

Linda

Hi Linda,

Anoop

Linda Dunbar

Goals and Milestones:
*         Charter statement
*         Problem Statements
*         Gap analysis

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 24 Aug 2010 14:31:58 -0500

Anoop, 

The issue of duplicated IP addresses comes up when there are more client
controlled subnets than the number of VLANs. The number of client controlled
subnets could be in hundreds of thousands, but there are only 4095 VLANs
within one Layer 2. Then you might need to assign multiple client controlled
subnets in one VLAN. Under this scenario, duplicated IP will be an issue. 

Linda 

  _____  

From: Anoop Ghanwani [mailto:[email-masked]] 
Sent: Monday, August 23, 2010 4:36 PM
To: Linda Dunbar; [email-masked]
Subject: RE: [arp222] ARP222 Charter statement and milestones

Linda,

Anoop

Anoop, 

No, it shouldn't. 

Linda

  _____  

Linda,

Anoop

Anoop, 

Linda 

  _____  

Hi Linda,

Anoop

Linda Dunbar

  _____  

 

*         

Goals and Milestones:

*        Charter statement

*        Problem Statements

*        Gap analysis

---

From: Anoop Ghanwani <[email-masked]>
Date: Tue, 24 Aug 2010 13:36:56 -0700

Linda,

I think the key piece of information that I'm missing is how
the layer 2 forwarding takes place in a particular client-controlled
subnet.  If it's just regular bridging, we will have leakage of traffic
between subnets that are in the same VLAN.  In that case, I think
it would be hard to solve the duplicate address problem.  If there
is some kind of new forwarding happens that ensures that there
is never leakage between the subnets, and the two subnets never
need to talk to each other unless they use a NAT, then there
is nothing to be solved...that problem already exists today with
VRFs.  But I don't know of such a layer 2 device and that's why
I was asking for more details.

Anoop

From: Linda Dunbar [mailto:[email-masked]]
Sent: Tuesday, August 24, 2010 12:32 PM
To: Anoop Ghanwani; [email-masked]
Subject: RE: [arp222] ARP222 Charter statement and milestones

Anoop,

The issue of duplicated IP addresses comes up when there are more client controlled subnets than the number of VLANs. The number of client controlled subnets could be in hundreds of thousands, but there are only 4095 VLANs within one Layer 2. Then you might need to assign multiple client controlled subnets in one VLAN. Under this scenario, duplicated IP will be an issue.

Linda

Linda,

Anoop

Anoop,

No, it shouldn't.

Linda

Linda,

Anoop

Anoop,

Linda

Hi Linda,

Anoop

Linda Dunbar

Goals and Milestones:
*         Charter statement
*         Problem Statements
*         Gap analysis

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 24 Aug 2010 17:28:39 -0500

Anoop, 

I am referring to duplicated IP addresses but with different MAC addresses. 

Linda

  _____  

From: Anoop Ghanwani [mailto:[email-masked]] 
Sent: Tuesday, August 24, 2010 3:37 PM
To: Linda Dunbar; [email-masked]
Subject: RE: [arp222] ARP222 Charter statement and milestones

Linda,

Anoop

Anoop, 

Linda 

  _____  

Linda,

Anoop

Anoop, 

No, it shouldn't. 

Linda

  _____  

Linda,

Anoop

Anoop, 

Linda 

  _____  

Hi Linda,

Anoop

Linda Dunbar

  _____  

 

*         

Goals and Milestones:

*        Charter statement

*        Problem Statements

*        Gap analysis

---

From: Anoop Ghanwani <[email-masked]>
Date: Tue, 24 Aug 2010 15:30:35 -0700

Linda,

Yes, I understand...and the concerns in my previous reply
are with that in mind.

Anoop

From: Linda Dunbar [mailto:[email-masked]]
Sent: Tuesday, August 24, 2010 3:29 PM
To: Anoop Ghanwani; [email-masked]
Subject: RE: [arp222] ARP222 Charter statement and milestones

Anoop,

Linda

Linda,

Anoop

Anoop,

Linda

Linda,

Anoop

Anoop,

No, it shouldn't.

Linda

Linda,

Anoop

Anoop,

Linda

Hi Linda,

Anoop

Linda Dunbar

Goals and Milestones:
*         Charter statement
*         Problem Statements
*         Gap analysis

---

From: Benson Schliesser <[email-masked]>
Date: Tue, 24 Aug 2010 19:39:31 -0500

This is pretty much what a VLAN solves for you; it multiplexes link-layer segments.

The scenario you've described is missing an abstraction layer.  You're apparently trying to get around the need for VLANs, rather than improve their scale.  I'd suggest this really is not the right way to think about VLAN scale limitations.

Cheers,
-Benson

On 24 Aug 10, at 5:28 PM, Linda Dunbar wrote:

> I think the key piece of information that I’m missing is how
> subnet.  If it’s just regular bridging, we will have leakage of traffic
> VRFs.  But I don’t know of such a layer 2 device and that’s why
> No, it shouldn’t.
> ·        All solutions developed by ARP222 WG should not expect any behavior changes on hosts, applications, or Virtual Machines being deployed in the market.
> ·        All solutions developed should not break DHCP.
> ·        Evaluating the impact to IPv6 ND, and develop solutions accordingly if needed.
> ·        Should consider variety of solutions, including directory based, proxy based, or cache based solutions.
> ·        Include analysis of security concerns of IPv4 ARP requests from malicious users. Evaluating potential security solutions and conclude if the security threat can justify solutions.
> ·        ARP222 assumes the direct links to individual hosts and virtual machines are IEEE802.3 Ethernet links. 
> ·        Should consider scenarios of one Ethernet network being interconnected by another network, which can be L2VPN, pure IP, Ethernet, or others.
> ·        Should consider address resolution solutions for one VLAN with small number of duplicated IP addresses. 
>  
> ·        Re-define DHCP behavior
> ·        Re-define security concern to IPv6 ND
> ·        Direct links from hosts and virtual hosts are non Ethernet links
> ·         
>  
> Goals and Milestones:
> ·        Charter statement
> ·        Problem Statements
> ·        Gap analysis
> ·        Study of NHRP (RFC2332) & SCSP,  and their applicability to Ethernet networks
> ·        Study and Analysis of MOOSE as a potential solution
> ·        Study and Analysis of SEATTLE as a potential solution.
>  
>  
> _______________________________________________
> arp222 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/arp222

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 26 Aug 2010 10:04:09 -0500

Anoop, 

First of all, the main objective of ARP222 is to develop interoperable
solution(s) for address resolution for massive number of (virtual) hosts (or
nodes) in one broadcast domain. The possible occurrence of duplicated IP
addresses among some hosts is by no means the main objective. 

It is from our cloud computing group indicating that it would make their
resource management much easier if occasional duplicated IP addresses among
some hosts are allowed within one VLAN. Here are their reasons:

*	There could be many Client Controlled subnets; the number could be
in the magnitude of tens or hundreds of thousands. There is huge difference
in the number of (virtual) hosts which client subnets have; Some client
subnets can have a few virtual hosts, all of them require very low
computation demand, and some client subnets can have very large number of
(virtual) hosts and require very high computation power. 

*	If each client subnet is only mapped to one VLAN, then each layer 2
can only support up to 4095 clients. The physical servers and network gears
in each layer 2 don't change very often. But the client subnets come and go
very frequently. With virtualized servers, you can easily have more than
5000 VMs under each Top of Rack Switch. Requiring each TOR to support NAT is
not realistic. 
*	Therefore, restricting one dedicated VLAN for each client can cause
some L2 network & servers under utilized and others over utilized. Making it
difficult for Resource Management. 

Back in ATM days, there were RFC2333 (NHRP) and RFC2334 (SCSP) which use
distributed servers to resolve addresses. If the similar approach is used
for resolving MAC addresses, then duplicated IP address within one VLAN
shouldn't be an issue (as long as they all have distinct MAC addresses).  

Linda 

  _____  

From: Anoop Ghanwani [mailto:[email-masked]] 
Sent: Tuesday, August 24, 2010 5:31 PM
To: Linda Dunbar; [email-masked]
Subject: RE: [arp222] ARP222 Charter statement and milestones

Linda,

are with that in mind.

Anoop

Anoop, 

Linda

  _____  

Linda,

Anoop

Anoop, 

Linda 

  _____  

Linda,

Anoop

Anoop, 

No, it shouldn't. 

Linda

  _____  

Linda,

Anoop

Anoop, 

Linda 

  _____  

Hi Linda,

Anoop

Linda Dunbar

  _____  

 

*         

Goals and Milestones:

*        Charter statement

*        Problem Statements

*        Gap analysis

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 26 Aug 2010 10:38:52 -0500

Benson, 

Definitely VLAN should be used to differentiate different subnets. 

In the Cloud Computing environment, client subnets are added and removed
very frequently and the number of (virtual) hosts in client subnets is very
different. 

If each client subnet is mapped to one VLAN, then each layer 2 can only
support up to 4095 clients

The physical servers and network gears in each Layer 2 don't change very
often. But the client subnets come and go very frequently. 

Therefore, restricting one dedicated VLAN for each client can cause some
servers/network under utilized and others over loaded.

Linda

  _____  

From: Benson Schliesser [mailto:[email-masked]] 
Sent: Tuesday, August 24, 2010 7:40 PM
To: Linda Dunbar
Cc: 'Anoop Ghanwani'; [email-masked]
Subject: Re: [arp222] ARP222 Charter statement and milestones

This is pretty much what a VLAN solves for you; it multiplexes link-layer
segments.

The scenario you've described is missing an abstraction layer.  You're
apparently trying to get around the need for VLANs, rather than improve
their scale.  I'd suggest this really is not the right way to think about
VLAN scale limitations.

Cheers,

-Benson

Anoop, 

Linda

  _____  

Linda,

Anoop

Anoop, 

Linda 

  _____  

Linda,

Anoop

Anoop, 

No, it shouldn't. 

Linda

  _____  

Linda,

Anoop

Anoop, 

Linda 

  _____  

Hi Linda,

Anoop

Linda Dunbar

  _____  

 

*         

Goals and Milestones:

*        Charter statement

*        Problem Statements

*        Gap analysis

---

From: Anoop Ghanwani <[email-masked]>
Date: Thu, 26 Aug 2010 10:59:38 -0700

Linda,

I'm not disputing the main objective of this work (looking
for methods to scale the number of ARPs).

I'm only questioning the relevance of the last bullet
under the design goals which is to support duplicate IP
addresses within the same VLAN.

Even in the presence of something like NHRP, I still
don't see how it is not an issue.   If you ever need to
route _to_ that IP address, there will be no way to know
which MAC address to put on the packet.

Anoop

From: Linda Dunbar [mailto:[email-masked]]
Sent: Thursday, August 26, 2010 8:04 AM
To: Anoop Ghanwani; [email-masked]
Subject: RE: [arp222] ARP222 Charter statement and milestones

Anoop,

First of all, the main objective of ARP222 is to develop interoperable solution(s) for address resolution for massive number of (virtual) hosts (or nodes) in one broadcast domain. The possible occurrence of duplicated IP addresses among some hosts is by no means the main objective.
It is from our cloud computing group indicating that it would make their resource management much easier if occasional duplicated IP addresses among some hosts are allowed within one VLAN. Here are their reasons:

 *   There could be many Client Controlled subnets; the number could be in the magnitude of tens or hundreds of thousands. There is huge difference in the number of (virtual) hosts which client subnets have; Some client subnets can have a few virtual hosts, all of them require very low computation demand, and some client subnets can have very large number of (virtual) hosts and require very high computation power.

 *   If each client subnet is only mapped to one VLAN, then each layer 2 can only support up to 4095 clients. The physical servers and network gears in each layer 2 don't change very often. But the client subnets come and go very frequently. With virtualized servers, you can easily have more than 5000 VMs under each Top of Rack Switch. Requiring each TOR to support NAT is not realistic.
 *   Therefore, restricting one dedicated VLAN for each client can cause some L2 network & servers under utilized and others over utilized. Making it difficult for Resource Management.

Back in ATM days, there were RFC2333 (NHRP) and RFC2334 (SCSP) which use distributed servers to resolve addresses. If the similar approach is used for resolving MAC addresses, then duplicated IP address within one VLAN shouldn't be an issue (as long as they all have distinct MAC addresses).

Linda

Linda,

Anoop

Anoop,

Linda

Linda,

Anoop

Anoop,

Linda

Linda,

Anoop

Anoop,

No, it shouldn't.

Linda

Linda,

Anoop

Anoop,

Linda

Hi Linda,

Anoop

Linda Dunbar

Goals and Milestones:
*         Charter statement
*         Problem Statements
*         Gap analysis

---

From: Benson Schliesser <[email-masked]>
Date: Thu, 26 Aug 2010 14:57:46 -0500

Linda -

I agree with the concerns you outline: existing layer 2 segmentation techniques (i.e. 802.1Q) don't scale well for large datacenter / cloud environments.  However, accepting those concerns doesn't lead to the conclusion you've reached.

Your view, as I understand it, is that conflicting use of IP addresses within the same broadcast domain should be supported.  I gather that you propose to enable this by somehow fixing ARP.  But I fear that you're conflating the issues of segmented broadcast domains and improved address resolution.  (After all, ARP isn't the only consumer of broadcast or multicast forwarding.)

My suggestion is that we either focus on an ARP alternative that works with VLANs, or an ARP alternative that depends on a VLAN alternative.  I don't consider it a reasonable goal to develop an ARP alternative that works with a shared broadcast domain.

Cheers,
-Benson

On 26 Aug 10, at 10:38 AM, Linda Dunbar wrote:

> In the Cloud Computing environment, client subnets are added and removed very frequently and the number of (virtual) hosts in client subnets is very different.
> If each client subnet is mapped to one VLAN, then each layer 2 can only support up to 4095 clients
> The physical servers and network gears in each Layer 2 don’t change very often. But the client subnets come and go very frequently.
> Therefore, restricting one dedicated VLAN for each client can cause some servers/network under utilized and others over loaded.
>  
> Linda
>  
>