On Wed, Aug 15, 2018 at 2:30 AM, Ole Troan <otr...@employees.org> wrote:
> Jon, > > Thanks for bringing this up. In addition to Matus’ answer. > Hi Ole, Thanks! > There is a distinction to be made between forwarding and terminating > traffic. > And there is a nice grey middle ground between the two. > > Some features does forwarding on the transport header, like NAT, MAP-E, > MAP-T and so on, those do not require reassembling the fragment chain, and > do forward fragments in flights, aka virtual reassembly. > Right. > Tunnels with outer fragmentation require full reassembly (the packets are > addresses to the node itself), before forwarding. > > But you could also argue that there are features like ACL, firewalls, > legal intercept whatnot that would benefit from doing a full reassembly > while forwarding. > > a) Virtual reassembly > b) Full reassembly for terminating traffic (for-us / host) > c) Full reassembly for forwarding traffic for specific features requiring > that > > From a quick glance it seems like the current reassembly feature is doing > c. And doing it without any level of granularity. > Meaning that if you need outer reassembly for an IP in IP tunnel, you’d > suddenly also reassemble all IP traffic. And GRE? > Which is unwanted and costly. > That should be easy to fix. Klement? > I've not gotten to any of the IP-in-IP-like tunneling in my examples yet, so that is a future problem. :-) But hey, if we can fix it before we get to it, that always works! :-) > So you are right if you combine the current reassembly (c) with NAT, NAT > does not deal with the fragments. So how does NAT's fragmentation handle the parameters of the API_NAT_SET_REASS API call? Specifically, the max_frag value? It has to track all the fragments of one (original) packet and then does it drop all the fragments if it exceeds the max_frag value? > But at a much higher cost than virtual reassembly of course. I propose we > move default reassembly to b instead of c, and that it’s only done in the c > case for features that require it. > > Cheers, > Ole Thanks, jdl
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#10168): https://lists.fd.io/g/vpp-dev/message/10168 Mute This Topic: https://lists.fd.io/mt/24529319/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
