[ovs-dev,RFC,v2,08/10] vswitch.xml: Detail vxlanipsec user interface.

This commit adds details to the vswitch xml regarding the use of the
vxlanipsec interface type. This patch is not intended for upstreaming
and simply seeks to solicit feedback on the user interface design of
the vxlanipsec port type as described in the vswitch.xml.

This modifies the vswitch.xml with a proposed vxlanipsec interface.
It also provides details for the proposed interface options such as
SPD creation, SA creation and modification, Policy entries for the
SPD as well as traffic selector options for the policy.

Signed-off-by: Ian Stokes <ian.stokes@intel.com>
---
 vswitchd/vswitch.xml |  225 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 225 insertions(+), 0 deletions(-)

Hi Ian,

> -----Original Message-----
> From: ovs-dev-bounces@openvswitch.org [mailto:ovs-dev-
> bounces@openvswitch.org] On Behalf Of Ian Stokes
> Sent: Friday, August 25, 2017 5:41 PM
> To: dev@openvswitch.org
> Subject: [ovs-dev] [RFC PATCH v2 08/10] vswitch.xml: Detail vxlanipsec user
> interface.
> 
> This commit adds details to the vswitch xml regarding the use of the vxlanipsec
> interface type. This patch is not intended for upstreaming and simply seeks to
> solicit feedback on the user interface design of the vxlanipsec port type as
> described in the vswitch.xml.
> 
> This modifies the vswitch.xml with a proposed vxlanipsec interface.
> It also provides details for the proposed interface options such as SPD creation,
> SA creation and modification, Policy entries for the SPD as well as traffic
> selector options for the policy.
> 
> Signed-off-by: Ian Stokes <ian.stokes@intel.com>
> ---
>  vswitchd/vswitch.xml |  225
> ++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 225 insertions(+), 0 deletions(-)
> 
> diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml index
> 074535b..27c3c54 100644
> --- a/vswitchd/vswitch.xml
> +++ b/vswitchd/vswitch.xml
> @@ -2227,6 +2227,13 @@
>              A pair of virtual devices that act as a patch cable.
>            </dd>
> 
> +          <dt><code>vxlanipsec</code></dt>
> +          <dd>
> +            An interface type to provide IPsec RFC4301 functionality for
> +            traffic at the IP layer with vxlan, initially for IPv4
> +            environments.
> +          </dd>
> +
>            <dt><code>null</code></dt>
>            <dd>An ignored interface. Deprecated and slated for removal in
>            February 2013.</dd>
> @@ -2644,6 +2651,224 @@
>        </column>
>      </group>
> 
> +    <group title="IPsec">
> +      <p>
> +        Only <code>vxlanipsec</code> interfaces support these options.
> +      </p>
> +
> +      <column name="options" key="spd_id" type='{"type": "string"}'>
> +      <p>
> +        Must be an identifier for the SPD that is to be used by this IPsec
> +        interface. If no SPD exists with this ID then it will be created.
> +      </p>
> +      </column>
[[BO'M]] Do we need different security policy databases for different Interfaces? One per vSwitch would be enough to start with.
> +
> +      <column name="options" key="sa_id" type='{"type": "string"}'>
> +      <p>
> +        An identifier representing the ID of a Security Association.
> +        If no SA with this ID exists it will be created.
> +      </p>
> +      </column>
> +
> +      <column name="options" key="sa_spi" type='{"type": "string"}'>
> +      <p>
> +        A 32 bit number representing the security policy index for
> +        the SA.
[[BO'M]] should this be 'security *parameters* index'? If so the specs (rfc4301 sec 4.4.2.1) say "a 32-bit value selected by the
      receiving end of an SA to uniquely identify the SA"  and " An arbitrary 32-bit value that is used by a receiver to identify
      the SA to which an incoming packet should be bound." so should not need to be configured? I think the receiver just assigns an arbitrary 32bit value.
> +      </p>
> +      </column>
> +
[[BO'M]] The remaining options ipsec_mode, sa_protocol, .... ts_remote_port_range really define an SPD (security policy database) to look at the packet and decide if it needs to be DISCARD, BYPASS, PROTECTed. Would it be feasible to configure the selectors just as regular OF rules that send traffic to the vxlanipsec interface and then associate the keys, algorithms, mode (tunnel/transport) and protocol (AH/ESP) with the vxlanipsec interface?

> +      <column name="options" key="ipsec_mode" type='{"type": "string"}'>
> +      <p>
> +        The IPsec mode that applies to the SA, one of:
> +      </p>
> +        <ul>
> +          <li>
> +            <code>transport</code>: Provide protection primarily for next
> +            layer protocols.
> +          </li>
> +          <li>
> +            <code>tunnel</code>: Provide protection to IP layer also (applied
> +            to tunneled IP packets).
> +          </li>
> +        </ul>
> +      <p>
> +        Initially only support for transport mode will be implemented.
> +      </p>
> +      </column>
> +
> +      <column name="options" key="sa_protocol" type='{"type": "string"}'>
> +      <p>
> +        The security protocol used for IPsec, one of the following:
> +      </p>
> +        <ul>
> +          <li>
> +            <code>ESP</code>: Encapsulating Security Payload.
> +          </li>
> +          <li>
> +            <code>AH</code>: Authentication header
> +          </li>
> +        </ul>
> +      <p>
> +        Initially only ESP is supported, users can implement authentication
> +        communication only by setting the encryption algorithm to NULL for ESP
> +        but specifying the integrity algorithm. In this way there is no need
> +        to support AH. If this is acceptable to the OVS community then this
> +        option could be removed as it will always be ESP.
> +      </p>
> +      </column>
> +
> +      <column name="options" key="crypto_alg" type='{"type": "string"}'>
> +      <p>
> +        The encryption algorithm used for IPsec, one of the following:
> +      </p>
> +        <ul>
> +          <li>
> +            <code>NULL</code>: No encryption. Note NULL is required for the
> +            use of ESP with authentication only which is preferred over AH
> +            due to NAT traversal.
> +          </li>
> +          <li>
> +            <code>AES_CBC</code>: AES_CBC is a non-AEAD algorithm. Note users
> +            MUST specify an authentication algorithm to check integrity.
> +          </li>
> +          <li>
> +            <code>AES_GCM_16</code>: An AEAD algorithm. This allows the use of
> +            ESP with a combined mode cipher that handles encryption/decryption
> +            and authentication in a single step. Recommended for performance.
> +          </li>
> +        </ul>
> +      </column>
> +
> +      <column name="options" key="crypto_key" type='{"type": "string"}'>
> +      <p>
> +        A crypto key specifies the transformation of plaintext into cipher
> +        text for the encryption algorithm. Alphanumeric user generated string.
> +        IPsec sessions may have very long life time, and carry multiple
> +        packets, where possible 128-bit or 256-bit keys should be used.
> +      </p>
> +      </column>
> +
> +      <column name="options" key="auth_alg" type='{"type": "string"}'>
> +      <p>
> +        Optional. Represents the authentication algorithm to be used for
> +        IPsec. Depending on the encryption algorithm that is chosen a user
> +        may have to specify a separate authentication algorithm.  This
> +        typically occurs when communications are encrypted with non-AEAD
> +        algorithm which MUST be combined with an authentication algorithm.
> +        Can be one of the following:
> +      </p>
> +        <ul>
> +          <li>
> +            <code>NULL</code>: No authentication algorithm. Must only be used
> +            when the encryption is done with an AEAD algorithm.
> +          </li>
> +          <li>
> +            <code>HMAC_SHA2_256_128</code>: Should be selected when a non
> AEAD
> +            algorithm is used for encryption.
> +          </li>
> +        </ul>
> +      </column>
> +
> +      <column name="options" key="auth_key" type='{"type": "string"}'>
> +      <p>
> +        Required if an auth_alg has been specificed. An authentication key
> +        specifies the transformation of plaintext into cipher text for the
> +        authentication algorithm. An alphanumeric user generated string. IPsec
> +        sessions may have very long life time, and carry multiple packets,
> +        where possible 128-bit or 256-bit keys should be used.
> +      </p>
> +      </column>
> +
> +      <column name="options" key="policy_priority" type='{"type": "integer"}'>
> +      <p>
> +        Represents the policy order for an entry in the SPD.
> +      </p>
> +      </column>
> +
> +      <column name="options" key="direction" type='{"type": "string"}'>
> +      <p>
> +        A string representing whether the policy is applied to inbound or
> +        outbound traffic. Can be one of the following:
> +      </p>
> +        <ul>
> +          <li>
> +            <code>inbound</code>
> +          </li>
> +          <li>
> +            <code>outbound</code>
> +          </li>
> +        </ul>
> +      </column>
> +
> +      <column name="options" key="policy_action" type='{"type": "string"}'>
> +      <p>
> +        The policy action to take. Can be one of the following:
> +      </p>
> +        <ul>
> +          <li>
> +            <code>bypass</code>: IPsec transformation is not applied to
> +            traffic and traffic continues as normal.
> +          </li>
> +          <li>
> +            <code>discard</code>: Traffic is dropped.
> +          </li>
> +          <li>
> +            <code>protect</code>: An IPsec transformation is applied to the
> +            traffic. Note if action is 'protect' then the policy_sa option
> +            must also be specified.
> +          </li>
> +        </ul>
> +      </column>
> +
> +      <column name="options" key="policy_sa" type='{"type": "string"}'>
> +      <p>
> +        Required if the action for a policy is protect. The policy_sa should
> +        match an sa_id specified which contains the correct transformations.
> +      </p>
> +      </column>
> +
> +      <column name="options" key="ts_local_ip_range"
> +              type='{"type": "string"}'>
> +      <p>
> +        Optional. This represents the range of local IP addresses for the
> +        traffic selector to examine a packet for. Should be in the form of
> +        <code> start_ip_addr - end_ip_addr </code>
> +      </p>
> +      </column>
> +
> +      <column name="options" key="ts_remote_ip_range"
> +              type='{"type": "string"}'>
> +      <p>
> +        Optional. This represents the range of remote IP addresses for the
> +        traffic selector to examine a packet for. Should be in the form of
> +       <code> start_ip_addr - end_ip_addr </code>
> +      </p>
> +      </column>
> +
> +      <column name="options" key="ts_protocol" type='{"type": "string"}'>
> +      <p>
> +        Optional. This represents the traffic selector next layer protocol
> +        identifier to examine for before taking action.
> +      </p>
> +      </column>
> +
> +      <column name="options" key="ts_local_port_range"
> +              type='{"type": "string"}'>
> +      <p>
> +        Optional. This represents the range of local port ranges for the
> +        traffic selector to examine a packet for.
> +      </p>
> +      </column>
> +
> +      <column name="options" key="ts_remote_port_range"
> +              type='{"type": "string"}'>
> +      <p>
> +       This represents the range of remote port range for the traffic selector
> +       to examine a packet for.
> +      </p>
> +      </column>
> +    </group>
> +
>      <group title="MTU">
>        <p>
>          The MTU (maximum transmission unit) is the largest amount of data
> --
> 1.7.0.7
> 
> _______________________________________________
> dev mailing list
> dev@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev

> Hi Ian,
> 
> > -----Original Message-----
> > From: ovs-dev-bounces@openvswitch.org [mailto:ovs-dev-
> > bounces@openvswitch.org] On Behalf Of Ian Stokes
> > Sent: Friday, August 25, 2017 5:41 PM
> > To: dev@openvswitch.org
> > Subject: [ovs-dev] [RFC PATCH v2 08/10] vswitch.xml: Detail vxlanipsec
> > user interface.
> >
> > This commit adds details to the vswitch xml regarding the use of the
> > vxlanipsec interface type. This patch is not intended for upstreaming
> > and simply seeks to solicit feedback on the user interface design of
> > the vxlanipsec port type as described in the vswitch.xml.
> >
> > This modifies the vswitch.xml with a proposed vxlanipsec interface.
> > It also provides details for the proposed interface options such as
> > SPD creation, SA creation and modification, Policy entries for the SPD
> > as well as traffic selector options for the policy.
> >
> > Signed-off-by: Ian Stokes <ian.stokes@intel.com>
> > ---
> >  vswitchd/vswitch.xml |  225
> > ++++++++++++++++++++++++++++++++++++++++++++++++++
> >  1 files changed, 225 insertions(+), 0 deletions(-)
> >
> > diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml index
> > 074535b..27c3c54 100644
> > --- a/vswitchd/vswitch.xml
> > +++ b/vswitchd/vswitch.xml
> > @@ -2227,6 +2227,13 @@
> >              A pair of virtual devices that act as a patch cable.
> >            </dd>
> >
> > +          <dt><code>vxlanipsec</code></dt>
> > +          <dd>
> > +            An interface type to provide IPsec RFC4301 functionality
> for
> > +            traffic at the IP layer with vxlan, initially for IPv4
> > +            environments.
> > +          </dd>
> > +
> >            <dt><code>null</code></dt>
> >            <dd>An ignored interface. Deprecated and slated for removal
> in
> >            February 2013.</dd>
> > @@ -2644,6 +2651,224 @@
> >        </column>
> >      </group>
> >
> > +    <group title="IPsec">
> > +      <p>
> > +        Only <code>vxlanipsec</code> interfaces support these options.
> > +      </p>
> > +
> > +      <column name="options" key="spd_id" type='{"type": "string"}'>
> > +      <p>
> > +        Must be an identifier for the SPD that is to be used by this
> IPsec
> > +        interface. If no SPD exists with this ID then it will be
> created.
> > +      </p>
> > +      </column>
> [[BO'M]] Do we need different security policy databases for different
> Interfaces? One per vSwitch would be enough to start with.

My thinking was that an SPD per tunnel is easier in terms of performance and look up for policies. If associated on a per tunnel basis there should only be 1 inbound and 1 outbound policy per tunnel (as the selectors will be based on the src/dst IP and dest port), when you start to scale the number of tunnels you could end up with a lot of entries in the spd if using just 1 global spd which I'm thinking is going to slow down performance when selecting he correct policy for a given tunnel.

Having an spd per tunnel I don't think it's too much overhead and from a security point of view it could make sense that if an SPD is compromised it would only compromise that tunnel, not all tunnels. Thoughts?

> > +
> > +      <column name="options" key="sa_id" type='{"type": "string"}'>
> > +      <p>
> > +        An identifier representing the ID of a Security Association.
> > +        If no SA with this ID exists it will be created.
> > +      </p>
> > +      </column>
> > +
> > +      <column name="options" key="sa_spi" type='{"type": "string"}'>
> > +      <p>
> > +        A 32 bit number representing the security policy index for
> > +        the SA.
> [[BO'M]] should this be 'security *parameters* index'? If so the specs
> (rfc4301 sec 4.4.2.1) say "a 32-bit value selected by the
>       receiving end of an SA to uniquely identify the SA"  and " An
> arbitrary 32-bit value that is used by a receiver to identify
>       the SA to which an incoming packet should be bound." so should not
> need to be configured? I think the receiver just assigns an arbitrary
> 32bit value.

I think this would have to be configured in the manual/static case. The SPI should represent an index that is set in the ESP header when a packet is being sent outbound, the idea being that when a received receives the packet they can use the SPI as an index to which SA is used to decrypt the packet. For this to work I think we would have to assign an SPI per SA manually so that they are synced on both sides of the tunnel.

> > +      </p>
> > +      </column>
> > +
> [[BO'M]] The remaining options ipsec_mode, sa_protocol, ....
> ts_remote_port_range really define an SPD (security policy database) to
> look at the packet and decide if it needs to be DISCARD, BYPASS,
> PROTECTed. Would it be feasible to configure the selectors just as regular
> OF rules that send traffic to the vxlanipsec interface and then associate
> the keys, algorithms, mode (tunnel/transport) and protocol (AH/ESP) with
> the vxlanipsec interface?
> 

Possibly, I hadn't looked at this, do you have a fleshed out example of how this would work?

Because We're doing vxlan over ipsec in transport mode I guess you will only ever have 2 SAs for the vxlanipsec port, 1 for outbound, 1 for inbound, these would be called at the encap and decap stages respectfully, it makes me think would the SPD need to be consulted as the packets will already have been routed to the vxlanipsec port and encapsulated with vxlan destination/source IP and dest port before conducting IPsec processing?

It could be that the SPD is there for completeness and can be queried for what the active policies are for a given tunnel, but that it is never consulted for selection as the encap and decap  will always have the same IP range and port range to execute on (OVS has already routed it to the port).

> > +      <column name="options" key="ipsec_mode" type='{"type":
> "string"}'>
> > +      <p>
> > +        The IPsec mode that applies to the SA, one of:
> > +      </p>
> > +        <ul>
> > +          <li>
> > +            <code>transport</code>: Provide protection primarily for
> next
> > +            layer protocols.
> > +          </li>
> > +          <li>
> > +            <code>tunnel</code>: Provide protection to IP layer also
> (applied
> > +            to tunneled IP packets).
> > +          </li>
> > +        </ul>
> > +      <p>
> > +        Initially only support for transport mode will be implemented.
> > +      </p>
> > +      </column>
> > +
> > +      <column name="options" key="sa_protocol" type='{"type":
> "string"}'>
> > +      <p>
> > +        The security protocol used for IPsec, one of the following:
> > +      </p>
> > +        <ul>
> > +          <li>
> > +            <code>ESP</code>: Encapsulating Security Payload.
> > +          </li>
> > +          <li>
> > +            <code>AH</code>: Authentication header
> > +          </li>
> > +        </ul>
> > +      <p>
> > +        Initially only ESP is supported, users can implement
> authentication
> > +        communication only by setting the encryption algorithm to NULL
> for ESP
> > +        but specifying the integrity algorithm. In this way there is no
> need
> > +        to support AH. If this is acceptable to the OVS community then
> this
> > +        option could be removed as it will always be ESP.
> > +      </p>
> > +      </column>
> > +
> > +      <column name="options" key="crypto_alg" type='{"type":
> "string"}'>
> > +      <p>
> > +        The encryption algorithm used for IPsec, one of the following:
> > +      </p>
> > +        <ul>
> > +          <li>
> > +            <code>NULL</code>: No encryption. Note NULL is required for
> the
> > +            use of ESP with authentication only which is preferred over
> AH
> > +            due to NAT traversal.
> > +          </li>
> > +          <li>
> > +            <code>AES_CBC</code>: AES_CBC is a non-AEAD algorithm. Note
> users
> > +            MUST specify an authentication algorithm to check
> integrity.
> > +          </li>
> > +          <li>
> > +            <code>AES_GCM_16</code>: An AEAD algorithm. This allows the
> use of
> > +            ESP with a combined mode cipher that handles
> encryption/decryption
> > +            and authentication in a single step. Recommended for
> performance.
> > +          </li>
> > +        </ul>
> > +      </column>
> > +
> > +      <column name="options" key="crypto_key" type='{"type":
> "string"}'>
> > +      <p>
> > +        A crypto key specifies the transformation of plaintext into
> cipher
> > +        text for the encryption algorithm. Alphanumeric user generated
> string.
> > +        IPsec sessions may have very long life time, and carry multiple
> > +        packets, where possible 128-bit or 256-bit keys should be used.
> > +      </p>
> > +      </column>
> > +
> > +      <column name="options" key="auth_alg" type='{"type": "string"}'>
> > +      <p>
> > +        Optional. Represents the authentication algorithm to be used
> for
> > +        IPsec. Depending on the encryption algorithm that is chosen a
> user
> > +        may have to specify a separate authentication algorithm.  This
> > +        typically occurs when communications are encrypted with non-
> AEAD
> > +        algorithm which MUST be combined with an authentication
> algorithm.
> > +        Can be one of the following:
> > +      </p>
> > +        <ul>
> > +          <li>
> > +            <code>NULL</code>: No authentication algorithm. Must only
> be used
> > +            when the encryption is done with an AEAD algorithm.
> > +          </li>
> > +          <li>
> > +            <code>HMAC_SHA2_256_128</code>: Should be selected when a
> > + non
> > AEAD
> > +            algorithm is used for encryption.
> > +          </li>
> > +        </ul>
> > +      </column>
> > +
> > +      <column name="options" key="auth_key" type='{"type": "string"}'>
> > +      <p>
> > +        Required if an auth_alg has been specificed. An authentication
> key
> > +        specifies the transformation of plaintext into cipher text for
> the
> > +        authentication algorithm. An alphanumeric user generated
> string. IPsec
> > +        sessions may have very long life time, and carry multiple
> packets,
> > +        where possible 128-bit or 256-bit keys should be used.
> > +      </p>
> > +      </column>
> > +
> > +      <column name="options" key="policy_priority" type='{"type":
> "integer"}'>
> > +      <p>
> > +        Represents the policy order for an entry in the SPD.
> > +      </p>
> > +      </column>
> > +
> > +      <column name="options" key="direction" type='{"type": "string"}'>
> > +      <p>
> > +        A string representing whether the policy is applied to inbound
> or
> > +        outbound traffic. Can be one of the following:
> > +      </p>
> > +        <ul>
> > +          <li>
> > +            <code>inbound</code>
> > +          </li>
> > +          <li>
> > +            <code>outbound</code>
> > +          </li>
> > +        </ul>
> > +      </column>
> > +
> > +      <column name="options" key="policy_action" type='{"type":
> "string"}'>
> > +      <p>
> > +        The policy action to take. Can be one of the following:
> > +      </p>
> > +        <ul>
> > +          <li>
> > +            <code>bypass</code>: IPsec transformation is not applied to
> > +            traffic and traffic continues as normal.
> > +          </li>
> > +          <li>
> > +            <code>discard</code>: Traffic is dropped.
> > +          </li>
> > +          <li>
> > +            <code>protect</code>: An IPsec transformation is applied to
> the
> > +            traffic. Note if action is 'protect' then the policy_sa
> option
> > +            must also be specified.
> > +          </li>
> > +        </ul>
> > +      </column>
> > +
> > +      <column name="options" key="policy_sa" type='{"type": "string"}'>
> > +      <p>
> > +        Required if the action for a policy is protect. The policy_sa
> should
> > +        match an sa_id specified which contains the correct
> transformations.
> > +      </p>
> > +      </column>
> > +
> > +      <column name="options" key="ts_local_ip_range"
> > +              type='{"type": "string"}'>
> > +      <p>
> > +        Optional. This represents the range of local IP addresses for
> the
> > +        traffic selector to examine a packet for. Should be in the form
> of
> > +        <code> start_ip_addr - end_ip_addr </code>
> > +      </p>
> > +      </column>
> > +
> > +      <column name="options" key="ts_remote_ip_range"
> > +              type='{"type": "string"}'>
> > +      <p>
> > +        Optional. This represents the range of remote IP addresses for
> the
> > +        traffic selector to examine a packet for. Should be in the form
> of
> > +       <code> start_ip_addr - end_ip_addr </code>
> > +      </p>
> > +      </column>
> > +
> > +      <column name="options" key="ts_protocol" type='{"type":
> "string"}'>
> > +      <p>
> > +        Optional. This represents the traffic selector next layer
> protocol
> > +        identifier to examine for before taking action.
> > +      </p>
> > +      </column>
> > +
> > +      <column name="options" key="ts_local_port_range"
> > +              type='{"type": "string"}'>
> > +      <p>
> > +        Optional. This represents the range of local port ranges for
> the
> > +        traffic selector to examine a packet for.
> > +      </p>
> > +      </column>
> > +
> > +      <column name="options" key="ts_remote_port_range"
> > +              type='{"type": "string"}'>
> > +      <p>
> > +       This represents the range of remote port range for the traffic
> selector
> > +       to examine a packet for.
> > +      </p>
> > +      </column>
> > +    </group>
> > +
> >      <group title="MTU">
> >        <p>
> >          The MTU (maximum transmission unit) is the largest amount of
> > data
> > --
> > 1.7.0.7
> >
> > _______________________________________________
> > dev mailing list
> > dev@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev

On Fri, Aug 25, 2017 at 05:40:30PM +0100, Ian Stokes wrote:
> This commit adds details to the vswitch xml regarding the use of the
> vxlanipsec interface type. This patch is not intended for upstreaming
> and simply seeks to solicit feedback on the user interface design of
> the vxlanipsec port type as described in the vswitch.xml.
> 
> This modifies the vswitch.xml with a proposed vxlanipsec interface.
> It also provides details for the proposed interface options such as
> SPD creation, SA creation and modification, Policy entries for the
> SPD as well as traffic selector options for the policy.
> 
> Signed-off-by: Ian Stokes <ian.stokes@intel.com>

Thanks for adding documentation.

Would you mind adding the documentation in the same commit that adds the
documented feature?  We find that this makes what's going on a little
easier to understand.

> On Fri, Aug 25, 2017 at 05:40:30PM +0100, Ian Stokes wrote:
> > This commit adds details to the vswitch xml regarding the use of the
> > vxlanipsec interface type. This patch is not intended for upstreaming
> > and simply seeks to solicit feedback on the user interface design of
> > the vxlanipsec port type as described in the vswitch.xml.
> >
> > This modifies the vswitch.xml with a proposed vxlanipsec interface.
> > It also provides details for the proposed interface options such as
> > SPD creation, SA creation and modification, Policy entries for the SPD
> > as well as traffic selector options for the policy.
> >
> > Signed-off-by: Ian Stokes <ian.stokes@intel.com>
> 
> Thanks for adding documentation.
> 
> Would you mind adding the documentation in the same commit that adds the
> documented feature?  We find that this makes what's going on a little
> easier to understand.

No problem, the feature being added is kind of a bloated patch and needs to be spit out anyhow in the next RFC, I'll combine the doc patch at that stage to make reviewing a little easier.

Thanks
Ian