Regarding terminology: I like the idea of introducing an Abstract Network Elements (ANE). Maybe we could also use a term like Abstract Element/Entity (AE).
We should probably avoid the acronym NE, since this is used by the network management community, but in a different context (typically implying a device). Michael -----Ursprüngliche Nachricht----- Von: alto [mailto:[email protected]] Im Auftrag von Wendy Roome Gesendet: Mittwoch, 25. Februar 2015 21:51 An: [email protected] Betreff: Re: [alto] ALTO topology design: separation design I also prefer the separation strategy. I don't think we have enough legacy clients to worry about (*sigh*), but a PID as a collection of endpoints defined by a set of CIDRs is a simple, easy-to-understand concept. Most ALTO clients will not care about topology. So why complicate life for them? To summarize my idea of the separation approach: * We define a new entity, called (say) a Network Element (NE). An NE is something that packets must go through to get from one PID to another. An NE can be a link, a router, a node, or some conglomeration of all of those. If you want to make it crystal clear that NEs can be a conglomerate, we could call them Abstract Network Elements, or ANEs. * Like PIDs, NEs have unique names. And like PID names, NE names are meaningless outside of the context of the ALTO server that defines them. * A new cost metric gives the set of NEs involved in delivering packets from the source PID to the destination PID. Note that although those NEs are represented with a JSON array, the order is irrelevant; it really is a set. * Like endpoints and PIDs, NEs can have properties. Eg, type, bandwidth, delay, etc. * If the NE set from Pid1->Pid2 intersects the NE set from Pid3->Pid4, then the client knows those two flows are dependent: they may have a common point of failure, or they may limit each other, or whatever. - Wendy Roome >Date: Wed, 25 Feb 2015 15:29:16 +0000 >From: "Scharf, Michael (Michael)" <[email protected]> >Subject: Re: [alto] ALTO topology design: separation design > > >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 _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
