Dear Jon, I think were we left this last was a "shared TODO" list. What do you see as gaps? Feel free to patch.
Since April, I think there are a couple of things that has happened. The MAP specific shallow virtual reassembly has been generalised, and moved to a separate component. SVR now runs in front of MAP, so MAP doesn't need to deal with reassembly itself. That simplifies that handling quite a bit. There is also some work on making a functional interface to fragmentation, as in instead of sending packets requiring fragmentation via a separate graph node, then getting those back or setting the next-node via buffer meta data, just call fragment() and get a list of buffers back. Cheers, Ole > On 6 Nov 2019, at 20:07, Jon Loeliger <j...@netgate.com> wrote: > > Ole, > > Waaay back in April, we had a small exchange here on the topic > of some MAP-T/E behavior. Bottom line was some functionality > needed to be homogenized. We wrote: > > On Tue, Apr 16, 2019 at 2:35 AM Ole Troan <otr...@employees.org> wrote: > Hi Jon, > > Apologies for the delay in answering. Swapped out all my knowledge of MAP to > disk. ;-) > > > We are working on some MAP-E and MAP-T testing, and we have > > a few questions. Some of the existing VPP documentation about > > MAP-E and MAP-T is a bit loose. > > > > Should the use of a pre-resolved forwarding address be applicable > > to both MAP-E and MAP-T? Or is that only a MAP-E thing? Specifically, > > we see in the test/test_map.py test that it is only tested in the MAP-E > > case. > > Is it missing from the MAP-T tests due to oversight, or is that technically > > correct? > > -E and -T has evolved a little differently, which accounts for the > differences. > Pre-resolved next-hops is applicable for both. Should we do a shared todo > list for MAP items? > Perhaps an epic JIRA? > > > The MAP-T test also "enables map" on both interfaces in that same file. > > Is it required to do so? For only MAP-T? > > I would think so. Isn’t one the IPv4 side and the other interface the IPv6 > side? > In both cases packets are picked out from the IP feature path. > > > Finally, there is no test that introduces a rule. I feel like I read > > somewhere > > that MAP-T required at least one rule? Or is some combination of PSID > > and EA bits sufficient alone? > > Rules was developed for the LW46 1:1 case. As per subscriber rules as opposed > to algorithmic mapping for many users within a domain. > I think rules can be useful also in a MAP-T case. We should homogenize that. > > Patches welcome! > > Best regards, > Ole > > ... and we're back! Months pass, seasons change, and the code has, > what?, been fixed? ignored? silently left to bit-rot? Where are we today? > > Any chance there has been progress here? > > Thanks, > jdl >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14538): https://lists.fd.io/g/vpp-dev/message/14538 Mute This Topic: https://lists.fd.io/mt/31018611/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
