On Wed, Feb 25, 2015 at 4:24 PM, Y. Richard Yang <[email protected]> wrote:
> I also support the terminology of Abstract Network Elements (ANE). The > idea of introducing an abstract network (graph) element that is a base for > both nodes (vertices) and links (edges) is clean. For example, this is also > the design of Blueprints; see > https://github.com/tinkerpop/blueprints/wiki/Property-Graph-Model. > > Here are some more details that we need to agree on. The quoted sentences > are from Wendy's previous email: > > Q1: "* 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." > > So this is by using cost map. All agree? > Before we go too far regarding exposing path vectors to applications. One issue is that there can be the issue of multi-path routing (e..g, ECMP). Hence, a more general design is to use a flow model (see slides 10 to 12 of http://www.ietf.org/proceedings/91/slides/slides-91-alto-4.pdf). I am sure some (Greg? :-) and some will not. We need to reach an agreement on this. > Q2: "* Like endpoints and PIDs, NEs can have properties. Eg, type, > bandwidth, > delay, etc." > > What is the map (or maps) for such mapping of properties? We already have > endpoint properties. Ideally, this new mapping (and the additional PID > property mapping) should be designed to be consistent. All agree? > > Thanks! > Richard > > > On Wed, Feb 25, 2015 at 4:09 PM, Scharf, Michael (Michael) < > [email protected]> wrote: > >> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_alto&d=AwIFAw&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=vdG3SCjU9pqdD8xOwqkV0MWp35yXQg6YB5lY87ys60c&s=fw44WRIugHgS3r4A5CA2oBZOzuGPvZ24G3XHFSP5zD0&e= >> >> _______________________________________________ >> alto mailing list >> [email protected] >> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_alto&d=AwIFAw&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=vdG3SCjU9pqdD8xOwqkV0MWp35yXQg6YB5lY87ys60c&s=fw44WRIugHgS3r4A5CA2oBZOzuGPvZ24G3XHFSP5zD0&e= >> > >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
