[{"author": "Les Ginsberg", "text": "<p>can other remote folks hear - I have no audio.</p>", "time": "2024-11-07T09:32:25Z"}, {"author": "Jeffrey Haas", "text": "<p>I can hear loud and clear</p>", "time": "2024-11-07T09:34:41Z"}, {"author": "Yingzhen Qu", "text": "<p>collective note taking: <a href=\"https://notes.ietf.org/notes-ietf-121-lsr\">https://notes.ietf.org/notes-ietf-121-lsr</a></p>", "time": "2024-11-07T09:39:39Z"}, {"author": "Shraddha Hegde", "text": "<p>This can be done in RFC 9350 by not advertising algorithm TLV by the node to be excluded</p>", "time": "2024-11-07T09:48:07Z"}, {"author": "Ketan Talaulikar", "text": "<p>+1 to Shraddha</p>", "time": "2024-11-07T09:51:50Z"}, {"author": "Les Ginsberg", "text": "<p>+2</p>", "time": "2024-11-07T09:52:18Z"}, {"author": "Ketan Talaulikar", "text": "<p>existing : enable/disable algo ... this new proposal :  add/remove node admin flag .... isn't that the same?</p>", "time": "2024-11-07T09:54:26Z"}, {"author": "Liyan Gong", "text": "<p>Thank you for your question. Let me try to explain, hold on a moment.</p>", "time": "2024-11-07T10:13:06Z"}, {"author": "Liyan Gong", "text": "<p>The advantage of using FAD is that We can exclude a category of nodes that share the same attributes\uff0c<br>\nwithout having to specify each individual node.</p>", "time": "2024-11-07T10:15:14Z"}, {"author": "Liyan Gong", "text": "<p>For example, if we want to exclude all nodes in the network that have not been upgraded, we can set the tag of these nodes to a specific value. Then, by excluding that value, it will be OK.</p>", "time": "2024-11-07T10:16:12Z"}, {"author": "Lou Berger", "text": "<p>@les lost you</p>", "time": "2024-11-07T10:16:52Z"}, {"author": "Jeffrey Haas", "text": "<p>shraddha, your mic sounds like it's across the room</p>", "time": "2024-11-07T10:18:32Z"}, {"author": "Christian Kuhtz", "text": "<p>check which mic you're using on your machine.</p>", "time": "2024-11-07T10:18:56Z"}, {"author": "Shraddha Hegde", "text": "<p>I'll fix my headset. others can go</p>", "time": "2024-11-07T10:19:19Z"}, {"author": "Ketan Talaulikar", "text": "<p>@shraddha ... if nbr is running different algo then we just fallback for normal flooding. It is the same for everyone?</p>", "time": "2024-11-07T10:21:25Z"}, {"author": "Ketan Talaulikar", "text": "<p>s/everyone/every algo</p>", "time": "2024-11-07T10:21:37Z"}, {"author": "Les Ginsberg", "text": "<p>This is why discussion of enablement method needs to be separate from algorithm. There is a substantive discussion which needs to take place which should be separate from whether a given alorithm is something we should standardize. Please enable this discussion by separarting the two discussions.</p>", "time": "2024-11-07T10:25:49Z"}, {"author": "Shraddha Hegde", "text": "<p>@ketan, My understanding is that what you describe is specific to leaderless mode of operation. In area leader operation, the assumption has to be that everyone runs same algo. Thats why algo will be slightly different (very small nuance though) based on what framework it runs</p>", "time": "2024-11-07T10:40:10Z"}, {"author": "Ketan Talaulikar", "text": "<p>@Shraddha, I believe it is practically the same thing but I will double check.</p>", "time": "2024-11-07T10:46:45Z"}, {"author": "Les Ginsberg", "text": "<p>@shraddha Leader based enablement guarantees that there is only one optimized flooding algorithm being used in the network. Nodes can use standard flooding - but they cannot use a different non-standard algorithm. Unless you actually want to run multiple non-standard algorithms at the same time - which I think is a VERY BAD IDEA - there is no issue.</p>", "time": "2024-11-07T10:50:22Z"}, {"author": "Mingqing(Michael) Huang", "text": "<p>the two routers may has the prefixes, but the interface in FIB</p>", "time": "2024-11-07T10:50:43Z"}, {"author": "Mingqing(Michael) Huang", "text": "<p>might not be correct for uRPF strict mode</p>", "time": "2024-11-07T10:50:56Z"}, {"author": "Mingqing(Michael) Huang", "text": "<p>this is kind of the typical  limitation of uRPF strict mode</p>", "time": "2024-11-07T10:53:52Z"}, {"author": "Jeffrey Haas", "text": "<p>From an overly simplified point of view, the SAV table contents for any source prefix, S, will be the union of all shortest paths for all other destinations that S can try to reach.</p>\n<p>Exactly how that's different from reaching every part of the network is part of the discussion as to whether this is a useful thing to do.</p>", "time": "2024-11-07T11:02:28Z"}, {"author": "Jeffrey Haas", "text": "<p>Additional hilarity ensues on a topology change and you have to deal with a thundering herd of updates to the sav table entry in a scale far greater than a destination based FIB update would have been.</p>", "time": "2024-11-07T11:04:13Z"}, {"author": "Martin Horneffer", "text": "<p>Is reprogramming filtering HW faster than reprogramming forwarding HW? probably not ...</p>", "time": "2024-11-07T11:05:35Z"}, {"author": "Jeffrey Haas", "text": "<p>Depending on the hardware, possibly so.  But in general, probably not.  Line card memory resources are different in fw vs. FIB entries in some vendors with different programming latencies.</p>", "time": "2024-11-07T11:06:30Z"}, {"author": "Jeffrey Haas", "text": "<p>The savnet solution space permits mixes of fib-based behaviors and fw based ones.  However, they will not scale at the same rates.</p>", "time": "2024-11-07T11:07:11Z"}, {"author": "Jeffrey Haas", "text": "<p>the vrf-table based filtering is what many cases will devolve to, and that's speed of fib programming.</p>", "time": "2024-11-07T11:07:34Z"}, {"author": "Jeffrey Haas", "text": "<p>Thank you, Peter P.</p>", "time": "2024-11-07T11:15:44Z"}]