yahoo-eng-team team mailing list archive

[Omer Anson <omer.anson@xxxxxxxxxxxxxxxx>]

Public bug reported:

This RFE requests a unified API for a port-behind-port behaviour. This
behaviour has a few use-cases:

* MACVLAN - Identify that a port is behind a port using Allowed Address
Pairs, and identifying the behaviour based on MAC.

* HA Proxy behind Amphora - Identify that a port is behind a port using
Allowed Address Pairs and identifying the behaviour based on IP.

* Trunk Port (VLAN aware VMs) - Identify that a port is behind a port
using the Trunk Port API and identifying the behaviour based on VLAN
tags.

This RFE proposes to extend the Trunk Port API to support the first two
use-cases. The rationale is that in an SDN environment, it makes more
sense to explicitly state the intent, rather than have the
implementation infer the intent by matching Allowed Address Pairs and
other existing ports.

This will allow implementations to handle these use cases in a simpler,
flexible, and more robust manner than done today.

** Affects: neutron
     Importance: Undecided
         Status: New


** Tags: rfe

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1730845

Title:
  [RFE] support a port-behind-port API

Status in neutron:
  New

Bug description:
  This RFE requests a unified API for a port-behind-port behaviour. This
  behaviour has a few use-cases:

  * MACVLAN - Identify that a port is behind a port using Allowed
  Address Pairs, and identifying the behaviour based on MAC.

  * HA Proxy behind Amphora - Identify that a port is behind a port
  using Allowed Address Pairs and identifying the behaviour based on IP.

  * Trunk Port (VLAN aware VMs) - Identify that a port is behind a port
  using the Trunk Port API and identifying the behaviour based on VLAN
  tags.

  This RFE proposes to extend the Trunk Port API to support the first
  two use-cases. The rationale is that in an SDN environment, it makes
  more sense to explicitly state the intent, rather than have the
  implementation infer the intent by matching Allowed Address Pairs and
  other existing ports.

  This will allow implementations to handle these use cases in a
  simpler, flexible, and more robust manner than done today.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1730845/+subscriptions