Richard, I’d like to understand a simpler question first; I don’t recall whether we have already discussed this basic scenario so far: Assume we have PID1 and PID2 and the ALTO server operator wants to announce that there are two entirely disjoint paths between those PIDs. The path vector would probably just include ANE1 and ANE2 as alternatives. Is there a way to encode this simple scenario in path vector without using the “general flow” model?
If we go for general flow, could we make the weight parameter optional? Michael PS: Other naming suggestions: Provider-Defined Network Element (PAE), Provider-Defined Topology Entity (PTE), Provider-Defined Path Element (PPE), or use of “Abstract” instead of “Provider-Defined”, or combinations thereof… From: [email protected] [mailto:[email protected]] On Behalf Of Y. Richard Yang Sent: Wednesday, February 25, 2015 10:35 PM To: Scharf, Michael (Michael) Cc: ROOME, Wendy D (Wendy); [email protected] Subject: Re: [alto] ALTO topology design: separation design On Wed, Feb 25, 2015 at 4:24 PM, Y. Richard Yang <[email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>] Im Auftrag von Wendy Roome Gesendet: Mittwoch, 25. Februar 2015 21:51 An: [email protected]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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
