Skip to content

Commit

Permalink
Marek Updates
Browse files Browse the repository at this point in the history
  • Loading branch information
@mzbroch
mzbroch committed Aug 15, 2022
1 parent 63133be commit 89b35cb
Showing 1 changed file with 48 additions and 66 deletions.
114 changes: 48 additions & 66 deletions README.md
View file
Original file line number Diff line number Diff line change
@@ -1,5 +1,3 @@
# *** TODO(mzb) Init Przemek's review **

# Nautobot BGP Models Plugin

A plugin for [Nautobot](https://github.com/nautobot/nautobot) extending the core models with BGP-specific models.
Expand All @@ -13,16 +11,14 @@ New models enable modeling and management of BGP peerings, whether or not the pe

This plugin adds the following data models to Nautobot:

| Przemek: Model names on this list are not consistent with the names we use to describe individual models.

- Autonomous System
- Routing Instance
- Peer Endpoint
- Peer Group
- Peer Group Template
- Address Family
- AutonomousSystem
- BGPRoutingInstance
- PeerEndpoint
- PeerGroup
- PeerGroupTemplate
- AddressFamily
- Peering
- Peering Role
- PeeringRole

A key motivation behind this design is the idea that the Source of Truth should take a network-wide view of the BGP configuration, rather than a per-device view. This especially applies to the data models for autonomous systems (ASNs), BGP peerings, and network-wide templates (Peer Groups).

Expand Down Expand Up @@ -51,28 +47,34 @@ This model represents a device specific BGP process. It has a mandatory FK to a
- Description (optional, string)
- Extra Attributes (optional, JSON)

| Przemek: No mention of the Peer Group Template attribute? Peer Group Template attribute does not show up in the detailed view.
### Extra Attributes

### PeerEndpoint
Additional BGP object's attributes can be defined in "Extra Attributes" field. Extra attributes is a JSON type field meant to store data defined by user.

| Przemek: We should probably start with stating that this model is not directly exposed. I was looking for it in the menu. So something along the lines of "PeerEndpoint records are created when Peering instance is created."
Extra attributes follow the inheritance pattern, thus allowing for merging of the inherited extra attributes.

This model represents the configuration of a single device with respect to a single BGP peering.
Example of the extra attributes:

```json
{"ttl-security": 1, "timers": [6, 20] }
```

| Przemek: What does the below mean? Some configuration elements must match for the peering to establish, do we refer to all of them or just some?
Extra Attributes are available for following models:

It does not store configuration that must match symmetrically between peer devices (such as a common authentication key).
- `PeerEndpoint`
- `PeerGroup`
- `PeerGroupTemplate`
- `BGPRoutingInstance`

| Przemek: The below might lead user to think that he needs to manually create PeerEndpoint for remote peer. So might need to qualify it and say that this endpoint will be created automatically once Peering object is created.
### PeeringRole

Note that in the case of an external peering (device in the locally managed network peering to a remote endpoint belonging to an AS not managed within this network), while there generally will not be a Device record representing the remote endpoint, there will need to be a PeerEndpoint record representing it, at a minimum storing the IP address and ASN of the remote endpoint.
This model operates similarly to Nautobot’s `Status` and `Tag` models, in that instances of this model describe various valid values for the `Role` field used by `PeerGroup` and `Peering` records. Similar to those models, this model has fields including a unique name, unique slug, and a HTML color value.

`PeerEndpoint` model has a mandatory FK to a BGP Routing Instance (`BGPRoutingInstance`) record, an optional foreign-key relationship to a `PeerGroup`, and additional keys including:
### PeerGroupTemplate

This model represents network-wide configuration for `PeerGroups`. `PeerGroupTemplate` aims to represent a global configuration, and it has a mandatory `Name` field, and following fields:

- ASN (optional, FK to `AutonomousSystem`)
- Peer (optional, FK to `PeerEndpoint`)
- Source IP (optional, FK to Nautobot `IPAddress`, mutually-exclusive with Source Interface)
- Source Interface (optional, FK to Nautobot `Interface`, mutually-exclusive with Source IP)
- Role (optional, FK to `PeeringRole`)
- Description (string)
- Enabled (bool)
Expand All @@ -81,21 +83,6 @@ Note that in the case of an external peering (device in the locally managed netw
- Secret (optional, FK to Nautobot `Secret`)
- Extra Attributes (optional, JSON)

#### PeerEndpoint Local-IP

To ease the data presentation and consumption, `PeerEndpoint` provides also a property named `local_ip`.

| Przemek: Which GUI view has Local IP Address?

The value of this property will be presented in plugin's Grapical User Interface (GUI), and can be used to render configuration templates.

As Source-IP and Source-Interface could be defined at multiple inheritance levels, each Peer Endpoint will have a `local_ip` determined based on the following order:

1. `PeerEndpoint`'s `source_ip` attribute (if exists)
2. `Peer Group`'s `source_ip` attribute (if exists)
3. `PeerEndpoint`'s `source_interface` attribute (if exists)
4. `PeerGroup`'s `source_interface` attribute (if exists)

### PeerGroup

This model represents common configuration for a group of functionally related BGP peers. Peer Group aims to represent device-specific configuration shared across multiple peerings, and it has a mandatory `Name` field, optional FK to a network-wide `PeerGroupTemplate`, and additional fields including:
Expand All @@ -111,11 +98,20 @@ This model represents common configuration for a group of functionally related B
- Secret (optional, FK to Nautobot `Secret`)
- Extra Attributes (optional, JSON)

### PeerGroupTemplate
### PeerEndpoint

This model represents network-wide configuration for `PeerGroups`. `PeerGroupTemplate` aims to represent a global configuration, and it has a mandatory `Name` field, and following fields:
PeerEndpoint records are created when Peering instance is created.

This model represents the configuration of a single device with respect to a single BGP peering.

Note that in the case of an external peering (connection with an ISP or Transit Provider), there is no need to create and model provider's `Device` object. However, as a minimum `PeerEndpoint` (representing provider's side of `Peering`) created during `Peering` object creation, will have to store IP Address and ASN.

`PeerEndpoint` model has a mandatory FK to a BGP Routing Instance (`BGPRoutingInstance`) record, an optional foreign-key relationship to a `PeerGroup`, and additional keys including:

- ASN (optional, FK to `AutonomousSystem`)
- Peer (optional, FK to `PeerEndpoint`)
- Source IP (optional, FK to Nautobot `IPAddress`, mutually-exclusive with Source Interface)
- Source Interface (optional, FK to Nautobot `Interface`, mutually-exclusive with Source IP)
- Role (optional, FK to `PeeringRole`)
- Description (string)
- Enabled (bool)
Expand All @@ -124,26 +120,22 @@ This model represents network-wide configuration for `PeerGroups`. `PeerGroupTem
- Secret (optional, FK to Nautobot `Secret`)
- Extra Attributes (optional, JSON)

### Extra Attributes

Additional BGP object's attributes can be defined in "Extra Attributes" field. Extra attributes is a JSON type field meant to store data defined by user.
The device-specific `PeerEndpoint` custom modeling will be implemented in the future with `PeerEndpointContext` and `PeerGroupContext` models.

Extra attributes follow the inheritance pattern, thus allowing for merging of the inherited extra attributes.
#### PeerEndpoint Local-IP

Example of the extra attributes:
To ease the data presentation and consumption, `PeerEndpoint` provides also a property named `local_ip`.

```json
{"ttl-security": 1, "timers": [6, 20] }
```
| Przemek: Which GUI view has Local IP Address?

Extra Attributes are available for following models:
The value of this property will be presented in plugin's Grapical User Interface (GUI), and can be used to render configuration templates.

- `PeerEndpoint`
- `PeerGroup`
- `PeerGroupTemplate`
- `BGPRoutingInstance`
As Source-IP and Source-Interface could be defined at multiple inheritance levels, each Peer Endpoint will have a `local_ip` determined based on the following order:

| Przemek: This should be included earlier as it's being referred to from other models.
1. `PeerEndpoint`'s `source_ip` attribute (if exists)
2. `PeerGroup`'s `source_ip` attribute (if exists)
3. `PeerEndpoint`'s `source_interface` attribute (if exists)
4. `PeerGroup`'s `source_interface` attribute (if exists)

### AddressFamily

Expand All @@ -156,10 +148,6 @@ It has a locally unique AFI (address family identifier) field, optional VRF fiel

(*) The network-wide modeling of AddressFamilies will be implemented in the future with `AddressFamilyTemplate` model similar to the `PeerGroupTemplate`.

| Przemek: Should the below be included in the description of the `PeerEndpoint` model?

The device-specific `PeerEndpoint` custom modeling will be implemented in the future with `PeerEndpointContext` and `PeerGroupContext` models.

### Peering

This model represents the shared configuration of a single BGP peer relationship between two endpoints. It has FKs to two `PeerEndpoint` records (representing the two devices involved in the peering), and additional fields including:
Expand All @@ -170,12 +158,6 @@ This model represents the shared configuration of a single BGP peer relationship
| Przemek: We should ideally show two use cases related to peering, one for internal peering, another one for external peering. Form has got a lot of fields and it's not immediately obvious how to use it.

### PeeringRole

This model operates similarly to Nautobot’s `Status` and `Tag` models, in that instances of this model describe various valid values for the `Role` field used by `PeerGroup` and `PeerSession` records. Similar to those models, this model has fields including a unique name, unique slug, and a HTML color value.

| Przemek: This model should be introduced earlier, since other models refer to it.

### Inheritance between models

Some models can inherit attribute values, similar to what BGP supports with Peer Group. The inheritance is built hierarchically. The final attribute value will be taken from the first object in the hierarchy, moving from the top, which has given the attribute value defined.
Expand Down Expand Up @@ -269,12 +251,12 @@ PLUGINS_CONFIG = {
"nautobot_bgp_models": {
"default_statuses": {
"AutonomousSystem": ["active", "available", "planned"],
"PeerSession": ["active", "decommissioned", "deprovisioning", "offline", "planned", "provisioning"],
"Peering": ["active", "decommissioned", "deprovisioning", "offline", "planned", "provisioning"],
}
}
}
```
In the `default_statuses` section, you can define a list of default statuses to make available to `AutonomousSystem` and/or `PeerSession`. The lists must be composed of valid slugs of existing Status objects.
In the `default_statuses` section, you can define a list of default statuses to make available to `AutonomousSystem` and/or `Peering`. The lists must be composed of valid slugs of existing Status objects.

## Screenshots

Expand Down

0 comments on commit 89b35cb

Please sign in to comment.