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
