Hey Tim,
> It’ll have to wait till after the RIB dump, or does it?
For me, the RIB dump is just a trigger/instruction to send all NLRIs and
their paths from the BGP RIB of a given AFI/SAFI. It should not really
be a different BMP feature in the sense of how we send BGP data to the
BMP receiver.
Now as far as compression I am not sure there is a need for it
considering today's interface speeds. It would be just unnecessary CPU
cycles on both sides of the BMP session.
Now to your question how BGP enqueues routes for UPDATE generation it is
very much implementation dependent. But normally yes the subsequent
update for already advertised 1.1.1.0/24 <http://1.1.1.0/24> would have
to wait till all other updates subject to be sent with version bumped
would be processed.
Thx,
R.
On Tue, Sep 20, 2022 at 2:05 AM Tim Evens (tievens) <[email protected]
<mailto:[email protected]>> wrote:
Inline, marked <tievens>____
__ __
On 9/19/22, 3:10 PM, "Robert Raszuk" <[email protected]
<mailto:[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 <http://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 <http://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 <http://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
<https://www.ietf.org/mailman/listinfo/grow>____
_______________________________________________
GROW mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/grow
<https://www.ietf.org/mailman/listinfo/grow>____
