Ketan,
> On Dec 3, 2025, at 9:24 AM, Ketan Talaulikar <[email protected]> wrote:
>
> For clarity:
> Destination: The destination in the appropriate address family combination
> (afi/safi) that a key in a RIB. (This is where we'll likely revisit things
> for the RIB-key conversation for 4271-bis)
> NLRI: In practice, the encoding of a destination and potentially other
> destination-specific attributes in a BGP UPDATE PDU, some of which may be a
> key in the RIB, some of which are not. The original meaning of "network
> layer" reachability has degraded over time where we no longer are talking
> strictly about OSI Layer 3 in the things we carry in BGP.
> Route: A pairing of a destination and a set of path attributes.
> Path: An instance of a route received from or sent to a BGP speaker.
>
> KT2> Agree - this is my (and perhaps the general?) understanding as well.
> There is one wrinkle about Loc-RIB (and the RIB) and how the terms Route and
> Path are correlated there (factoring multipath and its variants like
> best/backup)
This would probably be helped by one additional term, and one touched upon in
4271: The routing table.
The routing table is distinct from LocRIB.
The routing table is also the component that is very implementation specific
even if there's two-ish common patterns for its implementation. It's why we
don't see a ready YANG module in IETF or OC standardizing such a thing.
Multipath/ECMP is a routing-table function.
Backup paths are a routing-table function.
If an implementation has "more than one primary path" (this continues to be
poorly explained in the current document), that's also distinct from LocRIB.
All of these obviously are taking as inputs state that comes from the logical
RIB model. For the above, they're all items that are in the Adj-RIBs-In-Post
view. The status of these items depend on whether the entry is the LocRIB
entry - or not.
It's *FINE* to have routing-table state in BMP, but it's problematic to
conflate that with BGP RIB state.
Where BMP has previously had such an issue overlaps an ambiguity in 4271 with
regard to the routing table interaction: What happens when you advertise a
route into BGP that is different than your LocRIB route? E.g. static overrides
BGP?
One way to model that is that LocRIB also interacts with the routing table and
that route "overrides" the entry. "Unified" routing table models tend to favor
this behavior.
Another way to model this is that the LocRIB doesn't change, but the selected
route is "inserted into the Adj-RIBs-Out". Distributed BGP RIB/routing table
models tend to favor this behavior.
Covering this isn't intended to relitigate what an implementation puts into its
LocRIB view. Implementations may make a choice for BGP best-path, or routing
table "active route", and operators have use cases for both. We might be able
to address this later.[1]
End of the day, the necessary work is to be clear in the document what state is
modeled. We can then select the most appropriate standards terminology for it.
-- Jeff
[1] https://github.com/ietf-wg-idr/RFC4271bis/issues/99
_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]
