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. > [WAJ] Hop count have little influence on the application performance. Nearly > every router can forward traffic in line speed as declared by every device > vendor?
Yes, but hop count has a significant impact on the bits * miles/km product that represents ISP cost. >> 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] We prefer to the solution that can get determined results under various > scenarios, not just fit part of them. There are no solutions that fit all scenarios. Otherwise, we would not have traffic engineering and interesting 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. > [WAJ] For example, if we set the metric based on the distance between two > nodes, we can certainly say that the best path will have the shortest E2E > distance; if we set the metric based on the link delay, we can assure the > traffic will be forwarded in least delay path. > But if we set the metric based on the link bandwidth, I think you cannot > assure the E2E traffic will always pass the expected high bandwidth path. Is > it right? Not per the current formulation, but then that’s not what we’re after. >> 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. > > [WAJ] My observation is that the operator will need more judgment works in > their centralized controller to utilize such tools, especially in some > complex topology (because you need even manual intervention in some common > topology scenarios) > I am also prefer to more automatic work been done in distributed manner. But > shouldn’t such work/tools get determined expected results automatically even > in some simple topology? As I alluded to previously, bandwidth based metrics that have some respect for hop count have been found to be automatically helpful in MANY, MANY, MANY networks in previous routing protocols. Perhaps one of my competitors would be willing to say the name that I am unable to mention. Tony
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
