Dear Richard and all,
I think one interesting problem for unified properties is that how to support more powerful filtered property map. Specifically, a server should be able to answer the requests like “can you give me the properties of all endpoints in pid1?” or “can you give me the locations of links whose bandwidth is larger than 100Mbps?" There are several potential ways to achieve that: a. Filter entities based on their properties This would be very similar with the “where” statement in SQL. The problem of this approach would be how to make servers express their filtering capabilities easily. For example, a server should be able to tell clients like “you cannot filter entity1 based on property1” or “you can use the regular expression to filter the property2 for entity2”. It is important to make clients understand what they can do with filtered property map. b. Provide a tree structure to organize entities Every node in the tree is an entity. Servers define the structure of the tree. Specifically, they define edges like a pid entity can have children nodes which are endpoint entities. Therefore clients can ask “give me all endpoint entities who are the children of pid1 entity”. However, this tree structure cannot help for the question “can you give me the locations of links whose bandwidth is larger than 100Mbps?” Thanks, Xin ________________________________ From: alto <[email protected]> on behalf of Y. Richard Yang <[email protected]> Sent: Tuesday, March 28, 2017 16:21 To: IETF ALTO Subject: [alto] Unified properties salient design points Dear all, As multiple discussions, we feel that the unified properties draft (), although not a working group draft, can be an important piece to help finish several remaining working items. For those who are not tracking the document, the design might appear to be simple: it is after all just a simple key-value map. When conducting a real design, many issues, many quite general, however, appear. Hence the design can benefit from good feedback from the good talents of this group. The objective of this email is to make clear the salient points of the current design. We will go over and discuss them Friday during the WG session. D1. The goal is to provide properties to entities. D2. Each entity must have an entity name to be identified. An entity name is a typed (domained) string, in a format of <domain>:<name>, e.g., "ipv4:192.1.1.1", "pid:myid1", "ane:myane111". The <domain> provides essentially the type of the name. D3. There are essentially three types of domains: global, per-resource, per-query (dynamic): D3.1 ipv4 and ipv6 are global, in that they are not dependent on particular resources; D3.2 pid depends on a particular network map resource; D3.3 ane (abstract network element) may depend on a particular query of an ALTO resource. So far we cannot handle such case well. There can be multiple design options, but each adds more complexity. D4. Aggregation of entities is allowed, to improve scalability. Hence, an entity name may be either an individual entity or a set. An example is an IP prefix. D4.1 An implication of 4. is that we need to handle property inheritance. Multi-inheritance is tricky, as OOP multi-inheritance demonstrated. So far longest prefix matching (LPM) avoids the problem. But we need to decide if we want to have a spec on future design of this aspect. D5. Property names are in a global namespace, to enforce global, consistent usage of property names. It is not a long list but contains many interesting design points. Looking forward to good discussions soon! Richard
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
