Hi Ted: The "scaling benefit" offered by the approach is that the set of subtending end system MAC addresses is summarized as the MAC address of the ARP proxy which overwrites the ES address in the frame. The result being that MAC tables in the core tend to be smaller. The key thing is that this is a 1:N translation so the ARP proxy needs IP information in the frame and local ARP cache information in order to successfully translate the MAC address in frames addressed to itself to the subtending end system's MAC addresses.
What this means is any non-IP E2E protocol (CFM, QCN etc.) is broken and how one would instrument and fault sectionalize this network is unclear. It looks like an Ethernet subnet but does not behave like one. Again hope this helps Dave -----Original Message----- From: Ted Lemon [mailto:ted.le...@nominum.com] Sent: Friday, September 27, 2013 1:45 PM To: David Allan I Cc: Brian Haberman; int-area@ietf.org Subject: Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt On Sep 27, 2013, at 4:40 PM, David Allan I <david.i.al...@ericsson.com> wrote: > Although the list discussion around my comments was an interesting and > informative one, I did not consider my concerns addressed. An L3 ARP proxy > driving a 1:N MAC-NAT breaks a lot of stuff. IMO that is rather fundamental > and more discussion would not change the facts. In that regard I cannot see > how my concerns can be addressed by SARP as it stands... I realize that for the people presenting these points it is obvious why a L2 nat is a bad idea, and I think I know at least one reason why they feel this way, but it would help to actually walk the working group through it rather than just pointing out that it is so, because I suspect that there are plenty of working group participants who are not experts on the topic, but would understand readily if the concerns were explained in more detail. _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
