Hi, Tony: Aijun Wang China Telecom
> On May 22, 2021, at 06:40, Tony Li <tony...@tony.li> wrote: > > > > Hi Aijun, > >>>> With the introduce of additional constraint information, the problem >>>> described in “Introduction” part(Section 1) can be solved. >>> >>> >>> Please say more. Claims without rationale are not reasoning. >> [WAJ] The introduction part talks mainly how to divert the elephant traffic >> away from the low bandwidth link. This can be achieved via the introduction >> of additional constraints information for Flex-ALGO > > > Which is exactly what we’ve done: added bandwidth constraints. [WAJ] Yes, I agree with this. > > >>>> The usage of bandwidth metric in large network is not feasible. >>> >> [WAJ] The main reason is that bandwidth metric is not cumulative. > > > ??? What are you seeing that implies that? That is not my understanding at > all. [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. > > >>>> And, would you like to explain more for the following statements(in >>>> Section 4.1.1.2) >>>> “In the interface group mode, every node MUST identify the set of >>>> parallel links between a pair of nodes based on IGP link >>>> advertisements and MUST consider cumulative bandwidth of the parallel >>>> links while arriving at the metric of each link.” >>>> based on example described in Figure 7? >>> >>> >>> The paragraph immediately above explains exactly that. B->C has two >>> parallel 10Gbps links, so it should be considered to be 20Gbps. >>> >>> >>>> How the cumulative bandwidth will be used to achieve the result that >>>> traffic from B to D will prefer B-C-F-D, not B-E-D? >>> >>> >>> B-C-F-D is 20Gbps. B-E-D is 10Gbps. >> >> [WAJ] OK, let’s add two nodes between node B and C, say they are node M and >> N. They have also two parallel links to B and C respectively. The two >> possible path from B to D will be: >> Path 1: B-M-N-C-F-D >> Path 2: B-E-D >> If the “reference bandwidth” is 100G, then metric for each link in >> B-M-N-C-F-D will be 5, the cumulative metric from B-D for Path 1 “B—N-C-F-D” >> will be 25, right? >> The metric for each link in B-E-D will be 10, the cumulative metric from B-D >> for Path 2 will be 20, right? >> How can you prefer to the high bandwidth path? > > > Override the metric on B-E-D to be even higher. [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. > > 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. > 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? > > Tony > > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
