Tony - I think Robert has it correct here. This isn't a "plane violation" issue.
The requirements are that each node advertise link attributes and indicate with which application(s) a given attribute is associated. Only the sending node knows that - but the receivers need this information in order for the application to operate correctly. So it is necessary for the originators to include an indication of the associated application(s) in the advertisement. It is still possible, of course, for this to be misconfigured. No one is asking for the control plane to try to detect this. But if the architecture does not provide a way for necessary information to be advertised then it is the architecture which needs to be fixed. Would you expect the protocol to correctly perform topology specific calculations if the advertisements from each node did not include a topology ID? Les > -----Original Message----- > From: Tony Li <[email protected]> On Behalf Of Tony Li > Sent: Friday, July 30, 2021 11:00 PM > To: Robert Raszuk <[email protected]> > Cc: Les Ginsberg (ginsberg) <[email protected]>; Peter Psenak (ppsenak) > <[email protected]>; Shraddha Hegde <[email protected]>; Van De > Velde, Gunter (Nokia - BE/Antwerp) <[email protected]>; > [email protected] > Subject: Re: [Lsr] Generic metric: application-specific vs application- > independent > > > 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
