IETF-71 isis-wg Minutes. *** Corrections from speaker marked with [corr] Scribe: DWard Trill-ISIS doc to ISIS WG P2P over LAN needs to move forward Les - Gen App - see slides Kireeti: What is routing vs non routing info? Let's call it routing if it carries topology or how to route. GMPLS, mesh group affect topology Dave: What we are trying to do is take the new stuff that is coming at ISIS that isn't routing and move it to a location that won't affect convergence or scaling of ISIS for routing. Folks are trying to cram 10 lbs of poo in a 5 lb protocol. We gave them a 10lb protocol with their own instance. Don Eastlake: Can the WG be the authority? It has a finite lifetime All: So do humans. Will Ross Callon outlive the ISIS WG? Ross: I'll figure out how to have an authority on determining what goes into the routing instance vs poo instance. Should be the WG. Matthew Thomas: Why are those examples on the slide? Les: They are merely things I thought might be even able to be talked about. Kireeti: But some are routing Les: I made a mistake, thanks Matthew: But some are topo Les: Yes, they are just examples. Thanks WG chairs: Next presenter please ------ Les - ISIS/BFD see slides No questions. Found nits already ... new draft in a couple days ------ Stefano - MI-ISIS see slides No questions. DWard: Check w/ TRILL folks as they rely heavily on MI ISIS ------ George Swallow - Summary Route w/ Detailed Reachability - see slides [corr] Yakov: there are a whole bunch of issues raised in the draft, and [corr] there may be existing solutions to some of them. There is an issue [corr] of how long it takes to update FIB, and its impact on connectivity [corr] restoration. Summarizing routes in the FIB certainly improves [corr] connectivity restoration. The draft seems to assume that in order [corr] to summarize routes in the FIB one has to summarize routes in the [corr] RIB. However, this is an incorrect assumption, as one could [corr] summarize routes in the FIB without summarizing routes in teh [corr] RIB. Which means that in order to summarize routes in the FIB [corr] one can use the existing ISIS mechanisms "as is", w/o introducing [corr] any new mechanisms. [corr] In fact, one should ask what are the essential differences [corr] between George's proposal and the exising ISIS with /32 [corr] advertisements, where advertisements of individual /32s [corr] are compressed. TLi: No interoperability because you can't insure. You are sending a /32 from one area into other areas [corr] Yakov: To avoid installing /32 routes into FIB one could mark [corr] them with admin tags. TLi: have doc that shows admin tag for no install [corr] Yakov: All you need is a document that defines an admin tag [corr] for no install. Nothing else. In contrast to George's proposal, [corr] no new ISIS mechanisms are needed. [corr] The draft makes several incorrect statements. E.g., "Currently [corr] if next hop tracking is to be performed, host routes can not [corr] be summarized". This is false. What is true is that if one uses [corr] IGP to perform BGP next hop tracking, then host routes can not [corr] be summarized. However, using IGP for BGP next hop tracking is [corr] one possible way of doing this, but is not the only one possible. [corr] One can use BGP itself to perform BGP next hop tracking, and [corr] this way of BGP next hop tracking does allow to summarize host [corr] routes in IGP. GS: Now depends on BGP withdraw Yakov: That is correct. However, BGP Next Hop tracking depends on the withdraw of just one route - route to the Next Hop. [corr] Yakov: Moreover, with George's proposal to use IGP for BGP Next [corr] Hop tracking, in order for a particular ingress router to receive [corr] the information about a failed Next Hop, the withdraw of that [corr] Next Hop has to be processed/propagated by the control plane of [corr] every router on the path from the failed Next Hop to that ingress [corr] router. In contrast when BGP is used for BGP Next Hop tracking, [corr] this information has to be processed/propagated by only the control [corr] lane of the Route Reflector that has the Next Hop as its client [corr] and the Route Reflector that has the ingress router as its client. [corr] In other words, using BGP for Next Hop tracking may result in [corr] fewer control plane hops than using IGP for Next Hop tracking. Previdi: Comparing flooding scheme of BGP to ISIS isn't worthy to compare because of performance. There can be extensions to existing solutions. Yakov: Can use BGP NH Tracking for your own ASBR and neighbors ASBR. This scheme in ISIS just work for the latter case. GS: Agreed it doesn't work in that situation. Yakov: Only new thing in this proposal is to preserve control plan memory and nothing else. Acee: Not a bad idea but, your LC api and it appears you are exposing it in your TLVs. The precedence you are setting in sending /22s ... is this the way you want to advert information in the IETF. --------- Matthew Thomas - removing pseudonodes from ISIS - see slides Acee;Given we have p2p over LAN why take on the pain? MT: There is a cost to take them out but, it is born by the coding. Depends on what is coming next. Acee: What about bw compat. Requires complete rollout per enet segment MT: Segment by segment ... so, whereever you do this you get network wide benefit Stefano: neither in draft or mailing list was there a demonstration of a problem to be solved. Or a demonstration that the solution is that there is an improvement. "Fix the problem that is there in 20 years" is too far out. Nice algorithmic exercise now we just need a problem to solve. MT: you are looking at a pure guess of how many routing nodes are on a segment. SP: Do you have an idea of the CPU cost you are going to save. What is the # of ms I am going to save. MT: Half the heap. Do the math. Somewhere between 6.5 -9. Mike says 4 TLi: Not just half the heap must have 1 router per LAN. SPF costs are not the dominating cost in our computation. We are saving things we don't care about. MT: No, we have a feature to save large N. Our current protocols, etc why can't we scale it into some significant sized clouds (e.g. wide area bridging) GS: My draft is about scaling FIB update time. If you have a shared media and have two routers on it and there is no pseudonode, if a 3rd comes along what happens? Seems like there could be race conditions and you fail to find a path, etc. MT: When a node arrives you can see in the hellos that it is incompatible. Padma: I share POV that I don't see a problem. On the other hand on the slides there is a lot of benefit on bandwidth. But, with flooding reduction you'll save more w/ LSA flooding reduction. MT: Agreed shouldn't be written there. Padma: two routers in a bcast media. When you do that the media that others will join... there will be IP addresses ... there are other drafts where we can minimize the flooding, etc. The configuration for p2p on lan and other mechanisms possible to help. Acee: I am not familiar w/ TRILL but, when you do the math you can't help the two node case only the 3 node case. p2p on LAN on both IGPs is done. MT: If you fast forward you will see all sorts of LSA2 Acee/Padma: configure it all p2p and you are done. Les: Two things that need to happen to make this draft justifiable: 0) what is the problem and 1) the people that have given you feedback have done the math and the memory and CPU savings are not what you are claiming. If you think the numbers are incorrect please refute the calculations that have been given to you. Don Eastlake: The spec seems more robust as there is no config. DWard; If that is the point, please add it to the draft MT: That's not the point DWard: Please put whatever the problem is that you are solving into the draft