[{"author": "Tony Przygienda", "text": "yes, we need controversy! make ospf great again vs. is - is = 0 or something !<br/>", "time": "2022-03-24T13:30:26Z"}, {"author": "Boris Khasanov", "text": "Indeed :)<br/>", "time": "2022-03-24T13:30:36Z"}, {"author": "Tony Przygienda", "text": "let's squat port 179 on TCP and start flooding that way ! oops ...<br/>", "time": "2022-03-24T13:31:04Z"}, {"author": "John Scudder", "text": ":satisfied:<br/>", "time": "2022-03-24T13:31:15Z"}, {"author": "John Scudder", "text": "Gee, who is this \"AD review\" who's holding things up? :-(<br/>", "time": "2022-03-24T13:33:23Z"}, {"author": "John Scudder", "text": "But seriously, it's moving, it's moving.<br/>", "time": "2022-03-24T13:33:50Z"}, {"author": "Tony Przygienda", "text": "routing ADs are like car repair men now IME. Just don't ask for costs or dates ...<br/>", "time": "2022-03-24T13:34:13Z"}, {"author": "Jeff Tantsura", "text": "as long as it is moving in the right direction ;-)<br/>", "time": "2022-03-24T13:34:15Z"}, {"author": "Jeffrey Haas", "text": "Slow yang module revision processes were discussed in netmod.<br/>", "time": "2022-03-24T13:34:17Z"}, {"author": "Aijun Wang", "text": "every routing related group<br/>", "time": "2022-03-24T13:38:28Z"}, {"author": "Russ White", "text": "that's an empty room you have there, Jeff<br/>", "time": "2022-03-24T13:40:49Z"}, {"author": "Jeffrey Haas", "text": "More people than mpls had<br/>", "time": "2022-03-24T13:41:25Z"}, {"author": "Joel Halpern", "text": "We had a modest number of people in the room for the savnet BoF (15 or so).<br/>", "time": "2022-03-24T13:44:04Z"}, {"author": "Jeff Tantsura", "text": "@russ - IGPs are soooo yesterday ;-)<br/>", "time": "2022-03-24T13:45:33Z"}, {"author": "John Scudder", "text": "I think I forgot to say at the mic, thanks for doing this.<br/>", "time": "2022-03-24T13:47:22Z"}, {"author": "Russ White", "text": "that should have been a picture of bgp ... since we just throw anything we can think of at it :-)<br/>", "time": "2022-03-24T13:49:20Z"}, {"author": "Robert Raszuk", "text": "@russ .. was just going to say the same .. let's save this picture for reuse !<br/>", "time": "2022-03-24T13:49:48Z"}, {"author": "Jeff Tantsura", "text": "yea, I expected some hidden BGP message&nbsp;&nbsp;on the truck<br/>", "time": "2022-03-24T13:49:52Z"}, {"author": "John Scudder", "text": "<a href=\"https://www.constbgp.com\" rel=\"nofollow\">https://www.constbgp.com</a><br/>", "time": "2022-03-24T13:51:43Z"}, {"author": "Robert Raszuk", "text": ":)<br/>", "time": "2022-03-24T13:52:12Z"}, {"author": "Jeffrey Haas", "text": "&lt;3<br/>", "time": "2022-03-24T13:52:19Z"}, {"author": "Jeffrey Haas", "text": "\"BGP is a Swiss army knife.&nbsp;&nbsp;Actually, it's all knives.\"<br/>", "time": "2022-03-24T13:52:36Z"}, {"author": "John Scudder", "text": "I remember that but not who said it. Was it prz? Stefano?<br/>", "time": "2022-03-24T13:53:12Z"}, {"author": "Jeffrey Haas", "text": "prz<br/>", "time": "2022-03-24T13:53:19Z"}, {"author": "John Scudder", "text": "probably more manageable to ask questions one at a time and let the speaker respond one at a time, if you actually want answers<br/>", "time": "2022-03-24T13:54:16Z"}, {"author": "Stefano Previdi", "text": "@john. My memory archive doesn't go that far...;-)<br/>", "time": "2022-03-24T13:54:58Z"}, {"author": "John Scudder", "text": ":-)<br/>", "time": "2022-03-24T13:55:04Z"}, {"author": "Robert Raszuk", "text": "@Stefano ... your memory is just FIFO<br/>", "time": "2022-03-24T13:55:45Z"}, {"author": "Stefano Previdi", "text": "@Robert: qualify \"memory\"...<br/>", "time": "2022-03-24T13:56:15Z"}, {"author": "Russ White", "text": "maybe this should go in rtgwg -- @jeff?<br/>", "time": "2022-03-24T13:56:17Z"}, {"author": "John Scudder", "text": "no matter what group it's in, jeff will be chairing<br/>", "time": "2022-03-24T13:56:36Z"}, {"author": "Jeff Tantsura", "text": "@john as ct/car discussion proved - answers don't matter ;-)<br/>", "time": "2022-03-24T13:56:45Z"}, {"author": "John Scudder", "text": ":cry:<br/>", "time": "2022-03-24T13:57:23Z"}, {"author": "Jeffrey Haas", "text": "Whereas I regularly have conversations with people that want to reduce protocol count in their ecosystems.<br/>", "time": "2022-03-24T14:01:17Z"}, {"author": "Russ White", "text": "@tli -- I completely agree with this ... more smaller protocols rather than keep stuffing things into the protocols we have<br/>", "time": "2022-03-24T14:01:21Z"}, {"author": "Jeff Tantsura", "text": "some have deployed kafka connectors...<br/>", "time": "2022-03-24T14:05:17Z"}, {"author": "Aijun Wang", "text": "@tony. Additional questions that are not answered on the mic are here:<br/>1) The pressure on ABR is not only the sessions number, but the registration prefixes.<br/>2) Only the ABR can act such role. other internal IGP nodes can't accomplish this task<br/>", "time": "2022-03-24T14:06:26Z"}, {"author": "Jeff Tantsura", "text": "meetecho<br/>", "time": "2022-03-24T14:06:48Z"}, {"author": "Jeff Tantsura", "text": "SoS<br/>", "time": "2022-03-24T14:06:59Z"}, {"author": "Meetecho", "text": "What's the issue?<br/>", "time": "2022-03-24T14:07:09Z"}, {"author": "Jeff Tantsura", "text": "no audio<br/>", "time": "2022-03-24T14:07:13Z"}, {"author": "Zhibo Hu", "text": "@Russ White&nbsp;&nbsp;Dealing with coupling between multiple protocols can be a disaster.<br/>", "time": "2022-03-24T14:07:29Z"}, {"author": "Jeff Tantsura", "text": "Jie - we can't hear you<br/>", "time": "2022-03-24T14:07:30Z"}, {"author": "Jeffrey Haas", "text": "I can hear jie<br/>", "time": "2022-03-24T14:07:30Z"}, {"author": "Jeff Tantsura", "text": "can't<br/>", "time": "2022-03-24T14:07:35Z"}, {"author": "Meetecho", "text": "Jie is not audible in the room?<br/>", "time": "2022-03-24T14:07:52Z"}, {"author": "Jeff Tantsura", "text": "let's wait for meetecho<br/>", "time": "2022-03-24T14:07:53Z"}, {"author": "Jeff Tantsura", "text": "no<br/>", "time": "2022-03-24T14:07:57Z"}, {"author": "Gunter Van de Velde", "text": "yes, i can hear you<br/>", "time": "2022-03-24T14:08:00Z"}, {"author": "Louis Chan", "text": "i can hear<br/>", "time": "2022-03-24T14:08:03Z"}, {"author": "Jeff Tantsura", "text": "neither chris<br/>", "time": "2022-03-24T14:08:03Z"}, {"author": "Meetecho", "text": "We can hear on Meetecho<br/>", "time": "2022-03-24T14:08:04Z"}, {"author": "Hao Li", "text": "can hear<br/>", "time": "2022-03-24T14:08:12Z"}, {"author": "Jeff Tantsura", "text": "not in the room<br/>", "time": "2022-03-24T14:08:13Z"}, {"author": "Meetecho", "text": "Checking<br/>", "time": "2022-03-24T14:08:20Z"}, {"author": "Gunter Van de Velde", "text": "(oh, but i am remote)<br/>", "time": "2022-03-24T14:08:20Z"}, {"author": "Tony Przygienda", "text": "e'one remote. jeff can go drink a beer and we continue ;-)<br/>", "time": "2022-03-24T14:08:38Z"}, {"author": "John Scudder", "text": "can ppl in the room join from personal laptops while the room audio is being debugged<br/>", "time": "2022-03-24T14:09:18Z"}, {"author": "Acee Lindem", "text": "Please join on laptop<br/>", "time": "2022-03-24T14:09:22Z"}, {"author": "John Scudder", "text": "so that we can continue the meeting pls?<br/>", "time": "2022-03-24T14:09:23Z"}, {"author": "Meetecho", "text": "Sending someone over<br/>", "time": "2022-03-24T14:09:36Z"}, {"author": "Meetecho", "text": "But are all remote participants not audible?<br/>", "time": "2022-03-24T14:09:49Z"}, {"author": "Meetecho", "text": "Or ust Jie?<br/>", "time": "2022-03-24T14:09:52Z"}, {"author": "Christian Hopps", "text": "Everytone remote can hear<br/>", "time": "2022-03-24T14:10:01Z"}, {"author": "Jeff Tantsura", "text": "all<br/>", "time": "2022-03-24T14:10:03Z"}, {"author": "Christian Hopps", "text": "it's only the in room<br/>", "time": "2022-03-24T14:10:05Z"}, {"author": "John Scudder", "text": "all remote ppl can hear one another<br/>", "time": "2022-03-24T14:10:07Z"}, {"author": "Jeff Tantsura", "text": "I use audio from my laptop into the mike<br/>", "time": "2022-03-24T14:10:16Z"}, {"author": "Meetecho", "text": "Can remote participants hear audio from the room'<br/>", "time": "2022-03-24T14:10:19Z"}, {"author": "John Scudder", "text": "thanks jeff<br/>", "time": "2022-03-24T14:10:23Z"}, {"author": "John Scudder", "text": "we do not hear audio comign from the room but then again I don't know if anyone is talking<br/>", "time": "2022-03-24T14:10:36Z"}, {"author": "Christian Hopps", "text": "that'll be fun when it gets fixed :)<br/>", "time": "2022-03-24T14:10:40Z"}, {"author": "Meetecho", "text": "Ack, found the issue<br/>", "time": "2022-03-24T14:10:42Z"}, {"author": "Meetecho", "text": "Fixing it, just a sec<br/>", "time": "2022-03-24T14:10:46Z"}, {"author": "Wim Henderickx", "text": "we can hear in the meeting<br/>", "time": "2022-03-24T14:10:51Z"}, {"author": "Eduard V", "text": "It is more reliable to be remote. The world virtualized.<br/>", "time": "2022-03-24T14:10:55Z"}, {"author": "Jeff Tantsura", "text": "we are back<br/>", "time": "2022-03-24T14:11:04Z"}, {"author": "Jeff Tantsura", "text": "thanks meetecho!<br/>", "time": "2022-03-24T14:11:10Z"}, {"author": "Aijun Wang", "text": "broken<br/>", "time": "2022-03-24T14:11:11Z"}, {"author": "Meetecho", "text": "Should be working now, can you confirm?<br/>", "time": "2022-03-24T14:11:23Z"}, {"author": "Jeff Tantsura", "text": "yes<br/>", "time": "2022-03-24T14:11:27Z"}, {"author": "Jeff Tantsura", "text": "confirmed<br/>", "time": "2022-03-24T14:11:36Z"}, {"author": "Tony Li", "text": "@Aijun: 1) There is only one registration prefix assuming you're willing to put all loopbacks into that prefix.<br/>", "time": "2022-03-24T14:11:41Z"}, {"author": "Tony Li", "text": "2) No, it doesn't need to be the ABR.&nbsp;&nbsp;Any node that sees the area LSDB can provide liveness. The capability TLVs allow the ABRs to designate proxies for the NLP service within their area.<br/>", "time": "2022-03-24T14:12:49Z"}, {"author": "Aijun Wang", "text": "how the node in one area finds the proxies in another area?<br/>", "time": "2022-03-24T14:13:46Z"}, {"author": "Tony Li", "text": "Capability in the L2 LSDB.<br/>", "time": "2022-03-24T14:14:03Z"}, {"author": "Jeff Tantsura", "text": "@tony: from implementation prospective, would you have RIB registration and invalidation based on the state?<br/>", "time": "2022-03-24T14:14:56Z"}, {"author": "Les Ginsberg", "text": "@Tony: Non-ABR nodes providing the service have to have access to L1 and L2 LSPDB - otherwise they do not know what is being summarized. Unless you want to allow the service notifications to be completely redundant.<br/>", "time": "2022-03-24T14:14:58Z"}, {"author": "Tony Li", "text": "Ok, the proxy probably needs to be an L1L2 node.<br/>", "time": "2022-03-24T14:15:00Z"}, {"author": "Jeff Tantsura", "text": "+1 les<br/>", "time": "2022-03-24T14:15:23Z"}, {"author": "Tony Li", "text": "@Jeff This has nothing to do with the RIB. It's just data propagation. Do with the data as you will...<br/>", "time": "2022-03-24T14:15:41Z"}, {"author": "Aijun Wang", "text": "regarding to point 1), if there are 1000 nodes in one area, there will be 1000 loopback address registration, even these 1000 loopbacks are allocated under one prefixes<br/>", "time": "2022-03-24T14:16:16Z"}, {"author": "Tony Li", "text": "You're assuming that the registration database is /32 or /128.&nbsp;&nbsp;It doesn't need to be.<br/>", "time": "2022-03-24T14:16:48Z"}, {"author": "Boris Khasanov", "text": "@Tony, sorry I didn't get: what is the fundamental difference between liveness signaling via push/subs vs. existing IGP LSP? Speed, resilience, less resources consumption or what?&nbsp;&nbsp;Why should we trust registration more, for example?<br/>", "time": "2022-03-24T14:17:43Z"}, {"author": "Tony Li", "text": "The point is to take the burden off of the IGP.<br/>", "time": "2022-03-24T14:18:05Z"}, {"author": "Aijun Wang", "text": "the ABR can summary the registration. But for the first ABR, it must register the specific /32 or /128 address<br/>", "time": "2022-03-24T14:18:08Z"}, {"author": "Tony Li", "text": "The first ABR can see summaries advertised by other ABRs.<br/>", "time": "2022-03-24T14:18:29Z"}, {"author": "Jeff Tantsura", "text": "tony: of course, not directly, but the end consumer uses this to resolve (or invalidate) routes behind some next-hops<br/>", "time": "2022-03-24T14:18:32Z"}, {"author": "Tony Li", "text": "It registers with each ABR for the prefix that the ABR advertised.<br/>", "time": "2022-03-24T14:18:43Z"}, {"author": "Tony Li", "text": "@Jeff, correct.<br/>", "time": "2022-03-24T14:19:05Z"}, {"author": "Jeff Tantsura", "text": "@tony - similarly to BFD registrations<br/>", "time": "2022-03-24T14:20:45Z"}, {"author": "Tony Li", "text": "Except that we don't need to send packets every 10ms<br/>", "time": "2022-03-24T14:21:07Z"}, {"author": "Jeff Tantsura", "text": "sure, but the end result is exactly the same<br/>", "time": "2022-03-24T14:21:46Z"}, {"author": "Tony Li", "text": "There are many things that people seem to think are 'equivalent' PUA solutions.<br/>", "time": "2022-03-24T14:22:37Z"}, {"author": "Aijun Wang", "text": "@tony. The ABR should advertise the register the liveness of another loopback address, not the summary address<br/>", "time": "2022-03-24T14:23:49Z"}, {"author": "Ketan Talaulikar", "text": "@ Jie, it would be good if the authors can clearly identify and segregate the info that IGPs are actually going to use (i.e. for route calc, programming into fwd, etc.) and stuff that IGPs are simply flooding for someone else to consume. For the later set, some justification for why this needs to be in the IGPs would be good to add.<br/>", "time": "2022-03-24T14:24:02Z"}, {"author": "Tony Li", "text": "@Aijun Not in my proposal.<br/>", "time": "2022-03-24T14:24:16Z"}, {"author": "Tony Li", "text": "That approach would scale poorly.<br/>", "time": "2022-03-24T14:24:35Z"}, {"author": "Jie Dong", "text": "@Ketan, thanks for your suggestion, will clarify the usage<br/>", "time": "2022-03-24T14:25:51Z"}, {"author": "Aijun Wang", "text": "@tony, then, if only one of node within the prefix failed, but others are alive. how you notify the register via the summary prefix<br/>", "time": "2022-03-24T14:32:10Z"}, {"author": "Tony Li", "text": "Registrations are prefixes. Notifications are hosts within those prefixes.<br/>", "time": "2022-03-24T14:32:40Z"}, {"author": "Aijun Wang", "text": "OK, I know. but it sound a little strange. because the prefixes are reachable<br/>", "time": "2022-03-24T14:34:39Z"}, {"author": "Tony Li", "text": "This has nothing to do with reachability.<br/>", "time": "2022-03-24T14:35:13Z"}, {"author": "Aijun Wang", "text": "the prefixes are live<br/>", "time": "2022-03-24T14:36:13Z"}, {"author": "Tony Li", "text": "It's pretty simple. Suppose loopbacks are in 10/8 network wide.<br/>", "time": "2022-03-24T14:36:13Z"}, {"author": "Tony Li", "text": "Area 1 has loopbacks in 10.1/16, area 2 has them in 10.2/16, etc.<br/>", "time": "2022-03-24T14:36:30Z"}, {"author": "Tony Li", "text": "Now node A registers for 10/8.&nbsp;&nbsp;Node B registers with node C for 10.2/16. Node D fails and node C generates a notification for 10.2.1.1/32.<br/>", "time": "2022-03-24T14:37:24Z"}, {"author": "Aijun Wang", "text": "No, I think there are problem on your assumption here.<br/>", "time": "2022-03-24T14:38:14Z"}, {"author": "Aijun Wang", "text": "node A may tunnel with 10.2.1.2<br/>", "time": "2022-03-24T14:38:55Z"}, {"author": "Aijun Wang", "text": "when it receives the summary notification, will it switchover?<br/>", "time": "2022-03-24T14:39:25Z"}, {"author": "Tony Li", "text": "There are no summary notifications.<br/>", "time": "2022-03-24T14:39:37Z"}, {"author": "Tony Li", "text": "It gets a notification for 10.2.1.2/32<br/>", "time": "2022-03-24T14:39:54Z"}, {"author": "Aijun Wang", "text": "So, registration summary, but notification is specific?<br/>", "time": "2022-03-24T14:40:03Z"}, {"author": "Tony Li", "text": "Yes!<br/>", "time": "2022-03-24T14:40:10Z"}, {"author": "Jeff Tantsura", "text": ":)<br/>", "time": "2022-03-24T14:40:17Z"}, {"author": "Louis Chan", "text": "@Tony, you might consider notifications with all-alive-but, or all-dead-but.<br/>", "time": "2022-03-24T14:40:24Z"}, {"author": "Tony Li", "text": "Now you're just making things complicated for fun. :smile:<br/>", "time": "2022-03-24T14:40:51Z"}, {"author": "Boris Khasanov", "text": "@Tony, if&nbsp;&nbsp;we want to use other than ABRs routers for&nbsp;&nbsp;the registration, how that role will be assigned?&nbsp;&nbsp;Any thoughts?<br/>", "time": "2022-03-24T14:41:48Z"}, {"author": "Andrew Stone", "text": "Tony: might want to just describe the registration message as basically a filter for notifications on a per-prefix level (note i didnt read the doc yet...)<br/>", "time": "2022-03-24T14:42:24Z"}, {"author": "Andrew Stone", "text": "by per prefix level, i mean, the filter is applied but end consumer receives notifs per prefix<br/>", "time": "2022-03-24T14:43:00Z"}, {"author": "Tony Li", "text": "@Boris As noted above, it would need to be an L1L2 router so that it sees both databases.&nbsp;&nbsp;Set the overload bit so that it doesn't carry traffic.<br/>", "time": "2022-03-24T14:43:05Z"}, {"author": "Tony Li", "text": "@Andrew There are many ways to do it.<br/>", "time": "2022-03-24T14:43:42Z"}, {"author": "Robert Raszuk", "text": "@Tony - Does it need to really be a router ? How about just node listening passively to both L1 and L2 areas ?<br/>", "time": "2022-03-24T14:44:49Z"}, {"author": "Tony Li", "text": "That suffices.<br/>", "time": "2022-03-24T14:45:01Z"}, {"author": "Jeff Tantsura", "text": "i think we have a presentation on IGP monitor later today?<br/>", "time": "2022-03-24T14:45:23Z"}, {"author": "Boris Khasanov", "text": "@Tony, I thought about using some centralized way of assignments, via controller for example.<br/>", "time": "2022-03-24T14:45:35Z"}, {"author": "Aijun Wang", "text": "@boris, yes, this is the normal PUB/SUB procedures<br/>", "time": "2022-03-24T14:46:55Z"}, {"author": "Tony Li", "text": "@Boris We know that global controllers don't scale and we end up with hierarchical controllers. Which is not very different than this.<br/>", "time": "2022-03-24T14:48:13Z"}, {"author": "Tony Li", "text": "I will wait until the end.<br/>", "time": "2022-03-24T14:50:37Z"}, {"author": "Tony Przygienda", "text": "unless you really, really absolutely max. speed reaction time here (which is Tony's solution) an IETF free, cheap solution consists of a passive session to an ABR, bitsy code and a kafka bus or 0MQ ;-) But hey, where's the fun in that, nothing new to invent, no new stuff to hack into IGPs, no operational crisis when another obscure sideways hack takes the whole network down ;-)<br/>", "time": "2022-03-24T14:52:05Z"}, {"author": "Zhibo Hu", "text": "Would PUB/SUB be a disaster if all nodes needed to know the reachability of all nodes?<br/>", "time": "2022-03-24T14:53:39Z"}, {"author": "Jeff Tantsura", "text": "I'd argue that \"on change\" streaming notification into kafka/similar bus would have rather similar (speed wise) characteristics<br/>", "time": "2022-03-24T14:54:20Z"}, {"author": "Tony Przygienda", "text": "@Zhibo: chicken and egg. how will a node know how to get to the bus/server if there's no forwarding yet? ;-)<br/>", "time": "2022-03-24T14:54:41Z"}, {"author": "Robert Raszuk", "text": "@Zhibo - no. Today all nodes in IGP do know how to reach other nodes. Here we are taking about liveness.<br/>", "time": "2022-03-24T14:54:58Z"}, {"author": "Tony Przygienda", "text": "people always think IGPs are superfluous until they stand there with a packet in their hands and say \"eeehe, how do I get there\"?<br/>", "time": "2022-03-24T14:55:22Z"}, {"author": "John Scudder", "text": ":satisfied:<br/>", "time": "2022-03-24T14:56:24Z"}, {"author": "Tony Li", "text": "@Zhibo The nice thing about PUB/SUB is that it can go slowly if necessary. Sure, under stress, convergence time may suck, but that's far better than collapsing.<br/>", "time": "2022-03-24T14:56:42Z"}, {"author": "Aijun Wang", "text": "IGP has the existing mechanism to do the notification, which is no burden to the router(no SPF involved)<br/>", "time": "2022-03-24T14:57:14Z"}, {"author": "Tony Li", "text": "Except that you're adding arbitrary stuff to the LSDB.<br/>", "time": "2022-03-24T14:58:15Z"}, {"author": "Zhibo Hu", "text": "If any-to-any PUB/SUB is used, IGP is more efficient.<br/>", "time": "2022-03-24T14:58:23Z"}, {"author": "Tony Li", "text": "Which is why it's hierarchical.<br/>", "time": "2022-03-24T14:58:50Z"}, {"author": "Jeff Tantsura", "text": "@zhibo - no<br/>", "time": "2022-03-24T14:59:21Z"}, {"author": "Tony Przygienda", "text": "@Zhibo: you may be underestimating flooding &amp; SPF speeds and overestimate seriously how fast pub/sub systems can go, especially with slow receivers (building a serious BGP is very educational in this respect if you didn't implement other buses along Kafka lines ;-) RFC1925 #4 ;-)<br/>", "time": "2022-03-24T14:59:33Z"}, {"author": "Jeff Tantsura", "text": "+1 prz<br/>", "time": "2022-03-24T14:59:52Z"}, {"author": "Zhibo Hu", "text": "In addition, we have a document MFI that is trying to isolate the impact of different IGP flooding instances, and I think it would be better to resolve it within the protocol than to create a new protocol.<br/>", "time": "2022-03-24T15:00:06Z"}, {"author": "Tony Przygienda", "text": "lots of that has to do with fact that you cannot compare a modern 64cores memory loaded server hacked in hugely parallel fashion going fast and dying on bugs in nice regular fashion to a box that you drop into a basement double caged sitting there ideally for 15 years without being touched except cabling changes<br/>", "time": "2022-03-24T15:00:45Z"}, {"author": "Jeff Tantsura", "text": "there's a reason we do BMP and streaming telemetry in general<br/>", "time": "2022-03-24T15:00:49Z"}, {"author": "Robert Raszuk", "text": "If anything I would like to get clarity on key requirement - some folks claim that the mechanism (regardless which one) is needed to signal remote PE (service) node liveness across areas. Yet another group of folks claim that we also need to signal segment endpoints (possibly each P router) across areas. So do we have any agreement that both requirements are sound and we need to address them ?<br/>", "time": "2022-03-24T15:03:27Z"}, {"author": "Zhibo Hu", "text": "Node liveness is not a common occurrence. I don't think IGP advertising node liveness will lead to flooding crashes.<br/>", "time": "2022-03-24T15:03:49Z"}, {"author": "Boris Khasanov", "text": "@Tony P. RFC1925 has also #6 :)<br/>", "time": "2022-03-24T15:04:13Z"}, {"author": "Robert Raszuk", "text": "@Zhibo - then do not summarize node loopbacks and we are done.<br/>", "time": "2022-03-24T15:04:32Z"}, {"author": "Tony Przygienda", "text": "@Boris, yeah, #6 leads to people trying to dump truck IGPs as \"broadcast bus\" since they existed instead of building a proper solution in their own layer<br/>", "time": "2022-03-24T15:05:41Z"}, {"author": "Zhibo Hu", "text": "Summary is mandatory. Summary is used to reduce information about live nodes. Most nodes are in the live state.<br/>", "time": "2022-03-24T15:05:44Z"}, {"author": "Tony Li", "text": "So then we don't need PUA.<br/>", "time": "2022-03-24T15:06:26Z"}, {"author": "Robert Raszuk", "text": "stable information (as you claim it is such) do not hurt IGP scaling<br/>", "time": "2022-03-24T15:06:31Z"}, {"author": "Tony Przygienda", "text": "in simple words: routing protocols do reachability, what \"liveliness\" is is service access point availability and it is NOT a routing protocol problem/space. If people insist to dumptruck the protocol the best we can do is what Tony suggests, give them PUB/SUB service endpoints ideally and if they're too lazy to build their pub/sub provide simplest pub/sub possible<br/>", "time": "2022-03-24T15:06:48Z"}, {"author": "Boris Khasanov", "text": "Very good discussion!<br/>", "time": "2022-03-24T15:07:54Z"}, {"author": "Jeff Tantsura", "text": "along this lines - if your org is ops heavy, out of band solution might be better choice (building scalable and reliable collector infra&nbsp;&nbsp;ta scale is somewhat black magic), otherwise what tony proposed might fit better<br/>", "time": "2022-03-24T15:09:18Z"}, {"author": "Zhibo Hu", "text": "In fact, the IGP itself needs the node liveness status to select the correct ABR. One ABR notifies the node liveness status, and the other ABR notifies the node liveness status.<br/>", "time": "2022-03-24T15:10:58Z"}, {"author": "Zhibo Hu", "text": "In fact, the IGP itself needs the node liveness status to select the correct ABR. One ABR notifies the node live status, and the other ABR notifies the node liveness status.<br/>", "time": "2022-03-24T15:11:41Z"}, {"author": "Robert Raszuk", "text": "Nope .. ABRs are local to the area ... no livness is needed to select correct ABR<br/>", "time": "2022-03-24T15:12:36Z"}, {"author": "Jeff Tantsura", "text": "yep<br/>", "time": "2022-03-24T15:12:43Z"}, {"author": "Christian Hopps", "text": "@meetecho is there a way to increase the volume on the in-room mic in the remote mix?<br/>", "time": "2022-03-24T15:13:12Z"}, {"author": "John Scudder", "text": "the gain control in the lower right helps a little<br/>", "time": "2022-03-24T15:13:38Z"}, {"author": "Zhibo Hu", "text": "Other areas node&nbsp;&nbsp;select appropriate ABRs<br/>", "time": "2022-03-24T15:13:50Z"}, {"author": "Christian Hopps", "text": "yeah just found that, better, with all volume levels maxd though<br/>", "time": "2022-03-24T15:14:02Z"}, {"author": "Zhibo Hu", "text": "We will list some other cases in PUA. In fact, BGP does not only benefit from the node liveness status.<br/>", "time": "2022-03-24T15:14:51Z"}, {"author": "Christian Hopps", "text": "fwiw this has been a problem in every WG i've attended.. so maybe htis is a site-wide thing that could be fixed next time<br/>", "time": "2022-03-24T15:14:53Z"}, {"author": "Acee Lindem", "text": "Pardon my queue squatting...<br/>", "time": "2022-03-24T15:15:21Z"}, {"author": "Tony Przygienda", "text": "to be frank, there is a lot of naive parties here pushing for stuff (service liveliness) they vastly underestimate in terms of difficulty, even providing a good, reliable notification. Imagine what happens if you registers @ 2 ABRs and one of them sets overload bit. Theoretically it should notify you e'thing behind it is _dead_ but guess what, you either on getting both notifications need to coallesce those (hello, massive async FSMs) or the ABRs need compute from point of view of _other_ ABRs. Now what about registration coming from left and right and you that right a guy in the middle set overload. Now do you send a down notification on the right interface only? I can come up with examples like that for a long time, what you ask graph theory wise is a&nbsp;&nbsp;very complex problem to put into a topology protocol, your best guess is to say \"if both parties can reach a common point (pub/sub) then the service is up\". Enjoy parsing it ;-)<br/>", "time": "2022-03-24T15:16:14Z"}, {"author": "Robert Raszuk", "text": "#Tony - I asked that on the list. Les responded that overload or max-age would not be a trigger in any case.<br/>", "time": "2022-03-24T15:17:28Z"}, {"author": "Meetecho", "text": "Christian: the speaker mic sounds fine, not sure about the in-room mic one as no one is speaking there. Speaking closer to the mic may help. We'd rather not touch the mic levels as we risk causing echo when remote speakers talk<br/>", "time": "2022-03-24T15:17:35Z"}, {"author": "Tony Przygienda", "text": "right, we can make all kind of wonderful assumptions and end up with 1925 #7<br/>", "time": "2022-03-24T15:17:59Z"}, {"author": "Christian Hopps", "text": "Well I would question \"sounds fine\" I have all volumes maxed to barely hear the speaker, so when someone remote talks it will blast my eardrum.. having attended too many loud rock shows this causes pain :)<br/>", "time": "2022-03-24T15:18:48Z"}, {"author": "Meetecho", "text": "You're talking to a metalhead so I can relate :D<br/>", "time": "2022-03-24T15:19:17Z"}, {"author": "Meetecho", "text": "We'll try to better balance the levels when we do our sound checks tomorrow morning<br/>", "time": "2022-03-24T15:19:48Z"}, {"author": "Christian Hopps", "text": "thanks :)<br/>", "time": "2022-03-24T15:20:21Z"}, {"author": "Tony Przygienda", "text": "yeah, getting a good passive monitoring solution would be a great workitem here. it may even get rid of the bgp-ls wart in long term ;-)<br/>", "time": "2022-03-24T15:25:01Z"}, {"author": "Wim Henderickx", "text": "@tony, was just going to ask can we not use bgp-ls, but seems i know your answer :-)<br/>", "time": "2022-03-24T15:25:39Z"}, {"author": "Christian Hopps", "text": "I like acee's comment about usign the protocol where we can and just add what's missing.<br/>", "time": "2022-03-24T15:25:46Z"}, {"author": "Christian Hopps", "text": "if you trust the monitor node enough to let them onto your network you can trust them not to advertise LSAs too I guess<br/>", "time": "2022-03-24T15:26:12Z"}, {"author": "Tony Przygienda", "text": "you can, I'm fighting the warts every day. Don't get me started ... BGP-LS _almost_ does the IGP database and it _almost_ reflects flooding<br/>", "time": "2022-03-24T15:26:20Z"}, {"author": "Robert Raszuk", "text": "@Wim - if you recall I proposed how to use BGP for this notification. And no need to go into LU .. any SAFI and recursion works fine.<br/>", "time": "2022-03-24T15:26:34Z"}, {"author": "Tony Przygienda", "text": "the _almost_ at scale in high reliability deployments are what makes me loose sleep at night regularly ...<br/>", "time": "2022-03-24T15:26:47Z"}, {"author": "Jeff Tantsura", "text": "I don't see realistic alternative to BGP-LS is the next 3 or so years<br/>", "time": "2022-03-24T15:27:27Z"}, {"author": "Boris Khasanov", "text": "+1 to Jeff. We still need BGP-LS in mid-term perspective&nbsp;&nbsp;(it is supported by the majority of vendors in some level)<br/>", "time": "2022-03-24T15:27:46Z"}, {"author": "Tony Przygienda", "text": "the BGP-LS guys were warned about the sins they're committing but they just ploughed ahead ... having BGP being a conduit would have been fine, having done it right would have been fine (like keeping seqnr#) but the way it's done it's a fine toy until you really, really want equivalent of \"what is IGP seeing\" ...<br/>", "time": "2022-03-24T15:28:21Z"}, {"author": "Aijun Wang", "text": "BGP-LS has far scope than the IGP based solution<br/>", "time": "2022-03-24T15:28:23Z"}, {"author": "Tony Przygienda", "text": "so if you _really_ want to know what IGP is seeing passive monitoring cannot be beat. And effort to parse packets is vastly exaggerated. But yes, I know I likely talk scale &amp; timings &amp; reliability asked by very demanding customers which is not reality for vast majority of folks ...<br/>", "time": "2022-03-24T15:29:56Z"}, {"author": "Wim Henderickx", "text": "would it not be useful to do a generic monitor mechanism which is protocol agnostic. Like the pub/sub proposal Toni has for liveness. Rather than overloading the protocol have extendability for these use cases.<br/>", "time": "2022-03-24T15:30:08Z"}, {"author": "Ketan Talaulikar", "text": "@Tony +1 - BGP-LS does not provide the real IGP machinery view ... its only a topology view<br/>", "time": "2022-03-24T15:30:35Z"}, {"author": "Jeff Tantsura", "text": "@prz, in general - there's enough data to be actionable (icw with some other things)<br/>", "time": "2022-03-24T15:31:03Z"}, {"author": "Boris Khasanov", "text": "ccvktdvudlfdigiuknegcjukctteghfbjuitiihn<br/>", "time": "2022-03-24T15:31:16Z"}, {"author": "Tony Przygienda", "text": "@Wim yes, it's thinkable. but I fear we devolve very quickly into generic query language if you want to know certain \"closures\" on link state database notified/published<br/>", "time": "2022-03-24T15:31:17Z"}, {"author": "Tony Li", "text": "BGP-LS could have simply done a bcopy of the LSP/LSA as it was updated. That would have been simpler and more extensible.<br/>", "time": "2022-03-24T15:31:21Z"}, {"author": "Tony Przygienda", "text": "@Tony: yepp, that's the conduit thing. They were being told that over and over again ...<br/>", "time": "2022-03-24T15:31:45Z"}, {"author": "Boris Khasanov", "text": "Sorry. @Wim - what customers should do while this new protocol is not available at least on 2 major vendors boxes?<br/>", "time": "2022-03-24T15:32:03Z"}, {"author": "Jeff Tantsura", "text": "they = you ;-)<br/>", "time": "2022-03-24T15:32:04Z"}, {"author": "Ketan Talaulikar", "text": "but then we would need practically an OSPF or ISIS implementation to parse and also figure out what is \"usable\"<br/>", "time": "2022-03-24T15:32:05Z"}, {"author": "Tony Li", "text": "Which is now common.&nbsp;&nbsp;Next problem?<br/>", "time": "2022-03-24T15:32:33Z"}, {"author": "Tony Li", "text": "A passive node on the end of a tunnel is a simple solution to all of it.<br/>", "time": "2022-03-24T15:33:00Z"}, {"author": "Tony Przygienda", "text": "+1 and that's the root of my comment, yes, let's provide a good passive monitoring solution on IGP adjacency so people stop hacking stuff like not going FULL in OSPF<br/>", "time": "2022-03-24T15:33:30Z"}, {"author": "Robert Raszuk", "text": "Parsing LS is not an issue. I was always told that reason to trash BGP was requirement for BGP-LS to do intelligent NNI across domains hence need to understand the content<br/>", "time": "2022-03-24T15:33:58Z"}, {"author": "John Scudder", "text": "thanks for ending almost-on-time :-)<br/>", "time": "2022-03-24T15:34:19Z"}, {"author": "Tony Przygienda", "text": "good session ,thanks e'one !<br/>", "time": "2022-03-24T15:34:35Z"}, {"author": "Boris Khasanov", "text": "thanks everyone!<br/>", "time": "2022-03-24T15:34:40Z"}, {"author": "Jie Dong", "text": "thanks<br/>", "time": "2022-03-24T15:34:42Z"}, {"author": "Jeff Tantsura", "text": "thanks!<br/>", "time": "2022-03-24T15:34:47Z"}, {"author": "Christian Hopps", "text": "thanks everybody!<br/>", "time": "2022-03-24T15:35:49Z"}]