yahoo-eng-team team mailing list archive

[Armando Migliaccio <1484005@xxxxxxxxxxxxxxxxxx>]

If you are asking a) spanning a neutron logical network (l2 broadcast
domain) across multiple openstack deployments and b) the ability to
bridge/connect neutron managed and unmanaged l2 broadcast domains,
networking-l2gw is the project you should look. We kept abstractions and
implementations separate from Neutron core.

[1] https://github.com/openstack/networking-l2gw

** Changed in: neutron
       Status: Incomplete => Won't Fix

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

Title:
  [RFE] Remote port for L2 communication

Status in neutron:
  Won't Fix

Bug description:
  1. Use case from OPNFV: overlay L2 networks across OpenStack instance
  for heartbeat or state replication.

  Telecom application may (already) be designed as Active-Standby/Active-Active/N-Way to achieve high availability, 
   
  With a telecoms focus, this generally refers both to availability of service (i.e. the ability to make new calls), but also maintenance of ongoing control plane state and active media processing(i.e. “keeping up” existing calls). 
   
  Traditionally telecoms systems are designed to maintain state and calls across pretty much the full range of single-point failures.  As listed this includes power supply, hard drive, physical server or network switch, but also covers software failure, and maintenance operations such as software upgrade.  
   
  To provide this support, typically requires state replication between application instances (directly or via replicated database services).  It may also require special case handling of media endpoints, to allow transfer of median short time scales (<1s) without requiring end-to-end resignalling (e.g.RTP redirection via IP / MAC address transfers c.f VRRP).
   
  With a migration to cloud, a commonly expressed desire by carriers is to provide the same resilience to any single point(s) of failure in the cloud infrastructure.  
   
  This could be done by making each cloud instance fully HA (a non-trivial task to do right and to prove it has been done right) , but the preferred approach appears to be to accept the currently limited availability of a given cloud instance (no desire to radically rework this for telecoms), and instead to provide solution availability by spreading function across multiple cloud instances (i.e. the same approach used today to deal with hardware and software failures). 
   
  A further advantage of this approach, is it provides a good basis for seamless upgrade of infrastructure software revision, where you can spin up an additional up-level cloud, gradually transfer over resources / app instances from one of your other clouds, before finally turning down the old cloud instance when no longer required.
   
  If fast media / control failure over is still required (which many/most carriers still seem to believe it is) there are some interesting/hard requirements on the networking between cloud instances. To help with this, many people appear willing to provide multiple “independent” cloud instances in a single geographic site, with special networking between clouds in that physical site. "independent" in quotes is because some coordination between cloud instances is obviously required, but this has to be implemented in a fashion which reduces the potential for correlated failure to very low levels (at least as low as the required overall application availability).

  Therefore overlay L2 networks for cross OpenStack instance networking for heartbeat or state replication is required. Overlay L2 network is preferred for the following two consideration: 
  1) Legacy compatibility: Some telecom app with built-in internal L2 network, for easy to move these legacy telecom app to cloud, it would be better to provide L2 network connectivity 
  2) IP overlapping: overlapping IP address will occur for multiple telecom Apps (same type) in cross OpenStack instance networking.

  ( The use case could be found in the use case 2 of OPNFV multi-site
  project: https://etherpad.opnfv.org/p/multisite_usecase_collection.
  And the requirement is based on the OPNFV multi-site project meeting
  conclusion of Jul 16, 2015: Agenda & Minutes:
  https://wiki.opnfv.org/meetings/multisite )

  
  2.In some other scenario, the instance in OpenStack need to communicate with some server outside the cloud(e.g. an application in traditionally network). We need a port named remote port，which represent the server outside the cloud. We could made overlay L2 networks across OpenStack instance by this kind of ports.
  In this kind of ports, some attributes are needed(e.g. tunnel ip, another device owner, mac address etc).
  By using these ports, we can implicate the application migration from traditional network to neutron network.

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