|
1 |
| -## 0.5.0-rc0 |
| 1 | +## 0.5.0-rc1 |
2 | 2 |
|
3 |
| -Released 2024-05-29. |
| 3 | +Released 2024-06-10. |
| 4 | + |
| 5 | +This release features a lot of changes, big and small. The list below is not |
| 6 | +exhaustive but tries to highlight and describe the bigger (and perhaps, more |
| 7 | +important) ones. |
4 | 8 |
|
5 |
| -TODO |
6 | 9 |
|
7 | 10 | Breaking changes
|
8 | 11 |
|
| 12 | +* Several common basic types (e.g. `Asn` and `Prefix`) are moved out of |
| 13 | + _routecore_ to the new _inetnum_ crate. |
| 14 | + |
| 15 | +* Refactor of PathAttributes |
| 16 | + |
| 17 | + The introduction of `PaMap` and `RouteWorkshop` (see below) required refactoring |
| 18 | + of the `PathAttributes` enum and related types. Most significantly, an entire |
| 19 | + layer in the enum was removed, changing how one matches on variants. |
| 20 | + Furthermore some of the types in those variants slightly changed. |
| 21 | + |
| 22 | +* Overhaul of address family related code |
| 23 | + |
| 24 | + The types describing address families, and related traits to parse and compose |
| 25 | + NLRI of such families, have severely changed. This eliminates any possible |
| 26 | + ambiguity regarding the address family of announcements/withdrawals in UPDATE |
| 27 | + messages at compile time. |
| 28 | + |
| 29 | + * Supported address families are now explicitly and exhaustively enumerated |
| 30 | + in the `AfiSafiType` enum. As a SAFI by itself does not carry much meaning, |
| 31 | + the separate `SAFI` enum is removed. Almost all of the code now works |
| 32 | + based on the more descriptive `AfiSafiType`. |
| 33 | + * ADD-PATH is now supported on all supported address families, i.e. the |
| 34 | + `AfiSafiType` includes `~AddPath` variants for every single AFI+SAFI |
| 35 | + combination. |
| 36 | + * This now allows for e.g. efficient iterators over NLRI that are generic |
| 37 | + over the `AfiSafiType`. |
| 38 | + But, as a possible downside, this moves the task of determining what |
| 39 | + address family a set of NLRI holds to the caller in order to then use the |
| 40 | + correctly typed iterator. The less efficient, 'easier to use' iterators |
| 41 | + returning an enum instead of a distinct NLRI type are therefore still |
| 42 | + available. |
| 43 | + |
9 | 44 | New
|
10 | 45 |
|
11 |
| -Bug fixes |
| 46 | +* RouteWorkshop / PaMap |
| 47 | + |
| 48 | + This release introduces the `RouteWorkshop` to create UPDATE messages based on |
| 49 | + an NLRI and a set of attributes. For creation, inspection and manipulation of |
| 50 | + those attributes, the `PaMap` is introduced. These new types work in |
| 51 | + conjunction with the existing `UpdateBuilder`. |
| 52 | + |
| 53 | +* BGP FSM (absorbed from _rotonda-fsm_) |
| 54 | + |
| 55 | + _routecore_ now contains the code to enable for actual BGP sessions, i.e. the |
| 56 | + BGP FSM and related machinery. By pulling this in into _routecore_ allows for |
| 57 | + less dependency juggling, easier development iterations and more sensible code |
| 58 | + in all parts. All of this has some rough edges and is prone to changes on the |
| 59 | + near future. |
| 60 | + |
| 61 | + The _rotonda-fsm_ crate for now is left as-is. |
| 62 | + |
| 63 | + |
| 64 | +* Route Selection fundamentals |
| 65 | + |
| 66 | + This release introduces a first attempt at providing handles to perform the |
| 67 | + BGP Decision Process as described in RFC4271, colloquially known as 'route |
| 68 | + selection' or 'best path selection'. |
| 69 | + |
| 70 | + Most of the heavy-lifting for this comes from implementing `Ord` on a wrapper |
| 71 | + struct holding a 'route' (i.e., `PaMap`) and additional information to allow |
| 72 | + tie-breaking as described in the RFC. |
| 73 | + |
| 74 | + As the tie-breaking in RFC4271 is actually broken and not totally ordered, we |
| 75 | + aim to provide a certain degree of flexibility in the tie-breaking process by |
| 76 | + means of different `OrdStrat` ordering strategies. |
| 77 | + |
12 | 78 |
|
13 | 79 | Other changes
|
14 | 80 |
|
| 81 | +* Feature flags |
| 82 | + |
| 83 | + After splitting of parts of _routecore_ into the _inetnum_ crate, the default |
| 84 | + features set resulted in an almost empty library. Therefore the `bgp` flag is |
| 85 | + now on by default, and we introduced an `fsm` flag to enable the BGP FSM code |
| 86 | + absorbed from _rotonda-fsm_. |
| 87 | + |
| 88 | + |
| 89 | +Known limitations |
| 90 | + |
| 91 | +* Constructed UPDATE messages are MultiProtocol-only |
| 92 | + |
| 93 | + With regards to announcing and withdrawing NLRI, the `UpdateBuilder` is currently |
| 94 | + limited to putting everything in the MultiProtocol path attributes |
| 95 | + (MP_REACH_NLRI, MP_UNREACH_NLRI), so even for IPv4 Unicast. |
| 96 | + |
| 97 | + Note that this behaviour is considered preferable as it leads to somewhat more |
| 98 | + flexibility/resilience on the protocol level. But in case one of the peers |
| 99 | + does not signal the capability of doing IPv4 Unicast in MultiProtocol |
| 100 | + attributes, we should allow creation of PDUs in the traditional form anyway, |
| 101 | + so we plan to reintroduce this functionality. |
15 | 102 |
|
16 | 103 |
|
17 | 104 | ## 0.4.0
|
|
0 commit comments