Routing Policies

Home

Tutorial

Routing Policies

Routing policies define the import and export policy of each AS. Unlike some previous iterations of BGPy, these are now separate from the AS class so that they are easily swappable. The base class for a policy can be seen here

The base class of the policy defines the core functionality. It must be able to:

• receive an announcement (which will later be processed).
• process incoming announcements
• propagate announcements to providers, peers, and customers

BGPy supports a plethora of routing policies. We currently support:

• BGP
• ROV
• PeerROV
• BGPSec
• ASPA
• ASRA
• Path-End
• OnlyToCustomers
• EdgeFilter
• BGPiSec (several variants)
  • Transitive
  • ProviderConeID
  • Transitive + ProviderConeID
  • Transitive + OnlyToCustomers
  • BGPiSec (full version, with Transitive + OnlyToCustomers + ProviderConeID
• EnforceFirstAS
• ROV++ (Several variants)
  • ROV++V1 Lite
  • ROV++V2 Lite
  • ROV++V2Improved Lite
• PeerlockLite

You can also find other implementations of policies elsewhere, on old versions of BGPy, such as ROV++ and BGP-iSec (see the citations and use cases for links to the github repos)

As far as our requirements for integrating a policy into the BGPy, repo, this is typically our philosophy:

• Needs a peer reviewed publication
• Must be implemented in both the Full and non full versions (discussed in the next two tutorial pages)
• Must work for any possible scenario or simulation
• Ideally is gaining some traction in the BGP community (but not a requirement)
• Ideally, the policy would not be ambiguous as to it's implementation (but not a requirement)

If you wish to add a policy to this list, please just let us know at jfuruness@gmail.com, we'd be happy to add more!

Next: BGP