ExaBGP pick list, what is "TODO"

[thomas-mangin]

This is an unordered list of sub-project which would be beneficial for ExaBGP

Documentation

• write some documentation
  • document the configuration format
    • document the various tricks of productivity (env vs ini, -d, --decode, etc.)
    • document adj-rib-in impact
    • document the environment variables
    • document the main configuration file
    • document the API ( process part of the configuration file ) as it changed many times
  • document the scalability of the code
    • report tested env ( max number of peers, number of updates per seconds, etc. )

Code Cleanup

• IP.length and CIDR.size are mostly doing the same thing, keep one.
• nexthop, location and api_* API improvement
• INET, MPLS, PathInfo init make sure all the API are the same
• rename many pack() to pack_attribute() and for other ton() - deprecate .string as API
• Attributes / MultiAttributes API, should be Attribute, Attributes, like Capability, Capabilities
• in protocol replace all the function with many returns and if/elif/else with dicts
• look at and address all the XXX: and XXX: FIXME: in the code
• separate API parsing code from the configuration
• operational messages are handled with their own co-routine in the class Peer and have a message queue in the class Neighbour. It be generic mechanism, with a different queue per AFI/SAFI
• class Prefix and MPLS code is mostly common code and should refactored to remove duplication
• we create LOTS of try:except block in schedule() can we fix it and make the code faster ?
• setup a convention Clean the way we use str, extensive(), string(). No code should rely on str
• some of the match condition of flows currently take list or numeric tests, they should always take both, refactor (still true ?)
• introduce a NotificationID class
• peer.reload is a bad name. it should it be called something like peer.route_update
• have a defined convention for the interface we use ( factory, etc. )
• the TLV code in AIGP should be updated and used for Capabilities
• improve networking code to be easier to follow, and using outside reactor
• many of the initial classes are working with "parsed" value in the init for performance in many cases classes should be handling internally "raw" ( on wire format )
• have changes in neighbor in one dict (and not two list like we have now with operational and routes )

Code Correctness

• Have per message type options for negotiated, parsed, packets and consolidate ?
• API write are blocking ATM
• On configuration reload we do not detect changes in processes
• warn if an as-path has the router ASN on an ibgp connection
• let the forked process indicate when it has finished and do not kill it before then ?
• next-hop is optional for flow but mandatory for other family, check that the presence/absence is in line with RFC

Performance

• at the end of the configuration parsing clear the Community cache
• compile configuration, save unportable state for fast re-load

New feature

• make sure we clearly log if we decoded the MD5 string with auto
• split encoder for command and response
• have a default med for the neighbor and have this default pass to routes when being announced
• reading stderr from forked process and displaying via the self.logger class
• give attributes names (dict key) so they can be reference when creating Change/Updates
• async configuration loading
• detect duplicate logging lines and just announce the number of repeat
• http://datatracker.ietf.org/doc/draft-vandevelde-idr-remote-next-hop/
• https://tools.ietf.org/html/draft-green-idr-ddosae-00
• https://tools.ietf.org/html/rfc5292

[thomas-mangin]

This list old items' get deleted.

[thomas-mangin]

legacy.