Versions Compared

Old Version 1

changes.mady.by.user Unknown User (dahn)

Saved on

compared with

New Version Current

changes.mady.by.user Unknown User (dahn)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: mail link

Bug Reference

The Jira issue associated with this design spec

Branch

 

TBD (probably more then one oissue are related. if need be one will be created)

Branch

master 4.5/5.0What branch is this work being done in

Introduction

Purpose

State the purpose of the document; something like: this is the functional specificationS specification of feature "inter vpc networks"

References

...

References

  • relevant links

Document History

Glossary

Feature Specifications

  • put a summary or a brief description of the feature in question 

Support for networks between vpc routers. At the moment only a private gateway into another network can be created. in the sdn implementation of nicira networks this can be shared between multiple vpc routers. traffic can however only be routed to one remote gateway. The intent of this design is to make it possible to route traffic to different directions on such a network.

  • list what is deliberately not supported or what the feature will not offer - to clear any prospective ambiguities

It is not the primary objective to make traffic between tennants possible, though in sdn this is transparent to the user.

  • list all open items or unresolved issues the developer is unable to decide about without further discussion
  • quality risks (test guidelines)
    • functional
    • non functional: performance, scalability, stability, overload scenarios, etc
    • corner cases and boundary conditions
    • negative usage scenarios
  • specify supportability characteristics:
    • what new logging (or at least the important one) is introduced
    • how to debug and troubleshoot
    • what are the audit events 
    • list JMX interfaces
    • graceful failure and recovery scenarios
    • possible fallback or work around route if feature does not work as expected, if those workarounds do exist ofcourse.
    • if feature depends other run-time environment related requirements, provide sanity check list for support people to run
  • explain configuration characteristics:
    • configuration parameters or files introduced/changed
    • branding parameters or files introduced/changed
    • highlight parameters for performance tweaking
    • highlight how installation/upgrade scenarios change
  • deployment requirements (fresh install vs. upgrade) if any
  • system requirements: memory, CPU, desk space, etc
  • interoperability and compatibility requirements:
    • OS
    • xenserver, hypervisors
    • storage, networks, other
  • list localization and internationalization specifications 
  • explain the impact and possible upgrade/migration solution introduced by the feature 
  • explain performance & scalability implications when feature is used from small scale to large scale
  • explain security specifications
    • list your evaluation of possible security attacks against the feature and the answers in your design* *
  • explain marketing specifications
  • explain levels or types of users communities of this feature (e.g. admin, user, etc)

Use cases

An example of a three vpc network where vpc 10.1 is a management vpc that has access to everything and 10.2 and 10.3 only have access to each others first (front end?) tiers:


put the relevant use case/stories to explain how the feature is going to be used/work

...