On 12/3/2013 11:30 AM, Pedro Roque Marques wrote: > Joe, > > On Dec 3, 2013, at 7:56 AM, Joe Touch <[email protected]> wrote: > >> PS - it seems obvious to me that placing a router (an L3 IP forwarding >> device) between two sets of hosts considered on the same "subnet" is broken. >> >> What you want there is an L2 switch, not an L3 device. > > It depends on who is "you"... > > The vast majority of applications are not capable of accessing the > L2 header of a packet; if "you" have applications that care about the > L2 header and a specific L2 behavior then "you" must provide that > model.
The same is true for L3, though. > That is one of the issues that come up repeatedly around this topic. > There are very different requirements between traditional/legacy > data-centers deployments and "scale out" deployments. The most > successful scale out deployments do not support L2 semantics. It is a > tradeoff: not having to support ethernet emulation simplifies networking > and it turns out there is a class of applications that don't care. That > shouldn't prevent people from adding "an L2 switch" when serving the > traditional market. > > There where applications in the past that relied on an ethernet bus > behavior and assumed that they could listen to unicast packets sent to > any MAC. They ought to have been using a broadcast address if broadcast was desired. > When switches where introduced they had to change to use > unregistered MAC on an L2 emulation that don't broadcast unknown > unicast packets they will again have to change. Had they correctly used a broadcast address, it would have continued to work. > Even the concept of what > is an L2 service changes over time and applications that rely on side > effects may be impacted.. So far you've convinced me that if you don't understand the L2 you're using, you can see inadvertent side-effects. However, if you do understand the L2, things would have continued to work fine. > they are very few however. And it is often an > accepted trade-off to not support these in new environments. An Ethernet that doesn't support broadcast addresses isn't Ethernet anymore. If someone sells you something they claim is Ethernet and broadcast addresses aren't supported, return it. But I don't see why we should deal with this as a "new environment". Yes, there are L2s that don't support broadcast, and many Internet mechanisms don't react well to them (see RFC 3819 ). > So perhaps instead of using terms like "broken", we can discuss what > service model a given solution provides. And consider that given service > models have advantages and drawbacks. And some don't support Internet as L3 until there is support for some sort of broadcast emulation (e.g., RFC 1577). > It is perfectly reasonable to ask the author of the draft that is > being discussed to clarify what is the service model: what is the TTL > treatment; the IP broadcast model, etc. You can then let the network > operator decide what are their specific requirements. If it's an Internet L3 subnet, then see RFC 3819. If that's not what you can support, then see RFC 1577 for suggestions on how to emulate what's *required*. No, I don't think changing the Internet models to support incomplete solutions is a good idea for anyone. Joe
