Hi Tim,
- 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… BGP RIB dump is just a full BGP table being sent to a peer (regular peer or BMP peer). The main BGP RIB table does not freeze during such an event. It is still live - for BGP it is business as usual. So when new updates come in during sending they are added to the BGP table, best path is run etc ... If the prefix sent to the receiver was not yet sent it will be propagated with new info. If it was already sent the new update will be generated and sent after initial dump as simple BGP increment. It could be UPDATE MSG or WITHDRAW depending on the actual info which arrived during the cycle. Note that in some implementations all of the above may be multithreaded and happening in parallel. That is why there are flags in BGP RIB to assist with per peer deltas or per peer BGP tables like Adj-RIB-out. Thx, R. On Mon, Sep 19, 2022 at 10:42 PM Tim Evens (tievens) <tievens= [email protected]> wrote: > Let’s make sure to address that the bis is more than just an EoR update… > > @John Scudder <[email protected]>, @Paolo Lucente > <[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 > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow >
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
