On Tue, Apr 2, 2019 at 4:41 PM <tony...@tony.li> wrote: > > Hi Tony, > > > > Read it through (fairly slowly even ;-) and seems Les is for simply > always including LAN in the flood reduction topology. I would concur with > that. > > > Ok, I didn’t read that into it and I disagree. There are many topologies > where that approach is decidedly suboptimal. > > Suppose you have a leaf-spine topology, except that the spines are layer 2 > only. You now have N leaves, with M LANs interconnecting them. Do you > flood in parallel on M LANs? Wouldn’t it be more prudent just to flood on > 2? > > > > figuring whether a LAN is transit is basically calculation whether it's > a minimal cut. solving that is polynomial of course. When we have multiple > LANs to decide what is the maximum subset of LANs that can be cut without > paritioning the graph (i.e. how many LANs can we omit while still having > the graph connected) smells to me NP complet'ish but I don't think I ever > dealt with the problem. At worst it's combination of LANs * polynomial > computaton so about sum_1_k (n over k) * polynomial which looks tad chewy > to me ... then, LAN floods efficiently in terms of fanout compared to p2p > replication in IGPs so there's this unknown optimization constant that > affects overall solution ... > > > It’s pretty clear to me that the optimal selection of the FT is ‘chewy’ if > not NP-hard. However, the very good news is that we don’t need optimal. > Only effective and reasonably efficient. > > Dave Allan's proposal is a clear existence proof of a far less ‘chewy’ > algorithm, albeit for a restricted set of topologies. Other algorithms are > likely to be not very ‘chewy’ on those topologies either, and only become > ‘chewy’ as the topologies get more complex. This seems entirely reasonable > and appropriate. > > > > Obvioulsy, someone could implement a very clever algorithm how to avoid > LANs or account for their efficiency and so on so IMO the draft doesn't > even need to say anything normative if no algorithm is given as intended > AFAIR > > > This is exactly correct. Since we are partitioning the algorithm > development from signaling, we can set aside the question of how to > optimally use LANs and focus on the question on the table: do we add enough > signaling to specify LANs. > > ok, agreed. maybe something to this effect could make it into the draft as in "it's not simple to avoid LANs but nothing prevents you to do that" ...
I admit I may have over-interpreted Les's write-down which as far (meaningfull) verbiage goes rivals some of the stuff I tend to produce ;-) As to signalling, I think we have not much choice and need to signal the PNODE as either being in or out topology which implies LAN is in or out it .... I would also consider optimizations to "sub-flood" the LAN (i.e. disaggregate it to p2p floodings or nodes dropping received LSPs) as jumping the shark due to complexity but that's just my small change ... --- tony
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
