Hi, Just curious, keeping the 5G use case and applications aside, is it fair to consider the new metric analogous to TE metric for a prefix that CSPF can use? The metric can be split into 'n' parts all internal to the specific application?
Regards, Muthu On Wed, Jan 19, 2022 at 7:36 PM Aijun Wang <[email protected]> wrote: > 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 <jdrake= >> [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 >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
