IETF doc proposes fix to stop descent into data centre 'address hell'

Address tables in data centres can fill up really quickly, so researchers from Huawei and Marvell have offered up a proposal to make them smaller. The purely-experimental RFC 7586 suggests that all hosts – including VMs – in an access domain be addressed through a proxy. The problem the RFC looks at is how to get data from …

[Anonymous Coward]

NATting for MAC addresses?

Of course it's bad, as it was made a no-go in IPv6...

[Anonymous Coward]

And why not use aggregation similar to the way route aggregation works? i.e. allocate a MAC address range to each VM host (and VM hosts per switch). It won't fix the VLAN rfc1918 virtual local net issue but at least it will reduce the larger 100(s) VMs per host/switch.

[Warm Braw]

Layer violations considered harmful...

There seems to be an implicit assumption in the RFC that Layer 2 == Ethernet and Layer 3 == IP. However, the layered model is based on the functions that each layer is supposed to perform, not the technology it employs.

Layer 2 is a datalink layer and it was never intended to provide the sort of functions (the efficient interconnection of a lot of logically separate subnetworks) that L2 switching is now used for - that's supposed to be a Layer 3 job, Surprise, surprise, leave it to L2 and it doesn't scale. Of course, this layer abuse is pretty much baked into operations these days - the "swtiching" guys deal with internal connectivity, however complex, and the "routing" guys handle external connectivity, however simple, but that's not an architectural given.

I hope the IAB take a long hard look at this. There's already enough L3 stuff (eg multicast) that interacts with over-extended LANs in bad ways and incremental band-aids like this are not really the long-term answer.

[Peter Gathercole]

Nothing new?

This does not sound too dissimilar to the layer 2 heuristic bridges that I was using 20 years ago to bridge geographically separated networks over slower WAN technologies with some degree of optimisation. Of course the scope is different, but the concepts look very much the same.

[Freimer]

Math

I don't follow the math. 4000 MACs I get. The next step I don't. Only way to end up with 800K MACs is to have 200 per VM, and I don't know any VMs with 200 VLANs assigned. Most have 1. Some have 2. A very few have more. Plus, this appears to have the underlay network knowledgeable about all VM MACs. They are not using VxLAN?

[Yes Me]

NOT an IETF document

So why did El Reg choose to give free PR to this particular piece of non-standard stuff as compared to all the other non-standard stuff in the universe? Somebody made a phone call or two?

Like it says at the front of the document: it's an Independent Submissions document, *not* from the IETF, and the IETF steering group says "the problems described in RFC 6820 can already be addressed through the simple combination of existing standardized or other published techniques." In other words, SARP is pointless.

[-v(o.o)v-]

FDB means forwarding database

[Jose Pina Coelho]

I've been seeing this stupid trend for the last 20 years ...

Every single time you pervert the basic L1,2,3 model for expediency, it turns around and bites you in the derriére...

The first time I've seen something like this, it was an L2 switch that had an ARP-Accelerator "feature". Said feature would cause immediate grief to HACMP clusters and load-balancers.

The role of the switch is to switch. Period.

And as Freimer noted, the only way to generate that many FDB entries from the stated number of machines/VMs is if each VM has 200 interfaces, so even the given example is ludicrous.