Hi, Given that the flood reflector authors have asked the chairs to do a call for adoption, might someone from that group be able to talk to a couple of the points/questions from my mail? I think it would help me (and maybe others) in making informed responses to any adoption call.
- Is this proposing to add "virtual links" to IS-IS (in addition to the flood reflector part)? - Is there a general-purpose non-complex non-tunneling solution possible? Thanks, Chris. [as WG member] > On Jun 6, 2020, at 7:18 AM, Christian Hopps <[email protected]> wrote: > > [ all the following is as a WG member ] > > I've been thinking a lot about the proposed flooding reduction drafts > currently vying for adoption by the WG. I've been doing this thinking in the > context of wearing an operator hat (i.e., trying to leverage my prior > experience working for DT on Terastream). In the abstract the Terastream > architecture presented a good way to visualize and compare the benefits of > using one of these solutions w/o getting too complex. A simplified model of > this design can be seen as a horseshoe of horseshoes. the Major horseshoe is > L2 and the minor horseshoes are L1. Each L1 area has 2 L2 routers for > redundancy (I'll consider more though), and all L2 routers are full-mesh > connected to support that redundancy. > > Telco > > <PastedGraphic-4.png> > > But let's map this to a more DC centric view (I guess?) where each L1 area > now has 10 L2 routers instead of 2 (i.e., 10%, but that could be change that > later if need be). > > Natural Design > > > <PastedGraphic-5.png> > > Now for whatever reason some operators do not want to provision > high-bandwidth transit links between their L2 routers in their L1 areas. This > is critically important b/c otherwise you would simply use the above Natural > Design. I'd like to better understand why that isn't just the answer here. > > Anyway, forging ahead, here's what we get with unchanged IS-IS to support > "use everything for transit" > > All In > > <PastedGraphic-6.png> > > So the 800 L2 LSPs, and the impact on flooding dynamics, are what these > drafts are trying to reduce or avoid. > > Area Proxy > > First I'll look at area proxy. This seems a fairly simple idea, basically > it's taking the now L1L2 areas and advertising them externally as a single > LSP so the impact is very similar to if they were L1 only. This maps fairly > closely to the Telco and Natural Design from above. Each L1 router in the > Telco design would have 100 LSPs The L12 routers would have 100 L1 + 16 L2 > LSP. In the Natural Design each L1 router has 100 L1 and each L12 router > would have 100 L1 and 80 L2. With Area Proxy each router has 100 L1 and 100 > "Inner L2 LSPs" and 80 "Outer LSPs" + 8 "Outer L2 LSPs" > > The key thing to note here is that if you double the number of areas you only > add to the Outside LSP and Proxy count just as it would scale in the Natural > Design, so going from 8 to 16 areas here adds 80 more "Outside LSPs" and 8 > more L2 Proxy LSPs for a total of 276 L2 LSPs even though you've added 800 > more routers to your network. > > > <PastedGraphic-10.png> > > Flood Reflectors > > I'm less sure I understand this draft so please forgive me if I get this > wrong. After reading this draft a few times I believe it is basically > providing "L2 virtual links" over an L1 area between the area's L2 edge > routers and then using a "flood reflector" to reduce the number of required > "virtual links" by creating a hub-and-spoke topology of them. > > The draft does a bit of hand-waving at "judicious scoping of reachability" > being used in place of tunneling. I could guess at what this might mean, but > I shouldn't have to; the draft should spell it out so it can be judged as a > viable option or not. So, the only choice I see presented is to use a > full-mesh of L1 tunnels between the L12 edge routers. > > Anyway, here's a picture > > <PastedGraphic-9.png> > > If, in fact, the draft is talking about adding virtual links to IS-IS I think > it should say that. There's a lot of experience in OSPF with virtual links > and some of the trouble they have caused. There's also important details in > making them work right in OSPF that doesn't seem to be in the current draft, > so it's not clear what actual level of complexity is going to be required to > make this all work, and importantly, if that would then be palatable. > > I also do not like the idea of all of these automatic "fowarding-tunnels". > They would be disjoint from the advertised "flood reflector" tunnel topology > (right?) -- it seems like a management/debugability nightmare to me, and I'm > curious which operators are keen to have a bunch of unadvertised tunnels > added to their IGP network. :) If the draft really can work in general w/o > the tunnels I would appreciate seeing those mechanics described rather than > just hinted at. > > The ideas are interesting for sure, but the draft doesn't seem fully fleshed > out, and I'm worried it'll be overly complex when it is. > > Thanks, > Chris. > [as WG member] > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
