Subject: [armd] Data center issues

From: Patrick Frejborg <[email-masked]>
Date: Mon, 31 Jan 2011 20:19:55 +0200

Hi all,

I'm new to the list and I just read through  the "Updated ARMD Charter
and Milestones" thread.

I do agree with Thomas Narten in his post on 27th of January, this is
a much bigger problem than only ARP.
It is also about VLAN scalability, how many MAC-addresses needs to be
supported in the L2 domain, spanning-tree issues, failure domain etc

Much of these challenges can today be solved by implementing VPLS,
tomorrow they can be solved by TRILL/SPB - but a L2 broadcast domain
is also IMHO a failure domain since a bridge floods all unknown
packets out on all ports when a router only forward packets to known
destinations.

Thus I think the root cause to have large L2 domains is the TCP/IP
stack itself - there is no session layer in the current stack. If the
TCP/IP stack contained a session layer, by implementing a
locator/identifier split, then the application could be moved from one
server to another (physical or virtual, it doesn't matter) on the fly.
Then we could design data center networks according to best practices,
i.e. implement routing whenever you can and the failure domains would
be much smaller - also ARP, VLAN, MAC scalability issues are solved.

And with a session layer in the TCP/IP stack , the customer could move
his applications from one cloud service provider to another cloud -
over a routed network. The security nodes should not use IP addresses
to verify the users/servers, instead the decoupled identifier should
be used to grant/deny access to a resource.

Examples of  locator/identifier split architectures are Host Identity
Protocol (HIP), Identfier/Locator Network Protocol (ILNP), Name Based
Sockets (NBS).

My 2 cents...

Patrick

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 31 Jan 2011 15:38:10 -0500

Patrick:

Yes, I agree that Data Center problem is bigger than just ARP/ND. However,
to make progress on the ARP/ND portion we need to focus our work tightly. 

I agree that the problem needs the technologies of 100Gb Ethernet, IP/OTN or
WDWM, 802.1aq/SPB and TRILL plus new TCP/IP stack options (STCP or new TCP
or IPv6 options), session concepts and NM topologies to provide cross-layer
optimization for data centers. I'm actually participating with IETF folks in
all these areas on protocols or NM. 

Networks/DC are focused on expanding the L2 (see the presentation below: 
http://www.nanog.org/meetings/nanog51/presentations/Monday/NANOG51.Talk45.na
nog51-Schaumann.pdf)

IETF WG do best by tackling one part of the total solution. We are staying
tightly focused on the ARP/ND problem, and proposing a very tight working
group. We are focused on collecting publishable ARP/ND statistics, getting
specific requirements, creating models for discussion, and creating
prototype that the community can access.

We have demonstrated at our BOF in Beijing that there are many solutions to
the ARP/ND issues. 

Linda and I have talked to many people providing DC technology or VM
technology or DC services. However, the topic is so hot that people do not
want to publish their statistics due to competitive pressures. We are
investigating anonymous data from Research networks with similar DC
topologies. 

If you want to suggest a WG for session layer, I will definitely attend that
group. I'm already tracking the rest of this work, plus the IEEE VLAN group.

If you disagree with the tight focus, please send your comments to our ADs
(Ralph Droms and Jari Arkko). 

Sue 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Patrick Frejborg
Sent: Monday, January 31, 2011 1:20 PM
To: [email-masked]
Subject: [armd] Data center issues

Hi all,

I'm new to the list and I just read through  the "Updated ARMD Charter and
Milestones" thread.

I do agree with Thomas Narten in his post on 27th of January, this is a much
bigger problem than only ARP. It is also about VLAN scalability, how many
MAC-addresses needs to be supported in the L2 domain, spanning-tree issues,
failure domain etc

Much of these challenges can today be solved by implementing VPLS, tomorrow
they can be solved by TRILL/SPB - but a L2 broadcast domain is also IMHO a
failure domain since a bridge floods all unknown
packets out on all ports when a router only forward packets to known
destinations.

Thus I think the root cause to have large L2 domains is the TCP/IP stack
itself - there is no session layer in the current stack. If the
TCP/IP stack contained a session layer, by implementing a locator/identifier
split, then the application could be moved from one server to another
(physical or virtual, it doesn't matter) on the fly.

Then we could design data center networks according to best practices, i.e.
implement routing whenever you can and the failure domains would be much
smaller - also ARP, VLAN, MAC scalability issues are solved.

And with a session layer in the TCP/IP stack , the customer could move his
applications from one cloud service provider to another cloud -
over a routed network. The security nodes should not use IP addresses to
verify the users/servers, instead the decoupled identifier should
be used to grant/deny access to a resource.

My 2 cents...

Patrick
_______________________________________________
armd mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/armd