On Fri, Jan 16, 2026, 3:53 PM Bill Gage <[email protected]> wrote:
> Hmmm. On the one hand you say: > "the numbers being thrown around for scale-up networks seem to be a couple > of thousand nodes at most" > > and on the other hand you say: > "that would require Ethernet addresses to be the endpoint addresses and > they don't > have the hierarchical addressing that people want in network layer > addresses. While that might work for a small scale, it will have difficulty > scaling to large deployments". > > So, are these small networks with a few thousand nodes or massive networks > with hundreds of thousands of nodes? SUNH seems to be addressing the former. > > I'm confused :-( > Bill, The problem is that the overhead of IP is not inconsequential. This proposal addresses that by defining a slim layer network header. That retains the value of IP and L3 switching. The latest draft allows different sized addresses to give the operator control over how to scale their network. That includes zero length addresses if someone wants to use Ethernet addresses as endpoints and eliminate L3 addresses (but still have hop limit, traffic class, flow label, and next protocol fields). Tom Tom ---------------------------------------- > > Jan 16, 2026 2:40:10 p.m. Tom Herbert <[email protected]>: > > > On Fri, Jan 16, 2026 at 11:08 AM Bill Gage <[email protected]> > wrote: > >> > >> Hello Tom - > >> > >> Sorry if I am being a bit dense, but ... routing in datacentres replaced > >> Ethernet switching to provide capabilities such as fast reroute, > >> improved scalability, improved network management, etc which SUNH > >> doesn't seem to address. > >> > >> If SUNH is only about reducing packet overheads, what value does SUNH > >> provide versus using Ethernet without *any* network header? > > > > Hi Bill, > > > > Yes, there are some advocates who want to do that, but that would > > require Ethernet addresses to be the endpoint addresses and they don't > > have the hierarchical addressing that people want in network layer > > addresses. While that might work for a small scale, it will have > > difficulty scaling to large deployments (it's quite possible people > > could end up rediscovering why network layer addresses were needed in > > the first place :-) ). Basically, in the datacenter we want the > > advantages and ubiquity of IP without the overhead . > > > > The other problem is that the Ethernet header isn't sufficient. There > > are four fields we need from the network layer header: Traffic Class > > including ECN, Hop Limit as a safeguard against routing loops, Flow > > label for ECMP, and Next Protocol so we can demux different transport > > protocols over the same EtherType. These fields can fit in a four byte > > header. What we don't need are things like version numbers, flags, and > > payload length. > > > > Tom > > > >> > >> /bill > >> > >> On 2026-01-15 2:57 p.m., Tom Herbert wrote: > >>> On Thu, Jan 15, 2026 at 11:27 AM Bill Gage <[email protected]> > wrote: > >>>> > >>>> Please excuse my ignorance, but ... modern Ethernet switches have MAC > >>>> address table sizes on the order of hundreds of thousands of entries. > >>>> Building a local switched (not routed) network using a hierarchy of > >>>> Ethernet switches appears to be a common practice. > >>> > >>> Hi Bill, > >>> > >>> Larger networks, like in hyperscalers, are more likely to be L3 > >>> switched than spanning tree. There is also a know problem with > >>> Ethernet that it lacks a hop limit. > >>> > >>>> > >>>> So what problem does SUNH solve? > >>> > >>> 1. It reduces the size of the network layer header to reduce > >>> on-the-wire overhead > >>> 2. A smaller address simplifies switching and address lookups > >>> > >>> Tom > >>> > >>>> > >>>> /bill > >>>> > >>>> On 2026-01-09 5:53 p.m., Tom Herbert wrote: > >>>>> On Fri, Jan 9, 2026 at 2:03 PM dave seddon <[email protected]> > wrote: > >>>>>> … > >>>>> > >>>>> The numbers being thrown around for scale-up networks seem to be a > >>>>> couple of thousand nodes at most. 16 bits nicely rounds to the power > >>>>> of two and allows plenty of space to scale to reasonably large GPU > >>>>> clusters. Also, for scale-up we anticipate pretty flat networks with > >>>>> may two or three hops at most (justifies smaller Hop Limits in the > >>>>> protocol). > >>>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Int-area mailing list -- [email protected] > >>>> To unsubscribe send an email to [email protected] > >> >
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
