[{"author": "Chris Morrow", "text": "

missed martin on this slide :( will add after meeting.

", "time": "2022-11-11T12:04:16Z"}, {"author": "Chris Morrow", "text": "

meeting materials updated for martin's preso. (in chair slides)

", "time": "2022-11-11T12:08:00Z"}, {"author": "Job Snijders", "text": "

Thanks!

", "time": "2022-11-11T12:10:31Z"}, {"author": "Chris Morrow", "text": "

for other speakers out of the room: \"If you want to run your own slides, please say so\"

", "time": "2022-11-11T12:24:30Z"}, {"author": "Chris Morrow", "text": "

Question about primary key here:
\n 1) timestamp is likely not enough to determine if the messages are the same.
\n 2) you must also use some key (ie: md5(collector, nlri))

\n

Chances of getting updates out of order here seems relatively high, no?

", "time": "2022-11-11T12:33:38Z"}, {"author": "Chris Morrow", "text": "

(I can ask this at the end as well)

", "time": "2022-11-11T12:33:51Z"}, {"author": "Jeffrey Haas", "text": "

I have related questions on timestamp I'll be asking at mic.

", "time": "2022-11-11T12:34:17Z"}, {"author": "Jeffrey Haas", "text": "

there is no guarantee that two streams from the same device will even vaguely be in sync for messages they send.

", "time": "2022-11-11T12:35:22Z"}, {"author": "Chris Morrow", "text": "

jeff: yea, this is sort of the same question as mine :) you ask at mic!! :)

", "time": "2022-11-11T12:36:10Z"}, {"author": "Chris Morrow", "text": "

2 sides of same problem I guess really.

", "time": "2022-11-11T12:36:33Z"}, {"author": "Jeffrey Haas", "text": "

The fundamental issue for \"primary/backup\" is \"which collector has the most fresh view of the data\". you cannot tell this from BMP data feeds.

", "time": "2022-11-11T12:43:08Z"}, {"author": "Jeffrey Haas", "text": "

To @Severin Dellsperger 's point, Juniper's containerized BGP has support for distribution of the received BMP state into kafka. End of the day, you need a bus to distribute into other components.

", "time": "2022-11-11T12:44:29Z"}, {"author": "Chris Morrow", "text": "

yup, I don't know that you actually care about that (primary/backup) as much as: \"don't double report\" :)

", "time": "2022-11-11T12:45:55Z"}, {"author": "Chris Morrow", "text": "

seems like it's really a 'fan out to redundant collectors' and then fan-in to storage/analysis.

", "time": "2022-11-11T12:46:22Z"}, {"author": "Chris Morrow", "text": "

with de-dupe at the fan-in part.

", "time": "2022-11-11T12:46:34Z"}, {"author": "Chris Morrow", "text": "

i think also 'redis' here was a lego shaped hole for 'the thing that does intermediate collection/primary-key management' , and you could plug in any other sort of thing there, redis seems like the nail shaped item the presenter's hammer hits often.

", "time": "2022-11-11T12:47:46Z"}, {"author": "Randy Bush", "text": "

inaudible. please swallow the mike.

", "time": "2022-11-11T12:56:08Z"}, {"author": "Randy Bush", "text": "

no rpki use of communities comes to mind at 5am

", "time": "2022-11-11T12:58:00Z"}, {"author": "Chris Morrow", "text": "

there is the oft cited \"but route-servers may signal...\" of course.

", "time": "2022-11-11T12:58:30Z"}, {"author": "Chris Morrow", "text": "

but we shouldn't rely (nor really use) that.

", "time": "2022-11-11T12:58:47Z"}, {"author": "Chris Morrow", "text": "

this problem (json for communities and/or bgp data generally) is interesting to me though.

\n

(because we put all of routeviews in big-query ... and during that process we invented our own-ish json transform)

", "time": "2022-11-11T13:00:09Z"}, {"author": "Job Snijders", "text": "

Randy Bush said:

\n
\n

no rpki use of communities comes to mind at 5am

\n
\n

The word RPKI is mentioned here in similar context to how RPKI can be used to authenticate published Geofeed information (RFC 9092). A suggestion is that consumer of this JSON data could confirm that the JSON was produced by the applicable resource holder. Another consideration could be to create a signedObject that contains information following a scheme for easy publication/discovery/validation.

\n

But I'd suggest to first come up with a schema; and then discuss next steps like how it fits into RPKI

", "time": "2022-11-11T13:05:17Z"}, {"author": "Jeffrey Haas", "text": "

\"Discovery\" of the community map files is an interesting challenging. RPKI isn't a bad place to document such things, but I suspect operators of RPKI infrastructure will have opinions of whether that's a good place or not. But I think it's likely better to have it in rpki than in DNS, e.g.

", "time": "2022-11-11T13:09:26Z"}]