> -----邮件原件----- > 发件人: L3VPN [mailto:[email protected]] 代表 Joe Touch > 发送时间: 2013年12月4日 3:45 > 收件人: Pedro Roque Marques > 抄送: [email protected] > 主题: Re: on limitations of draft-xu-l3vpn-virtual-subnet > > > > 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).
Hi Joe, This draft is not intended to emulate a subnet for the TRANSIT LAN which is used for interconnecting routers, instead, it's just intended to emulate a subnet for the EDGE LAN where a lot of end HOSTs belonging to the same subnet are connected to each other. BTW, it's just a special usage of the Proxy ARP mechanism [RFC1027]. > > 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. See the above statement. > If that's not what you can support, then see RFC 1577 for suggestions on how > to > emulate what's *required*. See the above statement. > No, I don't think changing the Internet models to support incomplete solutions > is a good idea for anyone. As said before, this draft just describes a special usage of the Proxy ARP mechanism [RFC1027]. Therefore it DOESN'T change the Internet models at all. This special usage of the Proxy ARP is just to provide an optimal forwarding scheme for a certain target scenario where the subnet associated with the EDGE LAN need to be extended across multiple geographical dispersed locations). Xiaohu > Joe
