Comment 18 for bug 1837847

Dear all,

thanks for your comments.
I uploaded a first draft of a spec for my proposal:
https://review.opendev.org/#/c/680990/

I hope this answers some questions.

re Routers and L2 vs. L3 VPNs (#14, #16):

Running the VPN server in the Router namespace seemed like a logical choice,
but I didn't really question it. I based my implementation on the existing
IPSEC driver and on the previous attempt at an OpenVPN driver.
The nice thing about the solution is that there's already a namespace, and
the Router has IPs on which I can have the VPN server listen.

I'm not sure how this can be moved to "properly live" in Neutron's L2.
Would that mean to have it as an extention to l2gw? I'm not familiar with l2gw
but it looks to me that it would be less flexible to have OpenVPN integrated
at that level.

re API changes (#16):

For my PoC, I managed to avoid creating any new API objects or fields, and I
used the fields already present in vpnservice. I'll provide details in
the spec. But depending on how the discussion on the Neutron Port creation
is resolved, some API changes may be required.

re creation and cleanup of Neutron Ports (#11, #13, #15):

I assumed the main difficulty would be technical: notification of a new client's
login happens by OpenVPN calling a separate script, and I need to find a way
to notify the agent who can then create the Port via RPC.

Now I understand that there may be a conceptual problem as well, and port
creation initiated by an agent is not something that is currently done anywhere.

I see two alternative solutions (which I also put into the spec draft):
1. Leave it all up to the client. We would then expect the client to create
its Port in advance, providing its MAC address. Those Ports can be persistent,
or they can be removed by the client after a disconnect.
2. (briefly mentioned in #4): Don't create Neutron ports.