bgp.policy: allow to create an empty policy

[ssasso]

It would be great if the bgp.policy plugin will allow to create/append an empty policy to a neighbor. Allowing to define also the policy name would be a nice bonus.

In this way we can "attach" a route-map to a neighbor, which can easily be used (populated) by external/custom configuration scripts without the need to worry about the neighbor IP address (and eventually the policy name).

Example:

links:
- r1:
    bgp.create_empty_policy: true ### could be true/false or 'in' / 'out'
    bgp.policy_name_prefix: r1-to-r2-policy
  r2:

bgp.create_empty_policy will be considered only if no other attribute is present (as a sort of fallback),

https://github.com/ipspace/netlab/blob/63c3bc7427cacdce3a055d344ac1b892c1803336/netsim/extra/bgp.policy/plugin.py#L204

and could create a route map with permit 99 or sth similar, with no match/set clauses.

Then the route map needs to be linked to a neighbor (but the plugin is already capable of that).

policy_name_prefix could be used to create the two policy names, <prefix>-in and <prefix>-out.

[ipspace]

Agreed. I was thinking about something along these lines for quite a while (generic route-map functionality). Starting with "you can have a predictable route-map name" is a good idea.

I would simplify the attribute to bgp.policy, and use the presence of that attribute to indicate we want to have an inbound and outbound route map (in most implementations, a missing route-map is a no-op). That attribute could have a boolean value (True) to say "I want a route map, but choose any name you want"

However, there's a "slight" problem if we want to combine the other BGP policy attributes with a route map. Do we check whether all neighbors using the same bgp.policy value have the same set of attributes, or do we trust the user(s) not to do anything stupid (given how creative some people can get, that makes me a bit nervous).

Any thoughts?

[ssasso]

However, there's a "slight" problem if we want to combine the other BGP policy attributes with a route map. Do we check whether all neighbors using the same bgp.policy value have the same set of attributes, or do we trust the user(s) not to do anything stupid (given how creative some people can get, that makes me a bit nervous).

To avoid people creativity I would create a check to not allow to use the same policy name in multiple places.

[ipspace]

What about:

• If you set any attributes, you get the default route-map name.
• If you set bgp.policy attribute, you get two empty route-maps with that name (the -in and -out route maps). Even better, we could have the bgp.policy.in and bgp.policy.out attributes (I'd actually prefer this option, as it would tie nicely with the other ideas I'm mulling about)
• If you set any attributes and bgp.policy, you get an error

I would hate to ask for unique policy name per neighbor, as I'd like to have a system where I can apply the same route-map to multiple neighbors (for example, all customers)

[ssasso]

That's ok for me, but I'd like to add another point to the list, that could be useful.

You can define (or - you need to define) the "custom policy" name also at node level, and there you can add the "standard" attributes (standard = the ones we are already able to manage with the current templates).

In that way we can reuse the existing jinja templates for the attributes we already support.

[ipspace]

I would define the "custom policy" on the global level, so it can be reused across nodes. In the first iteration it might not check the node support for attributes (unless it's reasonably easy to do).

But yeah, I agree that it should be semantic icing that gets translated into existing Jinja2 templates.

[ipspace]

After mulling this over for a bit, here's the plan:

• Let's add this as part of bigger "generic routing" functionality.
• That functionality would include "routing.policy" (route maps), "routing.filters" (prefix lists, community lists, as-path lists) and "routing.static" (static routes)
• You would define route maps globally (for example routing.policy.as65000_in list/dictionary) and then use them in various places, starting with bgp.policy.in and bgp.policy.out
• Like with VLANs, you could define routing policy globally or within a node, including the ability to copy global definition into node definition without using it anywhere else in the data model.

Would that work for you? How soon do you need this?

[ssasso]

that looks perfect for me.

no rush, I am managing this with custom templates/plugins for now :)

but having this for end of summer would be great :)

[ipspace]

Implemented in #1238 and #1239