BGP Confederation plugin (updated)

[jbemmel]

Updated after #2462

Currently issues a warning if the user tries to use confed_ebgp in bgp.sessions, as this does not achieve the expected result - instead, ibgp settings are inherited (note added to documentation)

[ipspace]

Should BGP confederation peers be defined as a new type of neighbor? (e.g. confed)

From a purely academic standpoint 😜 we should have a new type of neighbor, maybe "ebgp_confed". However, we should probably apply IBGP-like community propagation to these members. I'm sure there are some other implication (but I'm too braindead to figure them out), and I don't want to think about what would happen when someone tries to combine this with EVPN and MPLS/VPN.

[ipspace]

Hoping I'm not about to write something too stupid:

• Confederation EBGP sessions are usually treated similarly to IBGP sessions if we use confederations as a scalability mechanism
• They can be more similar to EBGP sessions if you use confederations to create multiple domains within your "real" autonomous system
• In any case, we need to know how to deal with bgp.community, bgp.sessions and bgp.activate, and having confederation EBGP sessions use the same settings as regular EBGP sesssions is probably the wrong answer.
• That brings us to the need for ebgp_confed neighbor type. I think it should behave almost like ibgp by default (but the behavior should be configurable since we have configurable behavior for localas_ibgp), which means we have to generalize the localas_ibgp hacks in the BGP module.
• We could dynamically add the ebgp_confed neighbor type to various BGP attributes when the plugin is loaded, or we could add the value to the allowed values the way we do it with localas_ibgp. In any case, I would remove the hardcoded values for bgp.sessions (BGP_VALID_SESSION_TYPE) and bgp.activate (BGP_DEFAULT_SESSIONS) in the BGP module and rely on valid_values from BGP attributes.
• Finally, whenever we add support for confederations on a new device, we have to carefully check how BGP neighbor type is used in other BGP configuration templates, similarly to how we have to do if 'ibgp' in ngb.type in some places today.

If we decide to go down this path, I can do the generic BGP changes.

[jbemmel]

If we decide to go down this path, I can do the generic BGP changes.

I agree, let's do it this way

[ipspace]

After we merge #2462, you have to add ebgp_confed (or confed_ebgp to be consistent with localas_ibgp) to the four lists in bgp.attributes.global (you can use data.append_to_list function).

I hope the earliest plugin hook is executed before the attributes are expanded, otherwise you'll have to add the same values to bgp.attributes.node lists.

[ipspace]

Replaced by #2520