Hi Richard, I think one the key ideas of ALTO is that a PID refers to (potential) locations of application instances, i.e., endpoints. ALTO is a solution to provide topology guidance between endpoints.
With path vector encoding, we have additional entities for “something” that is in the middle between endpoints, e.g., a shared bottleneck of two path vectors. Conceptually, this entity representing a shared bottleneck is quite different to an endpoint: First, in many cases we won’t expect that an application runs instances at such a bottleneck. And second, these entities may use other identifiers. For instance, a switch or a router may not have any globally unique IP address, or even if it has one (e.g., router system address), the network operator may not necessarily be interested in exposing this in an ALTO server, e.g., to P2P applications. To me, the question of whether to use unified PID comes down to: 1) Distinguish different types of PIDs, i.e., add some form of “type field” for PIDs. I think we had a related discussion some time ago regarding “Transactional PIDs”. 2) Add a new entity in addition to PIDs that is used e.g. in the path-vector format, i.e., separation design. I think both approaches can work. IMHO, one of the constraints for picking a solution would be “legacy” ALTO clients. For instances, let’s assume that an ALTO server offers path-vector style ALTO maps, but not all ALTO clients support it. For instance, a P2P application may only understand “traditional” network and cost maps. In this case, it probably makes sense not to expose in network maps those PIDs a “legacy” application would not care about. This means that path-vector guidance would probably be exposed in a new network map (e.g., different MIME type). Furthermore, I’d argue that in this scenario it could make sense to allow an ALTO server operator to use the same PID names both in the network maps for “legacy” and “path-vector” users, in order to simplify management. In general, I believe that separation is a slightly more natural design choice under these constraints. Thoughts? Michael From: alto [mailto:[email protected]] On Behalf Of Y. Richard Yang Sent: Tuesday, February 24, 2015 11:40 PM To: IETF ALTO Subject: [alto] ALTO topology design: separation design Dear all, The authors of the ALTO topology draft are working to make progress on key design issues, in particular, the issues left open at IETF 91: http://www.ietf.org/proceedings/91/slides/slides-91-alto-4.pdf One key design choice is using unified PID/Network (Device) node or not; see slides 17-18 of the proceeding slides for discussions. At IETF 91, the favor was a separation design (slide 19), but no decision was made. After much thinking, and evaluation of related work, we propose to proceed with the separation design. This is similar to emerging general node-graph design such as that of ONOS, which uses Nodes, Link, Host, EdgeLink, Path. If you have any objection, please feel free to raise the issues soon. Thanks. Richard
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
