On 11/09/2013 10:17 PM, David Lamparter wrote: > On Sat, Nov 09, 2013 at 08:36:09PM +0000, Acee Lindem wrote: >> On 11/7/13 2:49 PM, "David Lamparter" <[email protected]> wrote: >>> The downside is that mixing LSA types opens really nice ways of messing >>> it all up with mismatching E-LSAs/LSAs, either by bugs or maliciously. >>> Also, race conditions may start popping up if LSAs arrive from flooding >>> before E-LSAs. Either way, if a router is identified as E-LSA capable, >>> LSAs originated by it should never be used by mode-1 routers. >> I'm not so worried about bugs as I am about carrying the complexity of >> mixed-mode LSA complexity forever. If you need to use both LSA types in >> the SPF computation, you will have more overhead. I'm inclined to always >> use the OLD, aka, LSAs for the SPF computation if any backward >> compatibility mode is configured. >
zipped through the draft-ietf-ospf-ospfv3-lsa-extend-00.txt draft & it's surely all an interesting new rathole ;-) Approach is intriguing and commendable per se but as the 'mixed' stuff goes I second Acee that this kind of 'mixed-modes' _never_ go away and people drag on huge amounts of complex code long after the original stuff is obsolete. Though, yes, a mixed mode is normally necessary for a while since 'flag' days don't exist anymore for stuff like IGP and IGPs aren't Apps (yet ;-) ?) that are updated over-nite for better or for worse. But back to this draft. So, as first, I think 12.1 section is overly complicated and will lead to many interesting disasters with all those 'mixed' and 'degraded' modes especially if SPF starts to be mucked with. But as second and worse, 12.1 is crippling the E-LSA proposal big time since if you have semantically completely new things in the new E-LSA TLVs (which after all is THE purpose of doing it), they may not encode into old style TLVs and so you can't issue them or otherwise you 'lie' and may create routing loops in a 'mixed' mode since you cannot decide when forwarding a packet whether it came from an 'old' router or a 'new' router. The 'new' router may understand it would create a loop based on E-TLV information only but the old router won't have it and throw the packet at you. You would forward using the 'new' info. If that is not intuitively clear, I can bring some sketches. The crux of all this has been actually the reason for multi-topology. After we looked into the math we realized you 'cannot' simply mix some new format with new info into a domain and expect loop-free-hop-by-hop. So, you can solve this only by running a multi-topology approach then (i.e. running SPF per E-TLV and TLV topology in your TDB). Or otherwise the new format is just lip-stick, it will semantcially never leave the restrictions of the old fixed format since it cannot add information. In summary, unless you want to take a 'multi-toopology' approach (which has been solved and it would mean E-LSAs are basically a new format in a new topology or you may choose to think about it as a completely new protocol engulfing the old one) I think you will have to abandon all those 'degrade/mixed/unmixed' stuff and simply fall back to old format each time you see a router with EL bit cleared, i.e. you have to migrate whole area until E-TLVs kick in. This will allow for E-TLVs to be the real flexible TLV new format with possibly new information influencing SPF you're seeking. --- tony
<<attachment: prz.vcf>>
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
