On Thu, Nov 7, 2019 at 7:23 AM Ole Troan wrote:
> Dear Jon,
>
> I think were we left this last was a "shared TODO" list.
>
Yeah, sorry, I got tasked with something else for a bit...
> The MAP specific shallow virtual reassembly has been generalised, and
> moved to a separate component.
> SVR n
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 i
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 wrote:
> Hi Jon,
>
> Apologies for the delay in answering. Swapped out all my knowled
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 fo
Hey, sorry to pester folks...
Anyone have any insight here for us?
Thanks,
jdl
On Wed, Apr 10, 2019 at 8:12 AM Jon Loeliger wrote:
> Good Morning,
>
> 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
Good Morning,
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? Spec
