Add basic ST info

[crankynetman]

This is very basic and lacks some meat, but I wanted to at least get a skeleton in place for streaming telemetry style information, as I think that this is probably the Best Way® to get this data off of a network element.

[dwcarder]

Just so I make sure I get this right, what happens if the central management system thingy reboots or is otherwise starting from a null database. With this method is there way to get the initial table dump and then get the updates on change after that?

[crankynetman]

Just so I make sure I get this right, what happens if the central management system thingy reboots or is otherwise starting from a null database. With this method is there way to get the initial table dump and then get the updates on change after that?

¯\_(ツ)_/¯

Any reasonably well designed database that is ingesting this information would only be adding new entries to it's database and I wouldn't think you'd ever allow the NEs to tell it "actually, delete all of that stuff I sent before". I plan on building a lab to test all of this out though. For example I'd really like to know if the NE provides an update when an entry expires, or do you have to infer that based off of configuration?

[dwcarder]

I'm thinking more about starting from a blank slate. Do you only get incremental updates and then have no idea if/when you actually have the whole picture?

As an example from my SNMP days, on boot we would first do a snmpwalk of the mac address table of a switch. So then we know we have the whole table in our database. Then after that we would listen to mac-change notification traps and do incremental updates. If you were ever worried you were out of sync like if the network element reboots, you could go through that process again.

So I'm wondering if in the ST ecosystem if a similar construct applies.

[crankynetman]

You could definitely do the same approach, where you pull the whole table first and then only subscribe to updates, definitely nothing stopping you from doing that with gNMI or NETCONF/RESTCONF as far as I can tell.

I'm loosely of a mind though that there's no need to pull the entire table and then get updates except for perhaps literally the first time you turn it on. It will be good to get hands-on time with this though and see what rakes rear themselves into my face.

[dwcarder]

I would guess if such a mechanism exists, we just might want to point it out. (I'm somewhat unfamiliar w/ ST and friends)

It ends up being a really common pattern you see inside many protocols: RRDP for RPKI, AXFR vs IXFR for DNS, rsync, ... Basically for any time you need to keep two database things in sync, it's hard.

[timchown]

Hi,

This does seem a nice idea to essentially get the “diffs” to the state. Certainly worth getting in as a placeholder and fleshing out later. We can upload a -01 after the meeting. There’s an issue tracker, feel free to use that to capture these ideas and discussions.

Jeremy’s point about 7217 is also good.

I’ve stuck 3 issues in as reminders.

Tim

On 22/10/2024, 15:37, "Dale W. Carder" @.***> wrote:

I would guess such a mechanism exists, we might want to point it out. (I'm somewhat unfamiliar w. ST and friends)

It ends up being a really common pattern you see inside many protocols: RRDP for RPKI, AXFR vs IXFR for DNS, rsync, ... Basically for any time you need to keep to database things in sync, it's hard.

— Reply to this email directly, view it on GitHubhttps://github.com/timchown/address-accountability/pull/3#issuecomment-2429468824, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABMV24C7WQ2M2ZN4FWS3Q4LZ4ZPJRAVCNFSM6AAAAABQMS2WZSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMRZGQ3DQOBSGQ. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[timchown]

All sounds good!

[timchown]

I started creating issues for points we want to capture in -01 and later.