Hi Tim,
A brief comment to say I'd be all up for a bis effort with all the
points you mention from our 2017 conversations and more - as we have
learned by deploying BMP during these past few years. And, of course,
include EoR as part of the package.
Paolo
On 19/9/22 22:41, Tim Evens (tievens) wrote:
Let’s make sure to address that the bis is more than just an EoR update…
@John Scudder <mailto:[email protected]>, @Paolo Lucente
<mailto:[email protected]> and I discussed back in 2017 several updates to
fix/clarify 7854 in terms of implementations of senders and receivers…
It was on the table to create a new RFC instead of a bis to go over
sender and receiver implementations.
Somethings have changed with RFC8671 (Adj-RIB-Out) and RFC9069
(Local-RIB). RFC9069 defines a new peer type and makes it very clear
to the receiver that the messages are for Local-RIB. RFC8671 follows
RFC7854, but clarifies that PEER_(UP|DOWN) are singular to the
route-(mirroring | monitor) messages. In other words, for Local-RIB we
know which messages are Local-RIB by peer type, but for Adj-RIB-Out and
Adj-RIB-In (both pre and post policy) we have to look at flags (per
mirroring/monitor message) and distinguish.
Correlating NLRIs (BGP updates) to PEER state (peer-(up|down) and
capabilities advertised) works when we can hash/identify per-peer header
to PEER_(UP|DOWN) per-peer headers. If they equal, then they are
associated.
When working with anything other than RFC9069, you send a SINGLE
PEER-(UP|DOWN). The route-(mirroring/monitor) messages are then
linked/associated by peer type. AFI/SAFI (rib-out, rib-in, pre-policy,
post-policy) are NLRI level. OpenBMP, as an example, will hash based on
this. It expects a single PEER-(UP|DOWN) that is re-used for the other
AFI/SAFIs and tables (in, out) and mix of pre vs post policy. The only
exception to this is Local-RIB, which is very clear on the usage. The
problem I see is that this is not clearly articulated in RFC7854 or
RFC8671…. Although 8671 inherits 7854, so a BIS for 7854 will address 8671.
OpenBMP takes the approach of hashing NLRI (bgp updates) and peer
up/down messages to associate them together. When we receive a PEER
DOWN, we mark NLRIs associated as withdrawn. Upon PEER UP, we delete
and rebuild the RIB. This is where EoR is very important!!!
The problem I see today is that senders (Cisco, Juniper, Huawei, Arista,
…) are unclear based on RFC7854 if they:
* should send multiple PEER_(UP|DOWN) messages based on flags
(rib-out, rib-in, pre-policy, post-policy)
* EoR should be per AFI/SAFI (IMO this should be an obvious yes)
* Route-Refresh; 7854 doesn’t call this out, but should I send a
ROUTE-REFRESH message to BMP receiver or not?? IMO, YES… send it and
we’ll trigger a delete/purge and rebuild based on it. EoR will be
expected.
* What does the sender do with the live updates that are happening
while the RIB dump is taking place, should they queue/buffer and
flood after RIB dump or drop them? IMO, dropping them is not an
option. Ideally the sender should queue those and then send them
(e.g., replay) them after the RIB dump (after sending the EoR).
Basically append them to the end of queue for transmission to the
BMP receiver. State-compression could be used here to reduce the
queue after RIB-DUMP. We’ll likely need to discuss this a bit more…
Thanks,
Tim
On 9/16/22, 3:17 AM, "GROW" <[email protected]> wrote:
Hi all,
Vincent, thanks for bringing this up. We've been puzzled about what to
expect exactly, too.
On Thu 15 Sep 2022, 01:08, Maximilian Wilhelm wrote:
> Anno domini 2022 Jeffrey Haas scripsit:
>
> > (..) the per-AFI/SAFI end of rib is a feature rather than a bug.
> >
>
> I fully agree with that. Having one marker per AF seems to be the much
> better option as it clearly indicates which RIB is fully transmitted/
> recieved/mirrored and also feels simpler to implement in a safe and
> sane way.
>
> (..)
>
> So I'd say lets stay with EoR and clarify it's to be send per AF and
> we should be in a better place.
I agree we should keep the EoRs, and we should not aim for a single
'Done'-message or drop this feature altogether. In addition to having a
EoR per AFI/SAFI, I think there are implementations that distinguish
pre- vs post-policy as well, i.e. sending out two EoRs per AFI/SAFI.
It might be good to clarify the text regarding that exact behavior too.
Are EoRs per pre/post policy useful? As a BMP consumer, I'm in favour.
Related question: should an implementation send out an EoR for empty
tables, i.e. a combination of {AFI/SAFI/policy} for which no actual
routes are stored and thus nothing is sent from the router to the BMP
monitoring station? Could/should one expect an EoR for such a
combination without having received any RouteMonitoring messages for
that combination?
And with BMP for Loc-RIB and Adj-RIB-Out, I guess similar questions
apply, and we actually have to reason about combinations of
{RIB/AFI/SAFI/policy} ?
Thanks,
luuk
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
<https://www.ietf.org/mailman/listinfo/grow>
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
