Michael, Thanks for the feedback. Please see below.
On Wed, Feb 25, 2015 at 10:29 AM, Scharf, Michael (Michael) < [email protected]> wrote: > 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”. > I tend to have a mixed feeling on adding a type field to mingle different types of objects into a single class. This is a foundation of the property graph abstraction and hence has its value. But they appear to be less natural. > 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. > > > Agreed. Considering legacy is an excellent point. Richard > 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 > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_proceedings_91_slides_slides-2D91-2Dalto-2D4.pdf&d=AwMGaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=XLUiSiiG1puqdedQurbPGwgATXWZip5Am1lcg3DwNgM&s=jwcigZ1MgWFL72LB91wmwPVoe75NQbZSkJdj2HcTO8k&e=> > > > > 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
