Hi Aijun,
>> My suggestion is still not introduce such non-cumulative metric to >> cumulative based SPF calculation process. > > Again, what we’re proposing is cumulative. > > [WAJ] My arguments is that your cumulative proposal (section 4.1.1.1 or > 4.1.1.2) can get unexpected result, that is, if there is no manual > intervention, the E2E sub-optimal path will be selected. You have also > confirmed this in > https://mailarchive.ietf.org/arch/msg/lsr/wWoGgwf-Nch0_VxjczZBpLFXyos/ > <https://mailarchive.ietf.org/arch/msg/lsr/wWoGgwf-Nch0_VxjczZBpLFXyos/>, > said as below: > > “Override the metric on B-E-D to be even higher. > > 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. Hops are still > relevant. An operator can adjust the reference bandwidth and add manual > metrics to achieve different effects, depending on their precise needs.” > > The operator must investigate their topology carefully to add necessary > manual metric to avoid the unexpected sub-optimal path. Is it nightmare? > I’m sorry, but I seem to be unable to help you reset your expectations. The bandwidth metric is NOT intended to find the absolute highest bandwidth path to the destination regardless of all other considerations. It is simply using link metrics based on bandwidth as a means of skewing paths towards higher bandwidths, but it is still cumulative so that a significantly longer path may still drive traffic away from a higher bandwidth. If it is any consideration, you should be aware that most implementations already set their default link metrics based on interface bandwidth. This results in EXACTLY this same behavior, with administrators making manual adjustments if necessary. Regards, Tony
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
