Release 0.5.0

[DRiKE]

0.5.0

Released 2024-11-20.

This release features a lot of changes, big and small. The list below is not
exhaustive but tries to highlight and describe the bigger (and perhaps, more
important) ones.

Breaking changes

• Several common basic types (e.g. Asn and Prefix) are moved out of
  routecore to the new inetnum crate.

• Refactor of PathAttributes

  The introduction of PaMap and RouteWorkshop (see below) required refactoring
  of the PathAttributes enum and related types. Most significantly, an entire
  layer in the enum was removed, changing how one matches on variants.
  Furthermore some of the types in those variants slightly changed.

• Overhaul of address family related code

  The types describing address families, and related traits to parse and compose
  NLRI of such families, have severely changed. This eliminates any possible
  ambiguity regarding the address family of announcements/withdrawals in UPDATE
  messages at compile time.

  • Supported address families are now explicitly and exhaustively enumerated
    in the AfiSafiType enum. As a SAFI by itself does not carry much meaning,
    the separate SAFI enum is removed. Almost all of the code now works
    based on the more descriptive AfiSafiType.
  • ADD-PATH is now supported on all supported address families, i.e. the
    AfiSafiType includes ~AddPath variants for every single AFI+SAFI
    combination.
  • This now allows for e.g. efficient iterators over NLRI that are generic
    over the AfiSafiType.
    But, as a possible downside, this moves the task of determining what
    address family a set of NLRI holds to the caller in order to then use the
    correctly typed iterator. The less efficient, 'easier to use' iterators
    returning an enum instead of a distinct NLRI type are therefore still
    available.

New

• RouteWorkshop / PaMap

  This release introduces the RouteWorkshop to create UPDATE messages based on
  an NLRI and a set of attributes. For creation, inspection and manipulation of
  those attributes, the PaMap is introduced. These new types work in
  conjunction with the existing UpdateBuilder.

  Another new, related type is the OwnedPathAttributes, which is sort of a mix
  between the PathAttributes and PaMap, keeping the actual wireformat
  attributes blob in tact (using a Vec<u8>). This makes it more memory
  efficient than the PaMap, at a small cost in forms of compute.

• BGP FSM (absorbed from rotonda-fsm)

  routecore now contains the code to enable for actual BGP sessions, i.e. the
  BGP FSM and related machinery. By pulling this in into routecore allows for
  less dependency juggling, easier development iterations and more sensible code
  in all parts. All of this has some rough edges and is prone to changes on the
  near future.

  The rotonda-fsm crate for now is left as-is.

• Route Selection fundamentals

  This release introduces a first attempt at providing handles to perform the
  BGP Decision Process as described in RFC4271, colloquially known as 'route
  selection' or 'best path selection'.

  Most of the heavy-lifting for this comes from implementing Ord on a wrapper
  struct holding a 'route' (i.e., PaMap) and additional information to allow
  tie-breaking as described in the RFC.

  As the tie-breaking in RFC4271 is actually broken and not totally ordered, we
  aim to provide a certain degree of flexibility in the tie-breaking process by
  means of different OrdStrat ordering strategies.

• Limited MRT read support

  Support for reading and parsing MRT files, such as those published by RIPE
  RIS, is added behind the mrt feature flag. Both the 'dump' and the 'updates'
  files are supported, though not all exotic message types might be recognized,
  and the API will likely change.

Other changes

• Feature flags

  After splitting of parts of routecore into the inetnum crate, the default
  features set resulted in an almost empty library. Therefore the bgp flag is
  now on by default, and we introduced an fsm flag to enable the BGP FSM code
  absorbed from rotonda-fsm.

Known limitations

• Constructed UPDATE messages are MultiProtocol-only

  With regards to announcing and withdrawing NLRI, the UpdateBuilder is currently
  limited to putting everything in the MultiProtocol path attributes
  (MP_REACH_NLRI, MP_UNREACH_NLRI), so even for IPv4 Unicast.

  Note that this behaviour is considered preferable as it leads to somewhat more
  flexibility/resilience on the protocol level. But in case one of the peers
  does not signal the capability of doing IPv4 Unicast in MultiProtocol
  attributes, we should allow creation of PDUs in the traditional form anyway,
  so we plan to reintroduce this functionality.