Hi Thomas, Thanks for taking the time to review the draft.
> However, at least initially, SARP would be implemented in the service > processor (consuming CPU cycles). It would be years (if ever) before silicon > would implement this. Speaking as a chip vendor: our existing silicons support the data plane functionality of SARP. In fact, I am taking a wild guess (but I may be wrong) that some of our competitors' silicons that support IP/TRILL routing also support the data plane functionality of SARP, simply because from a data plane perspective SARP performs a somewhat similar functionality: address lookup + MAC address replacement. In general, I don't think anyone intended for the data plane of SARP to be implemented in software. > As DaveA points out, FDB tables are large on chips these days. > silicon will just get better and have bigger FDB tables... Right, but the *demand* for bigger FDB tables is also increasing, even more rapidly. Moreover, the FDB table is typically the biggest table in a switch silicon, which means that a large FDB table significantly increases the cost of the silicon. BTW, I took a look at RFC6820 (I am sure you are familiar with this document :) ), and it certainly addresses MAC table size as a real issue: " When L3 extends only to aggregation switches (see Section 6.4.2), however, MAC table size limitations can be a real issue." Thanks, Tal. -----Original Message----- From: int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] On Behalf Of Thomas Narten Sent: Saturday, September 28, 2013 12:28 AM To: Suresh Krishnan Cc: Internet Area Subject: Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt Given the flurry of mail, I went back and reviewed my notes on this document. I believe I understand the problem (reduce size of FDB), but am skeptical that solving it via the approach in this document is worthwhile. 1) As DaveA points out, FDB tables are large on chips these days. However, at least initially, SARP would be implemented in the service processor (consuming CPU cycles). It would be years (if ever) before silicon would implement this. But in parallel, silicon will just get better and have bigger FDB tables... Moreover, the SARP motivation section specifically cites a shortage of processor cycles as a problem ... but doing SARP in software will increase the demands on the CPU... its unclear to me that the increased CPU burdens SARP implies would be offset by the reduced amount of ARP processing that the solution is hoping will result... I.e., at least in the short term, it's unclear that SARP would actually help in practice. 2) Doing L2 NAT at line rates (an absolute requirement for edge devices) will only happen if this is done in silicon. I don't see that happening unless there is strong support from vendors/operators/chip makers... Software based solutions simply will not have sufficient performance. I think the IEEE would be a better place to have the discussion about what L2 chip makers are willing to implement... 3) Only works for IP. Doesn't work for non-IP L2. Doesn't that only solve part of the problem? 4) High availability is complex (but presumably also necessary). It smells a lot like multi-chassis LAG (with the need to synchronize state between tightly-coupled peers). Although IEEE is working in this general area now, there are tons of vendor-specific solutions for doing this at L2. Do we really want to tackle standardizing this in the IETF? Isn't the relevant expertise for this general area in IEEE? 5) This solution touchs on both L2 (NATing L2 addresses) and L3 (ARPing for IP addresses). We absolutely would need coordinate with IEEE before deciding to take on this work. 6) ARP caching will be a tradeoff. You want to cache responses for better performance, but long cache timeouts will result in black holes after VMs move. There is no great answer here. I expect long timeouts to be unacceptable operationally, which means that the benefits of caching will be limited (and these benefits are the key value proposition of this approach). It is really hard to estimate whether the benefits will be sufficient in practice. Gratuitous ARPs can help, but they are not reliable, so they will help, but have limitations... 7) I haven't fully worked this out, but I wonder if loops can form between proxies. There is the notion that when a VM moves, proxies will need to update their tables. But careful analysis will be needed to be sure that one can't ever have loops where proxies end up pointing to each other. And since the packets are L2 (with no TTL), such loops would be disasterous. (Note point 6: we are using heuristics (like gratuitous ARP) to get tables to converge after a change. Heuristics tend to have transient inconsistencies.. i.e., possibly leading to loops.) Again, overall, I understand the generic problem and that it would be nice to have a solution. However, I don't see a simple solution here. I see a fair amount of complexity, and I'm skeptical that it's worth it (e.g., when the next gen of silicon will just have a larger FDB). What I'd really like to see (before having the IETF commit to this work) is: 1) operators who are feeling the pain described in the document stepping forward and saying they think the solution being proposed is something they would be willing to deploy and is better than other approaches they have in their toolkit. 2) Vendors (including silicon) saying they see the need for this and think the would implement it. Thomas _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
