Inline, marked <tievens> On 9/19/22, 3:10 PM, "Robert Raszuk" <[email protected]> wrote:
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. <tievens> The above works with a per flow/session based transmission, as in BGP peering sessions. This would work well if BMP senders implemented a per peer buffer where messages were either delayed or enqueued in FIFO order per peer. Basically start RIB dump, keep track of where you are sending the RIB and enqueue updates to the tail end. NOTE, state compression can be performed for pending updates to BMP, but for pre-policy but it does not involve best-path. The challenge comes with the BMP buffer/queue via the TCP connection and how the sender handles sending a RIB dump while changes are happening real-time. For example, 100’s of peers need to be RIB dumped, the sender starts in parallel (threaded) to send the first 10 peers, then it progressively moves on to other peers 10 at a time. RIB dump is delayed by the BMP buffer/TCP connection. If peer 1 RIB dump NLRI 1.1.1.0/24 has been sent/enqueued with state A, this is transmitted, but while the RIB dump is in progress, state of 1.1.1.0/24 has changed. It’ll have to wait till after the RIB dump, or does it? Do you add it to the live stream of the RIB DUMP still in progress or do you wait till after the initial RIB DUMP with an EoR? Obviously if a prefix, such as 8.8.8.0/24 that has yet to be enqueued can benefit from state compress before enqueuing. Although, that’s not written. 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) <[email protected]<mailto:[email protected]>> 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]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/grow _______________________________________________ GROW mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/grow
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
