Hi Robert, > If architecture enforces you to flood metric to topology mappings then you > don't have the issue of disconnect of control and mgmt plane.
Sorry, that’s a bill of goods. Let’s look at the reality, with ASLA. Here’s the example that Les proposed: > [LES:] Node R1 uses metric-type A for Application X and metric type B for > Application Y. > Node R2 uses metric-type B for Application X and metric type A for > Application Y. > Both nodes are advertising both metric-types. Even with ASLA you have a problem: R1’s application X sees it’s metric type A that it advetises. Then it sees R2 advertising metric-type B. It ignores it, no question about it. Application Y sees its own metric type B and it ignore’s R2’s metric type A. Similarly, R2 is going to ignore R1. Is there some SNMP trap for BOZOTCONFIG going off? No. The control plane has no idea what the configuration is supposed to be. It cannot be a sanity check for the management plane because it doesn’t have the correct information. The only place that has that information is the management plane itself. ASLA didn’t magically fix things for you. > I am a bit surprised we are ready to relax this and lower the bar here to > permit such mapping to be mgmt config driven. Everything is management plane driven. > Maybe definition of FAD should be revisited and defined in one place and > flooded ? ? The definition of a FAD is flooded. There at least we have an election mechanism across the area to pick something. It may still not be the right one, it may not be sane definition, but we should at least agree with what it is. If the implementations aren’t buggy. ;-) If you want, you can advertise the definition from only one place. But then you have a single point of failure. Want to avoid that? Well the smart money advertises the FAD from multiple points. And it’s the exact same FAD. Now, if you have a decent management plane, what’s the difference between replicating the defintion three places or forty? None. You could replicate it everywhere in the area. And you could avoid flooding. Tony _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
