Release 0.5.0

## 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.

Author: DRiKE

Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "routecore"
-version = "0.5.0-rc2-dev"
+version = "0.5.0"
 authors = ["NLnet Labs <[email protected]>"]
 categories = ["network-programming"]
 description = "A Library with Building Blocks for BGP Routing"

Changelog.md

@@ -1,6 +1,6 @@
-## 0.5.0-rc2
+## 0.5.0
 
-Released 2024-06-10.
+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
@@ -80,6 +80,14 @@ New
   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