Hi Aijun, > [WAJ] The operator must plan carefully for the metric assignment accordingly > to their specific topology to let the traffic pass the necessary high > bandwidth path as done in the following example.
That’s only if they have no concerns about the hop count. Previous experience with other routing protocols that have a bandwidth based metric and do compute a cumulative metric does show that it is indeed possible to run many large networks this way and get acceptable results. > [WAJ] If such work must be done manually, it certainly weaken the necessary > of the automatic metric calculations based on link bandwidth, also the > introduction of bandwidth metric. In many cases, that’s probably not necessary. >> The point of the bandwidth metric (at least in this incarnation) is not to >> make hop count irrelevant. It is to set the metrics relative to the >> bandwidth so that traffic skews towards higher bandwidths. > > [WAJ] This can be done via the “bandwidth constraints sub TLV” that is > introduced in this document. No, that alone would exclude the hop count, resulting in a different path computation. >> Hops are still relevant. An operator can adjust the reference bandwidth and >> add manual metrics to achieve different effects, depending on their precise >> needs. > [WAJ] Is it more simple and easy to get determined results via setting the > link metric based on the additive information? I don’t understand what you’re asking. Please remember that we are not trying to solve all problems for all people. We are trying to provide tools so that operators can drive traffic automatically in the way that they want. We’re trying to provide a variety of tools, with appropriate nerd knobs so that we can do useful traffic engineering without resorting to the very big hammer of having a centralized controller compute everything and program the entire network. Tonny _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
