It is important to show the overall philosophy of **GBP** as it sets the
project’s direction.
-In the Beryllium release of OpenDaylight, **GBP** focused on **expressed
+In this release of OpenDaylight, **GBP** focused on **expressed
intent**, **refactoring of how renderers consume and publish Subject
Feature Definitions for multi-renderer support**.
- Endpoints:
- Define concrete uniquely identifiable entities. In Beryllium,
+ Define concrete uniquely identifiable entities. In this release,
examples could be a Docker container, or a Neutron port
- EndpointGroups:
The *classifier* and *action* portions of the model can be thought of as
hooks, with their definition provided by each *renderer* about its
-domain specific capabilities. In **GBP** Beryllium, there is one
+domain specific capabilities. In **GBP** for this release, there is one
renderer, the *`OpenFlow Overlay renderer (OfOverlay). <#OfOverlay>`__*
These hooks are filled with *definitions* of the types of *features* the
looks as so:
.. figure:: ./images/groupbasedpolicy/GBP_High-levelBerylliumArchitecture.png
- :alt: GBP High Level Beryllium Architecture
+ :alt: GBP High Level Architecture
- GBP High Level Beryllium Architecture
+ GBP High Level Architecture
The major benefit of this architecture is that the mapping of the
domain-specific-language is completely separate and independent of the
can now be leveraged across NetConf devices simultaneously:
.. figure:: ./images/groupbasedpolicy/GBP_High-levelExtraRenderer.png
- :alt: GBP High Level Beryllium Architecture - adding a renderer
+ :alt: GBP High Level Architecture - adding a renderer
- GBP High Level Beryllium Architecture - adding a renderer
+ GBP High Level Architecture - adding a renderer
As other domain-specific mappings occur, they too can leverage the same
renderers, as the renderers only need to implement the **GBP** access
mapping to the access and forwarding models. For instance:
.. figure:: ./images/groupbasedpolicy/High-levelBerylliumArchitectureEvolution2.png
- :alt: GBP High Level Beryllium Architecture - adding a renderer
+ :alt: GBP High Level Architecture - adding a renderer
- GBP High Level Beryllium Architecture - adding a renderer
+ GBP High Level Architecture - adding a renderer
In summary, the **GBP** architecture:
- Consumer Endpoint Identification Constraint
- Label based criteria for matching against endpoints. In Beryllium
+ Label based criteria for matching against endpoints. In this release
this can be used to label endpoints based on IpPrefix.
The second category is the provider matchers, which match against the
- Consumer Endpoint Identification Constraint
- Label based criteria for matching against endpoints. In Beryllium
+ Label based criteria for matching against endpoints. In this release
this can be used to label endpoints based on IpPrefix.
Clauses have a list of subjects that apply when all the matchers in the
Demo/Development environment
----------------------------
-The **GBP** project for Beryllium has two demo/development environments.
+The **GBP** project for this release has two demo/development environments.
- Docker based GBP and GBP+SFC integration Vagrant environment