> On May 11, 2020, at 11:03 AM, Christian Hopps <cho...@chopps.org> wrote: > >> On May 11, 2020, at 9:56 AM, Neale Ranns (nranns) <nra...@cisco.com> wrote: >> >> On 11/05/2020 14:28, "Christian Hopps" <cho...@chopps.org> wrote: > >> >> Is it *really* that big a deal to have a logical interface represent a >> tunnel mode SA? It actually seems a fairly elegant to me. Instead of tossing >> it out, why not just clean up the objectionable API pieces? The current >> changes can continue to be used for the GRE tunnel case, so the current work >> is not lost either. >> >> We seem to have come full circle... there is a logical interface, it's >> called ipipX. Clearly the name of the interface is not important. >> The logical interface shouldn't represent the SA, it should represent the >> peering, and it's the peering that defines the encap. I say this because SAs >> come and go as rekeying occurs, but the peering remains. You don't want to >> delete your interface and recreate all your routes, each time you rekey. In >> fact there's a good test; if the peering addresses can >> regularly/reasonably/etc change during a rekey, then the ipip case is >> definitely worse, since one would need to create a new ipip tunnel and IMO >> that would justify a different interface type. >> >> What would be preferable/more efficient for your feature is if the encap >> were applied after your feature is run, but do I really need a new interface >> type just for that? let me see what I can do.
Do you think a fix will available before the next LTS release? Thanks, Chris. > > Fantastic. :) > > Thanks, > Chris. > >> >> /neale >> >> >> Thanks, >> Chris.
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16751): https://lists.fd.io/g/vpp-dev/message/16751 Mute This Topic: https://lists.fd.io/mt/74027328/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
