Skip to content

Latest commit

 

History

History
69 lines (48 loc) · 4.69 KB

README.md

File metadata and controls

69 lines (48 loc) · 4.69 KB

DASH Documentation

Documentation comprises system descriptions, High-level design (HLD) documents and detailed compliance requirements. These are contained in the DASH/documentation directory and subdirectories.

The testing framework, methodology, documentation and testing artifacts are stored in the DASH/test directory

See also DASH FAQ and Glossary.

Contents

Baseline Specifications and Requirements

All DASH devices shall conform to the following design specifications and compliance requirements:

Topic Documents
General Architecture and Requirements DASH general
Data plane Data plane
High-Availability (HA) High-Availability
gNMI Northbound API gNMI Northbound API
SAI Southbound API SAI Southbound API

Service Specifications and Requirements

DASH devices may implement one or more of the following services.

They shall conform to each service's design specifications and compliance requirements.

Topic Documents
Load Balancer Service Load Balancer Service
VNET-to-VNET Service VNET-to-VNET Service
Service Tunnel & Private Link Service Service Tunnel & Private Link Service
VNET Peering Service VNET Peering Service
Express Route (ER) Service Express Route (ER) Service
Encryption Gateway Service Encryption Gateway Service

Relationships and Flow of Documents

The diagram below shows how High-Level Descriptions beget Compliance requirements, compliance requirements beget test cases, and test cases are executed by test scripts to produce Test Results.

dash-specs-flow.

Some of the guiding principles for this approach are:

  • Define the objectives and the design or proposal separately from performance and requirement details.
  • Describe hard requirements separately from the design and architecture descriptions This allows the requirements to be easily defined, maintained, and referenced from other downstream "consumers," e.g., test cases. All requirements must be identified with some designator which allows traceability in test cases, scripts and results.
  • We encourage the creation of simultaneous human and machine-readable data which can drive test cases.
  • We must avoid burying test parameters into the test scripts. This allows the requirements to be maintained/defined independently from the (often complex) code which executes tests.
  • Many projects exist where only a programmer can locate and ferret out actual test criteria, often expressed as hard-coded constants buried within thousands of lines of test automation code. For quality control, these criteria must be easily accessible, reviewable and maintainable, to anyone familiar with the project.
  • We advocate complete auditability and traceability of tests cases, test results, associated specs and DUT/SUT configuration. This means a test run will record versions of every item including GitHub repository commit SHA ids, branches, tags, SW versions, API versions, etc.
  • Clear, concise and to the point human-readable reports, plus machine-readable results allowing dashboards, rolling-up of results, etc.

Related Repositories

References