Tony - > -----Original Message----- > From: Tony Li <[email protected]> On Behalf Of Tony Li > Sent: Friday, July 30, 2021 1:37 PM > To: Les Ginsberg (ginsberg) <[email protected]> > Cc: Peter Psenak (ppsenak) <[email protected]>; Shraddha Hegde > <[email protected]>; Robert Raszuk <[email protected]>; Van De > Velde, Gunter (Nokia - BE/Antwerp) <[email protected]>; > [email protected] > Subject: Re: [Lsr] Generic metric: application-specific vs application- > independent > > > Les, > > > " That does not need to be signaled. Configuration information SHOULD > NOT be signaled." > > > > Where "that" refers to the mapping of link attributes to an application. > > > > I am saying not advertising this association is an interoperability disaster > and has been proven to be so - and I pointed to the summary of cross- > vendor RSVP-TE behavior as a definitive example of one such disaster. > > > > If we disagree on that - so be it - but it is important to understand on > > what > we disagree - otherwise the arguments we make on the consequences of > that choice make no sense to each other. > > > The past issue arose because implementations made an implied association > between the presence of a TLV and enabling an application on a link. > > The generic metric TLV does not do that and cannot do so because it is > intrinsically not tied to any application. > [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. But neither node is aware of the inconsistency because nothing in the metric advertisement indicates how to make the metric-type/app association.
Clearly this is a problem. Are you arguing that it is up to the operator to make sure that they associate the same Metric-type with the same application by making sure node configurations are consistent? Les > Thus, this is not recreating the same disaster. > > Tony _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
