IETF 113 LSR Agenda Chairs: Acee Lindem (acee@cisco.com) Chris Hopps (chopps@chopps.org) Secretary: Yingzhen Qu (yingzhen.ietf@gmail.com) WG Page: http://tools.ietf.org/wg/lsr/ Materials: https://datatracker.ietf.org/meeting/113/session/lsr 1. Meeting Administrivia and WG Update Chairs (10 mins) 2. Update to OSPF Terminology Acee Lindem (10 mins) https://datatracker.ietf.org/doc/draft-fox-lsr-ospf-terminology/ Acee: 2328 is already an Internet standard. Chris H: To me, this is a better way. Acee: I’d look at the product documentation, not the standard. John: There are lots of RFC impacted, I do see the value of publishing one short doc with all the updates. But I would hope subsequently we may actually take care of all the changes, better to have it in the spec itself. Notes from HedgeDoc: Chris H.: would be nice if we could bis the base with errata, maybe will be easier later with this doc John S.: I had similar though as Chris, would be nice to rev the doc, but then saw the long list of impacted docs and thought there was some value to a small single update doc 3. Node Liveness Protocol Tony Li (15 mins) https://datatracker.ietf.org/doc/draft-li-lsr-liveness/ Aijun: First there are existing pub-sub mechanics, why do we need a new one? Second why IGP WG? Third for ABR, it must keep registration table, will stress the ABR. You can find other nodes to do the work. Tony Li: Buffer overrun. For your first question, I haven’t see any pub-sub protocol in IETF, if you know any please let me know. Can you repeat other questions? Aijun : Maybe a new WG for this work? It belongs to more than IGP. Tony: I agree it could go outside of LSR. Just we started here because of LSR problem, the problem was raise here. if the WG thinks it’s interesting and want to take it somewhere. Linda: Do you do registration for client node or all nodes? Tony: Currently the registration is for prefixes. Linda: Isn’t that the same as LSA? Tony: We’re not advertising anything. This is a request. Himanshu: Have you considered multi-hop BFD? Tony: A is going to get notification from B, C and D. Les: You’re inventing a new application, which operators will need to config. Do you have any feedback from operators whether they like it? Tony: Some feedback from operator, but I won’t speak for him. Routers have lots of subsystems, I agree it’s a pain. But I think it’s better than overloading IGP. Les: I’m interested in whether people want to deploy. Acee: Thanks for a very readable draft. I don’t think advertising a few thousands loopbacks is that many in OSPF, they’re really small LSAs. How did you come up with “ONN”? Tony: that’s Old and New. The reason to allow aggregation is to reduce the number of registrations. Chris: the notification is at host level, correct? Tony: yes Jeff Zhang: This reminds me of BGP route-target mechanism. Tony: Not consciously mirroring it. Gyan: Are there concerns for overhead? Tony: I’m not concerned. it doesn’t have to be on the router, it can be hosted on a server. Notes from HedgeDoc: Aijun: lots of pub sub why invent new one, why in LSR WG? 2nd. Tony: I have not seen similar pub/sub in IETF, happy to reuse. Tony: problem was raised here so we started here and solving problem here, but happy to move to wherever Linda: clarification: who does registeration? Tony: register for all lection Himanshau: Have you considered ____ Tony: yes A registered for all (B and C). Les: Doesn’t like, but not, but you are inventing something that Ops will need to manage, deploy, etc… have you heard any feedback from Operators on this? Tony: I’ve heard from 1 op who is in the room, other than that no, routers already have multiple apps, one more is better than overloading the routing protocol. Acee: Jeffery: the one area to another reminds me of BGP route target registration Gyan: any concerns with overhead between the different component Tony: no not a lot of data, doesn’t even ahave to be ABR based. 4. IGP Extensions for Scalable Segment Routing based Enhanced VPN Jie Dong/Zhibo Hu (10 mins) https://datatracker.ietf.org/doc/draft-dong-lsr-sr-enhanced-vpn/ Chris: We're looking at a standard-track protocol extension based on informational draft in TEAS. It's a little early for adoption in this WG. we need to move at the right order. Jie: which doc in TEAS? Chris: There is an informational and an individual draft, you might know better. Tarek: I have similar proposal in LSR, we presented at IETF 110. I agree with Chris, it’s too early for adoption. Vishnu Pavan: The guidance from TEAS chairs is to use term NRP. Notes from HedgeDoc: Tarek: still other documents work Pavan: Use NRP-ID to refer to this not VPN+ 5. LSR for SR Proxy Forwarding Huaimo Chen (15 mins) https://datatracker.ietf.org/doc/draft-hc-lsr-sr-proxy-fw/ Chris: Is the proxy draft adopted in SPRING? Huaimo: There is an adoption call, waiting for outcome. Chris: We’ll wait for the base document to progress first. Bruno: I believe the result was sent. There is already mirror-sid in ISIS, so the question is why we need similar function? I don't think we made progress since then. Huaimo: One option is to reuse mirror SID, another is for extension of capability. Binding segment would be nice to have. Acee: I think the document Bruno brought up could be more clear. It should specify exactly when the capability should be advertised and for how long, those need to be added to the draft. Stephane: There are still work to be done in SRPING before anything in LSR. Chris: The work needs to be done in SPRING first. Notes from HedgeDoc: Bruno: SPRING thought that IS-IS extension were not needed, already functionally there. Chris H: so is this an end-run around that? Huaimo: true, but one capability bit is missing Acee: could be a lot clearer about when things happen Stephane: We need to clarify the use case first in SPRING before 6. IGP Flexible Algorithm with Deterministic Routing Shaofu Peng (10 mins) https://datatracker.ietf.org/doc/draft-peng-lsr-flex-algo-deterministic-routing/ Jeff The measurements don't match. the advertisement is per Tantsura: topology, per adj, the delay is per traffic class, you can't advertise one per traffic class. there are huge differences between how traffic classes are defined. I'm not sure you can do it. Shaofu: is your question about measurement of traffic class? Jeff T: you have different traffic classes going to the same topo. Xuesong: Stable paths are important, we should be careful when choosing distributed path calculation. We need have more discussions whether to go down this way. Acee: We should get input from the DETNET WG. One thing we need discussion on is how often you change them, for scaling etc., this needs to be in the draft. Notes from HedgeDoc: Jeff: delay is per traffic class, how does this work? Xeusong: stable path is very important for deterministic latency, which is called explicit route in DetNet. But With distributed routing computation, it is difficult to keep the path unchanged. things like delay and jitter will change accordingly. So we should be careful if we choose a distributd method for DetNet, for example Flex-algo. Acee: Need to hear from DetNet WG and the advertisement frequency should also be considered 7. Advertisement of Dedicated Metric for Flexible Algorithm in IGP Mengxiao Chen (10 mins) https://datatracker.ietf.org/doc/draft-lin-lsr-flex-algo-metric/ Tony Li: This is already available in generic metric proposal. This is redundant. Mengxiao: This is different, it's algorithm based. Using multiple user defined metrics is another solution, but may bring more complexity. Chenxi Li: If there are routers that do not support this mechanism, what will happen? The existing flex algo can solve this? Jie Dong: This is more similar to multi-topology, not original design of flex-algo. Notes from HedgeDoc: Tony: Already in Generic (mentioned by Shradda on the list). Please look again. Chenxi Li: How does this work with existing routers (ones that don’t support??) Jie Dong: This makes Flex-Algo more and more Similar to MT, while diverge from the design of Flex-Algo. Peter P: [no time cut off queue, come back if time] 8. The Application Specific Link Attribute (ASLA) Any Application Bit Shraddha Hegde (10 mins) https://datatracker.ietf.org/doc/draft-hegde-lsr-asla-any-app/ Les: I've sent an email to the list with details. The conclusion is that there is not justification of moving forward with this proposal. This will cause lots of implementation and deployment complexity, and we're not getting any benefit for. So my opinion is there's no justification for this going forward. Shraddha: You mentioned encoding efficiency, but these are just examples. If you have more attributes have to be repeated, the efficiency is better. Les: I went through 3 examples, one with some savings, the other two with no savings. The quantity of benefit is not worth the complexity. Chris: Les's examples are pretty convincing. It's coming down whether you need it, do you have any example this is needed? Are you just imagining it? Do you have real examples? Shraddha: If ASLA going forward, it should be flexible. We need to think future, how easy to extend it. Chris: We have IS-IS extended space, but never really used it. Shraddha: The TLV space gets used up is coming. Martin This is a general comment about ASLA. The fact that Horneffer: We're having a discussion here about ASLA shows that it's too complex, and don't know who really needs it. I hope we resolve this issue ASAP. Acee: speaking as chair, please read through emails and comment on this. Response to Martin, we did have operators request ASLA. Notes from HedgeDoc: Les: long email sent, there’s really no justification for moving forward on this when you look at the realistic deployments, lots of cost not lots benefit. Chris H (wg member): is there an example of running out of space, do we need this right now. Shraddha: we do have other use cases Martin: things already complex enough let’s get this resolved. Acee: please read through the mail thread on this 9. OSPF Monitor Node Alvaro Retana (10 mins) https://datatracker.ietf.org/doc/html/draft-retana-lsr-ospf-monitor-node Acee: I was saying that on the list that this was the worst way to do it, we had to change code to get rid of adj. I read this again, I think one thing you can't do is to get rid of adj and any flapping of it on the side of non-monitor node. You put th e burden on the monitoring node and you get the best backward compatibility even when the non-monitoring node doesn't support the extension. For example, you can use DR priority 0 to prevent the monitoring node from becoming DR. You just need to know the node you're connecting to and put these options in his LSA. It might be good to have a formal mechanism. Alvaro: It makes me nervous if you put everything on the new node. Notes from HedgeDoc: Acee: Most of this can be done with unchanged protocol, maybe limit to just what can’t be done 10. Anycast Affiliation Advertisement Jeffrey Zhang (10 mins) https://datatracker.ietf.org/doc/draft-zzhang-lsr-anycast-affiliation/ Linda: A good draft. We had the 5G edge draft we did it a slight different way, and we used flex-algo to identify the topology where this info is applicable. Finding anycast affiliation doesn't need to be known by any node. Jeffrey: Let's follow up offline. Acee: The idea is the ingress will use the anycast to find the service and then unicast to load balance, correct? Jeffrey: That's one of the use cases. In theory, there could be more. But you don't want to change back and forth, that may get into routing loop. Les: IGPs already have mechanism to identify anycast and the source of it. I don't think we need any extension. I don't understand why we need to mapping of anycast and unicast? Jeffrey: IS-IS N-flag is not enough. Les: We have A-flat as well. Jeffrey I'll look into that. Acee: That's a proposed draft, right? Les: We'll get there. &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& & Chat History &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& Tony Przygienda so quiet and nice ;-) 06:22:11 Ueber allen Gipfeln Ist Ruh', In allen Wipfeln Spürest Du Kaum einen Hauch; Die Vögelein schweigen im Walde. Warte nur! Balde Ruhest du auch. 06:22:14 Jeff may be the first guy who can claim having chaired _every_ group in IETF ;-) 06:27:08 Jeff Tantsura Yes, we can! 06:27:37 Tony Przygienda yes, we need controversy! make ospf great again vs. is - is = 0 or something ! 06:30:25 Boris Khasanov Indeed :) 06:30:35 Tony Przygienda let's squat port 179 on TCP and start flooding that way ! oops ... 06:31:03 John Scudder 😆 06:31:14 Gee, who is this "AD review" who's holding things up? :-( 06:33:22 But seriously, it's moving, it's moving. 06:33:49 Tony Przygienda routing ADs are like car repair men now IME. Just don't ask for costs or dates ... 06:34:12 Jeff Tantsura as long as it is moving in the right direction ;-) 06:34:14 Jeffrey Haas Slow yang module revision processes were discussed in netmod. 06:34:16 Aijun Wang every routing related group 06:38:28 Russ White that's an empty room you have there, Jeff 06:40:48 Jeffrey Haas More people than mpls had 06:41:24 Joel Halpern We had a modest number of people in the room for the savnet BoF (15 or so). 06:44:03 Jeff Tantsura @russ - IGPs are soooo yesterday ;-) 06:45:32 John Scudder I think I forgot to say at the mic, thanks for doing this. 06:47:22 Russ White that should have been a picture of bgp ... since we just throw anything we can think of at it :-) 06:49:20 Robert Raszuk @russ .. was just going to say the same .. let's save this picture for reuse ! 06:49:48 Jeff Tantsura yea, I expected some hidden BGP message on the truck 06:49:51 John Scudder https://www.constbgp.com 06:51:43 Robert Raszuk :) 06:52:12 Jeffrey Haas <3 06:52:18 "BGP is a Swiss army knife. Actually, it's all knives." 06:52:35 John Scudder I remember that but not who said it. Was it prz? Stefano? 06:53:11 Jeffrey Haas prz 06:53:18 John Scudder probably more manageable to ask questions one at a time and let the speaker respond one at a time, if you actually want answers 06:54:15 Stefano Previdi @john. My memory archive doesn't go that far...;-) 06:54:57 John Scudder :-) 06:55:03 Robert Raszuk @Stefano ... your memory is just FIFO 06:55:44 Stefano Previdi @Robert: qualify "memory"... 06:56:14 Russ White maybe this should go in rtgwg -- @jeff? 06:56:16 John Scudder no matter what group it's in, jeff will be chairing 06:56:35 Jeff Tantsura @john as ct/car discussion proved - answers don't matter ;-) 06:56:44 John Scudder 😢 06:57:22 Jeffrey Haas Whereas I regularly have conversations with people that want to reduce protocol count in their ecosystems. 07:01:16 Russ White @tli -- I completely agree with this ... more smaller protocols rather than keep stuffing things into the protocols we have 07:01:20 Jeff Tantsura some have deployed kafka connectors... 07:05:16 Aijun Wang @tony. Additional questions that are not answered on the mic are here: 1) The pressure on ABR is not only the sessions number, but the registration prefixes. 2) Only the ABR can act such role. other internal IGP nodes can't accomplish this task 07:06:25 Jeff Tantsura meetecho 07:06:47 SoS 07:06:59 Meetecho What's the issue? 07:07:08 Jeff Tantsura no audio 07:07:13 Zhibo Hu @Russ White Dealing with coupling between multiple protocols can be a disaster. 07:07:28 Jeff Tantsura Jie - we can't hear you 07:07:30 Jeffrey Haas I can hear jie 07:07:30 Jeff Tantsura can't 07:07:35 Meetecho Jie is not audible in the room? 07:07:51 Jeff Tantsura let's wait for meetecho 07:07:52 no 07:07:56 Gunter Van de Velde yes, i can hear you 07:07:59 Louis Chan i can hear 07:08:02 Jeff Tantsura neither chris 07:08:02 Meetecho We can hear on Meetecho 07:08:03 Hao Li can hear 07:08:11 Jeff Tantsura not in the room 07:08:12 Meetecho Checking 07:08:19 Gunter Van de Velde (oh, but i am remote) 07:08:19 Tony Przygienda e'one remote. jeff can go drink a beer and we continue ;-) 07:08:37 John Scudder can ppl in the room join from personal laptops while the room audio is being debugged 07:09:17 Acee Lindem Please join on laptop 07:09:21 John Scudder so that we can continue the meeting pls? 07:09:22 Meetecho Sending someone over 07:09:35 But are all remote participants not audible? 07:09:48 Or ust Jie? 07:09:51 Christian Hopps Everytone remote can hear 07:10:01 Jeff Tantsura all 07:10:02 Christian Hopps it's only the in room 07:10:04 John Scudder all remote ppl can hear one another 07:10:06 Jeff Tantsura I use audio from my laptop into the mike 07:10:15 Meetecho Can remote participants hear audio from the room' 07:10:18 John Scudder thanks jeff 07:10:22 we do not hear audio comign from the room but then again I don't know if anyone is talking 07:10:35 Christian Hopps that'll be fun when it gets fixed :) 07:10:39 Meetecho Ack, found the issue 07:10:41 Fixing it, just a sec 07:10:45 Wim Henderickx we can hear in the meeting 07:10:50 Eduard V It is more reliable to be remote. The world virtualized. 07:10:54 Jeff Tantsura we are back 07:11:03 thanks meetecho! 07:11:09 Aijun Wang broken 07:11:10 Meetecho Should be working now, can you confirm? 07:11:22 Jeff Tantsura yes 07:11:26 confirmed 07:11:35 Tony Li @Aijun: 1) There is only one registration prefix assuming you're willing to put all loopbacks into that prefix. 07:11:41 2) No, it doesn't need to be the ABR. 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. 07:12:48 Aijun Wang how the node in one area finds the proxies in another area? 07:13:46 Tony Li Capability in the L2 LSDB. 07:14:02 Jeff Tantsura @tony: from implementation prospective, would you have RIB registration and invalidation based on the state? 07:14:56 Les Ginsberg @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. 07:14:57 Tony Li Ok, the proxy probably needs to be an L1L2 node. 07:15:00 Jeff Tantsura +1 les 07:15:23 Tony Li @Jeff This has nothing to do with the RIB. It's just data propagation. Do with the data as you will... 07:15:41 Aijun Wang 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 07:16:15 Tony Li You're assuming that the registration database is /32 or /128. It doesn't need to be. 07:16:47 Boris Khasanov @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? Why should we trust registration more, for example? 07:17:42 Tony Li The point is to take the burden off of the IGP. 07:18:05 Aijun Wang the ABR can summary the registration. But for the first ABR, it must register the specific /32 or /128 address 07:18:07 Tony Li The first ABR can see summaries advertised by other ABRs. 07:18:28 Jeff Tantsura tony: of course, not directly, but the end consumer uses this to resolve (or invalidate) routes behind some next-hops 07:18:32 Tony Li It registers with each ABR for the prefix that the ABR advertised. 07:18:42 @Jeff, correct. 07:19:04 Jeff Tantsura @tony - similarly to BFD registrations 07:20:45 Tony Li Except that we don't need to send packets every 10ms 07:21:07 Jeff Tantsura sure, but the end result is exactly the same 07:21:45 Tony Li There are many things that people seem to think are 'equivalent' PUA solutions. 07:22:36 Aijun Wang @tony. The ABR should advertise the register the liveness of another loopback address, not the summary address 07:23:48 Ketan Talaulikar @ 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. 07:24:01 Tony Li @Aijun Not in my proposal. 07:24:15 That approach would scale poorly. 07:24:34 Jie Dong @Ketan, thanks for your suggestion, will clarify the usage 07:25:51 Aijun Wang @tony, then, if only one of node within the prefix failed, but others are alive. how you notify the register via the summary prefix 07:32:10 Tony Li Registrations are prefixes. Notifications are hosts within those prefixes. 07:32:40 Aijun Wang OK, I know. but it sound a little strange. because the prefixes are reachable 07:34:39 Tony Li This has nothing to do with reachability. 07:35:12 Aijun Wang the prefixes are live 07:36:13 Tony Li It's pretty simple. Suppose loopbacks are in 10/8 network wide. 07:36:13 Area 1 has loopbacks in 10.1/16, area 2 has them in 10.2/16, etc. 07:36:29 Now node A registers for 10/8. 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. 07:37:24 Aijun Wang No, I think there are problem on your assumption here. 07:38:14 node A may tunnel with 10.2.1.2 07:38:55 when it receives the summary notification, will it switchover? 07:39:25 Tony Li There are no summary notifications. 07:39:36 It gets a notification for 10.2.1.2/32 07:39:53 Aijun Wang So, registration summary, but notification is specific? 07:40:02 Tony Li Yes! 07:40:09 Jeff Tantsura :) 07:40:16 Louis Chan @Tony, you might consider notifications with all-alive-but, or all-dead-but. 07:40:23 Tony Li Now you're just making things complicated for fun. 😄 07:40:50 Boris Khasanov @Tony, if we want to use other than ABRs routers for the registration, how that role will be assigned? Any thoughts? 07:41:47 Andrew Stone 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...) 07:42:23 by per prefix level, i mean, the filter is applied but end consumer receives notifs per prefix 07:42:59 Tony Li @Boris As noted above, it would need to be an L1L2 router so that it sees both databases. Set the overload bit so that it doesn't carry traffic. 07:43:04 @Andrew There are many ways to do it. 07:43:41 Robert Raszuk @Tony - Does it need to really be a router ? How about just node listening passively to both L1 and L2 areas ? 07:44:48 Tony Li That suffices. 07:45:00 Jeff Tantsura i think we have a presentation on IGP monitor later today? 07:45:22 Boris Khasanov @Tony, I thought about using some centralized way of assignments, via controller for example. 07:45:34 Aijun Wang @boris, yes, this is the normal PUB/SUB procedures 07:46:54 Tony Li @Boris We know that global controllers don't scale and we end up with hierarchical controllers. Which is not very different than this. 07:48:13 I will wait until the end. 07:50:36 Tony Przygienda 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 ;-) 07:52:04 Zhibo Hu Would PUB/SUB be a disaster if all nodes needed to know the reachability of all nodes? 07:53:39 Jeff Tantsura I'd argue that "on change" streaming notification into kafka/similar bus would have rather similar (speed wise) characteristics 07:54:19 Tony Przygienda @Zhibo: chicken and egg. how will a node know how to get to the bus/server if there's no forwarding yet? ;-) 07:54:40 Robert Raszuk @Zhibo - no. Today all nodes in IGP do know how to reach other nodes. Here we are taking about liveness. 07:54:57 Tony Przygienda people always think IGPs are superfluous until they stand there with a packet in their hands and say "eeehe, how do I get there"? 07:55:21 John Scudder 😆 07:56:23 Tony Li @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. 07:56:42 Aijun Wang IGP has the existing mechanism to do the notification, which is no burden to the router(no SPF involved) 07:57:13 Tony Li Except that you're adding arbitrary stuff to the LSDB. 07:58:14 Zhibo Hu If any-to-any PUB/SUB is used, IGP is more efficient. 07:58:22 Tony Li Which is why it's hierarchical. 07:58:50 Jeff Tantsura @zhibo - no 07:59:20 Tony Przygienda @Zhibo: you may be underestimating flooding & 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 ;-) 07:59:33 Jeff Tantsura +1 prz 07:59:51 Zhibo Hu 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. 08:00:05 Tony Przygienda 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 08:00:44 Jeff Tantsura there's a reason we do BMP and streaming telemetry in general 08:00:48 Robert Raszuk 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 ? 08:03:26 Zhibo Hu Node liveness is not a common occurrence. I don't think IGP advertising node liveness will lead to flooding crashes. 08:03:48 Boris Khasanov @Tony P. RFC1925 has also #6 :) 08:04:12 Robert Raszuk @Zhibo - then do not summarize node loopbacks and we are done. 08:04:31 Tony Przygienda @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 08:05:40 Zhibo Hu Summary is mandatory. Summary is used to reduce information about live nodes. Most nodes are in the live state. 08:05:43 Tony Li So then we don't need PUA. 08:06:25 Robert Raszuk stable information (as you claim it is such) do not hurt IGP scaling 08:06:30 Tony Przygienda 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 08:06:47 Boris Khasanov Very good discussion! 08:07:54 Jeff Tantsura along this lines - if your org is ops heavy, out of band solution might be better choice (building scalable and reliable collector infra ta scale is somewhat black magic), otherwise what tony proposed might fit better 08:09:18 Zhibo Hu 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. 08:10:57 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. 08:11:40 Robert Raszuk Nope .. ABRs are local to the area ... no livness is needed to select correct ABR 08:12:35 Jeff Tantsura yep 08:12:42 Christian Hopps @meetecho is there a way to increase the volume on the in-room mic in the remote mix? 08:13:11 John Scudder the gain control in the lower right helps a little 08:13:37 Zhibo Hu Other areas node select appropriate ABRs 08:13:49 Christian Hopps yeah just found that, better, with all volume levels maxd though 08:14:01 Zhibo Hu We will list some other cases in PUA. In fact, BGP does not only benefit from the node liveness status. 08:14:51 Christian Hopps 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 08:14:52 Acee Lindem Pardon my queue squatting... 08:15:20 Tony Przygienda 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 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 ;-) 08:16:13 Robert Raszuk #Tony - I asked that on the list. Les responded that overload or max-age would not be a trigger in any case. 08:17:27 Meetecho 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 08:17:34 Tony Przygienda right, we can make all kind of wonderful assumptions and end up with 1925 #7 08:17:58 Christian Hopps 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 :) 08:18:47 Meetecho You're talking to a metalhead so I can relate :D 08:19:17 We'll try to better balance the levels when we do our sound checks tomorrow morning 08:19:47 Christian Hopps thanks :) 08:20:20 Tony Przygienda 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 ;-) 08:25:00 Wim Henderickx @tony, was just going to ask can we not use bgp-ls, but seems i know your answer :-) 08:25:38 Christian Hopps I like acee's comment about usign the protocol where we can and just add what's missing. 08:25:45 if you trust the monitor node enough to let them onto your network you can trust them not to advertise LSAs too I guess 08:26:11 Tony Przygienda 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 08:26:19 Robert Raszuk @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. 08:26:33 Tony Przygienda the _almost_ at scale in high reliability deployments are what makes me loose sleep at night regularly ... 08:26:46 Jeff Tantsura I don't see realistic alternative to BGP-LS is the next 3 or so years 08:27:26 Boris Khasanov +1 to Jeff. We still need BGP-LS in mid-term perspective (it is supported by the majority of vendors in some level) 08:27:45 Tony Przygienda 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" ... 08:28:20 Aijun Wang BGP-LS has far scope than the IGP based solution 0 Tony Przygienda 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 & timings & reliability asked by very demanding customers which is not reality for vast majority of folks ... 08:29:55 Wim Henderickx 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. 08:30:07 Ketan Talaulikar @Tony +1 - BGP-LS does not provide the real IGP machinery view ... its only a topology view Jeff Tantsura @prz, in general - there's enough data to be actionable (icw with some other things) 08:31:03 Boris Khasanov ccvktdvudlfdigiuknegcjukctteghfbjuitiihn 08:31:15 Tony Przygienda @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 08:31:16 Tony Li BGP-LS could have simply done a bcopy of the LSP/LSA as it was updated. That would have been simpler and more extensible. 08:31:21 Tony Przygienda @Tony: yepp, that's the conduit thing. They were being told that over and over again ... Boris Khasanov Sorry. @Wim - what customers should do while this new protocol is not available at least on 2 major vendors boxes? 08:32:02 Jeff Tantsura they = you ;-) 08:32:03 Ketan Talaulikar but then we would need practically an OSPF or ISIS implementation to parse and also figure out what is "usable" Tony Li Which is now common. Next problem? A passive node on the end of a tunnel is a simple solution to all of it. Tony Przygienda +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 Robert Raszuk 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 11. Meeting Closure Chairs (5 mins)