Possible Feature: BGP Sessions

[coxley]

Similar in concept to #203

If someone currently wants to use NSoT to source configuration data from, they can but it's a bit more tricky for some things. Arbitrary attributes gets you pretty far but if you want to store associative data, you might need to get creative and do create attribute name rules like:

• bgp_65001_raddr => 10.0.0.1
• bgp_65001_type => external
• bgp_65001_name => Transit_A

The arbitrary nature of NSoT is its strong point, but BGP associations fits in the same category as circuits. I think the idea justifies itself, so here are some general questions about implementation detail:

• Given that circuits is similar, do we create a generic "A to Z" resource type driver to easily get these two resource types at the same time?
• Guess related to the first point and a point in #203, but do we make these sessions require a linked device? If so how do we handle external peering?
• Do we require link to #148 resource type?
• Do we require link to a circuit for an adjacency? Allow it to be optional? Don't allow it at all? I can see benefit in being able to fetch a circuit from BGP adjacency details and the other way around. Not sure how I think about requiring it because it might make starting to use NSoT for one feature incrementally difficult.

[jathanism]

Seems to me this would be something that the proposed ASN resource in #148 would be a prerequisite to this. I like this idea. Let's start thinking of this from the perspective of object modeling.

We should probably start a brainstorm doc on the new proposed objects and how they may relate to each other.

[coxley]

Yep that's what I was trying to get at but wanted to document this while on my brain. Agreed on he brainstorming for new resource concepts.

[coxley]

Here are some thoughts:

• Authentication Key
• A Peer IP
• A ASN
• Z Peer IP
• Z ASN
• Prefix (link to Network)
• Export/Import Policies

Some of those could just be attributes that each organization defines for themselves via required/optional resource attrs like policies and auth key. But it might make sense to include some just since it's something common that a BGP session includes.

[coxley]

After talking with a friend, I think we can do better than just BGP Sessions. I think we should make a more generic resource type Protocols. This would let us cover IS-IS, BGP, OSPF, etc. In addition, Circuits could have a protocols field to show the protocol(s) running over it.

[jathanism]

@coxley I love it. So let's start w/ BGP as the first use-case and see how that works out. Before we drop to some code let's come up w/ an abstract.

[coxley]

Well here's an abstract... diff :wink:

+Protocol
+   Type: Name of type. Validate the input someway or maybe just leave completely custom or validate the same way hostnames are, via config option
+   A Peer IP: Inherit from associated circuit OR pk to another network resource
+   Z Peer IP: PK to network OR string

# Problem with those is what type to take. Do we require /32 exists for
# referring to a network? Problem with this is it may become a small
# bit harder for new user to spin up and play with NSoT. If they want
# to just test and play with the Protocol resources for example. And we
# have the Prefix field to link to the parent at least?
# 
# On the other hand, most of the benefit and power of modeling out the
# network is doing it all the way. For Z-side I also thought that we
# shouldn't require a network resource anyway because that would mean
# we're modeling potential not-our-network. (if A is on the edge)

+   ASN: Optional link to ASN resource

# This should refer to the Z side - connecting *to* ASN.

+   Prefix: Link to network containing peer IPs
+   Import Policies: List of string
+   Export Policies: List of string

# Representing route-filter, policy, route-map, etc. Should be
# interpreted to be organizational-specific

Circuit:

+   Protocols: List of refs to Protocol instances

[jathanism]

Here's some replies:

+Protocol
+   Type: Name of type. Validate the input someway or maybe just leave completely custom or validate the same way hostnames are, via config option
+   A Peer IP: Inherit from associated circuit OR pk to another network resource
+   Z Peer IP: PK to network OR string

Why not just link a Protocol to an existing Circuit object? Then we could easily derive the A/Z peer IPs?

# Problem with those is what type to take. Do we require /32 exists for
# referring to a network? Problem with this is it may become a small
# bit harder for new user to spin up and play with NSoT. If they want
# to just test and play with the Protocol resources for example. And we
# have the Prefix field to link to the parent at least?

Look at the way a Network is assigned to an Interface. It's done by way of the Assignment intermediate model. The Assignment object is what constrains the ability to assign a Network object to an interface. It's here where the following checks occur upon assignment:

• That the Network is a /32 or /128 (aka host address)
• That the Network is not already assigned to another Interface on the attached Device
• That the Network exists
  • If it exists, its state is set to assigned
  • If it doesn't exist, it is created

On an Interface you can look at the addresses assigned to it by way of Assignment relationships. You can also look at the networks that contain the addresses.

So I feel like this same concept could be applied or adapted for use in a Protocol relationship to a Network object by way of a Circuit.

# On the other hand, most of the benefit and power of modeling out the
# network is doing it all the way. For Z-side I also thought that we
# shouldn't require a network resource anyway because that would mean
# we're modeling potential not-our-network. (if A is on the edge)

I think we should consider the modeling of these objects, and perhaps this would be a case where we could allow linking of Network objects from other sites. As in the case where we want to track "our" networks in site_id=1 and "their" networks in site_id=2.

+   Import Policies: List of string
+   Export Policies: List of string

# Representing route-filter, policy, route-map, etc. Should be
# interpreted to be organizational-specific

Why not just let these be left up to custom attributes? This seems like a super specific use-case. What about other things like md5/auth, AS path, metro, flags... etc? Perfect use-cases for attributes IMO.

[coxley]

1. I thought about that but it leaves us hanging on the case for using Loopbacks as source for protocol communication. And I'm not really inclined to have all protocols just running an a single Circuit containting a loopback Interface resource. :stuck_out_tongue:
2. Wonder if we should re-purpose Assignment or just have ProtocolAssignment. The only constrain the protocol would need would be the last bullet (set state or create). I like that though. Then the parent prefix can either be there or not and we only deal with the /32 assignment.
3. Hm, interesting thought. I'd like to get a revision landed before we think about that. I feel that's a bigger scope and just having Z be optional is fine at first. We've done this before as in building the resource slowly vs. 100% featureful on launch.
4. Yep, attributes it is

[coxley]

Another item to note for Z-side is for things like LDP where it may just be enabled on an interface and makes more sense to leave Z as null

[jathanism]

We should consider the OpenConfig model for BGP as inspiration for the abstract model we use for the Protocol resource type!

See: https://github.com/openconfig/public/tree/master/release/models/bgp

[jathanism]

Fixed in #301