Hi, Robert: As described in the draft, “all those locations can be close in proximity. There might be a tiny difference in the routing distance to reach an application instance attached to a different edge router” So, the “aggregated cost” or other factors that associated with the stub link may be more important for selecting the right server. I think it is not important for P router responses or Ingress router responses first. In Figure 10, you will notice the client’s traffic is first distributed via the DNS to different “ANYCAST” address. Then for the same “ANYCAST” address, the client will prefer one of the three server, if these server has different “aggregated cost” We can now adjust the “aggregated cost” to influence the traffic distribution among these three servers for the same “ANYCAST” address. For example, if we set all the”aggregated cost” same for one “ANYCAST” address(for example, aa08:4450), then the traffic to this address will be distributed equally among the three locations. No traffic oscillation will occur.
The key point here is that the attributes associated with these stub links/prefixes should be considered or emphasized. Aijun Wang China Telecom > On Jan 19, 2022, at 18:19, Robert Raszuk <[email protected]> wrote: > > > Hi Linda, > > The aggregated site cost change rate is comparable with the rate of adding or > removing application instances at locations to adapt to the workload > distribution changes. > > [RR] What Les and myself have been trying to highlight here is that the above > model does not effectively work well in the underlay layer. > > The moment you adjust such cost will not really spread workload distribution, > but shift it between servers - members of given anycast address. The > forwarding decision will happen at the first common P core underlay node from > the server side and not the ingress to the network - where is what you would > really want. > > Only in very specific topologies you may see some more control, but I would > say that this is rather an exception then a rule. > > Thx, > R. > > > >> On Wed, Jan 19, 2022 at 4:52 AM Linda Dunbar <[email protected]> >> wrote: >> Robert, >> >> >> >> In the new version of the draft, we have: >> >> “The aggregated site cost associated with a prefix (i.e., ANYCAST prefix) >> can be a value configured on the router to which the prefix is attached. The >> aggregated site cost can be computed based on an algorithm configured on >> router for specific prefixes. The detailed algorithm of computing the >> aggregated site cost is out of the scope of document. >> >> As the cost change can impact the path computation, there is a Minimum >> Interval for Metrics Change Advertisement which is configured on the routers >> to avoid route oscillations. Default is 30s. >> >> The aggregated site cost change rate is comparable with the rate of adding >> or removing application instances at locations to adapt to the workload >> distribution changes. The rate of change could be in weeks or days. On rare >> occasions, there might need rate changes in hours..” >> >> >> >> Your comments and suggestions are greatly appreciated. >> >> >> >> Linda >> >> >> >> From: Robert Raszuk <[email protected]> >> Sent: Monday, January 17, 2022 5:29 AM >> To: Aijun Wang <[email protected]> >> Cc: Acee Lindem (acee) <[email protected]>; Linda Dunbar >> <[email protected]>; John E Drake >> <[email protected]>; Les Ginsberg (ginsberg) >> <[email protected]>; Gyan Mishra <[email protected]>; lsr <[email protected]> >> Subject: Re: [Lsr] Seeking feedback to the revised >> draft-dunbar-lsr-5g-edge-compute >> >> >> >> Aijun, >> >> >> >> Such metric will be same(because of the ANYCAST address be advertised >> simultaneously via R1/R2/R3 at the same time for one application server, for >> example, S1/aa08::4450). >> >> >> >> That is not really correct. >> >> >> >> On each router R1 or R2 or R3 when you for example redistribute or originate >> in any other way host route for example S1/aa08::4450 you can apply a >> different metric to it. >> >> >> >> That is why I keep asking what is the mechanism in which routers will be >> informed what host routes to advertise and what metric to use for each IP >> address of the server or application on the server. The most precise answer >> received so far was "it is out of scope". And that is important irrespective >> if we are talking about using passive interfaces, stub interfaces or simply >> static routes. >> >> >> >> Thx, >> >> R. >> > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
