The data kindof exists. Servers have Physlocations which have addresses of some kind. Their purpose is presently ambiguous as to if that should be used for physical address or mailing address. Clearing that ambiguity and adding lat/long are nice to haves, but that’s really a TO enhancement rather than a TP one. Additionally those physlocation lat/longs wouldn’t presently used in a meaningful way since all routing decisions are based on the cachegroup. There are reasons that a cachegroup location might be skewed away from the physlocation or serve as an area aggregate. Today you can suboptimally equate physlocation and cachegroup for routing/capacity purposes if desired, but that gets pretty far into micromanagement and capacity issues. Analytics I’ve done in the past that were useful were to create convex hull polygons of the physlocations associated to a cachegroup and check that the areas were reasonable for the tiers as well as to ensure the cachegroup lat/long was contained within it or nearby to where it made sense. That’s shown in the past where we’ve had physlocations set wrong on hosts due to ambiguous physlocation names. Although that didn’t affect routing just RMA work.
Better visualization around parentage in general would be a definite win. Given how we’ve gone from a 1 or 2 tier CDN model with secondary parents and MSO to an N-tier model with additional dimensions of permutations around topologies as well as capabilities/requirements, as an SRE it’s much more difficult to know how traffic ideally should be flowing for diagnostic purposes. That view doesn’t have to be geographic in nature though. A graph/tree would suffice. From a perspective of self-service though, all the topic around parentage is generally too complex for a non-ATC engineer and too powerful. Better visualization around parentage I think benefits both user groups. Jonathan G From: Dave Neuman <neu...@apache.org> Date: Tuesday, June 7, 2022 at 9:30 AM To: dev@trafficcontrol.apache.org <dev@trafficcontrol.apache.org> Subject: [EXTERNAL] Re: 2022-06-07 TC Working Group Agenda and Meeting Notes >> - Zach proposes/iss working on a geographic Topology builder using Cache Group latitude/longitude to map them out I would suggest incorporating the physical locations of the hosts as well. Maybe as a drill down? Cache groups can be as big as a whole country, having the actual locations of the caches could be much more helpful. Just my $.02 --Dave On Tue, Jun 7, 2022 at 9:27 AM ocket 8888 <ocket8...@gmail.com> wrote: > 1. Attendance > - Amy Wilson > - Zach Hoffman > - Stephen Hamrick > - Eric Holguin > - Srijeet Chatterjee > 2. ML: Call for Traffic Portal Enhancements / New Features > - Zach proposes/iss working on a geographic Topology builder - > using Cache Group latitude/longitude to map them out > > On Tue, Jun 7, 2022 at 9:20 AM Zach Hoffman <zrhoff...@apache.org> wrote: > > > > Active mailing list threads: > > • Call for Traffic Portal Enhancements / New Features < > > https://urldefense.com/v3/__https://lists.apache.org/thread/82g2cstsn0p5gf8b6b56og17owq1837j__;!!CQl3mcHX2A!Bv6UqJctTu9oeZnjv-kUj-ZSFJgmN5_124arZmYjlcWFNNbKo9qjPArplelcEUXtPcErLkLAQWcazGhFGJmD$<https://urldefense.com/v3/__https:/lists.apache.org/thread/82g2cstsn0p5gf8b6b56og17owq1837j__;!!CQl3mcHX2A!Bv6UqJctTu9oeZnjv-kUj-ZSFJgmN5_124arZmYjlcWFNNbKo9qjPArplelcEUXtPcErLkLAQWcazGhFGJmD$> > > > >
