Hi Richard, Greg and all, I think in some way, ALTO already has a graph representation. Consider the cost mapand the endpoint cost map provided by ECS, they are basically fullmesh graphs in the matrix representation, where the paths between certain endpoint groups or hosts can be seen as virtual links. If we look at the use casessuch as peer/replica selection, they can be seen as making "routing" decisions in those overlay graphs.So from my perspective, the "topology extensions" are more like the efforts to generalize the ALTO protocol.
As Greg has mentioned, there are quite a few works on the "topologyextension"and many of us are still looking forward to pushing it forwards. I'd very much like to contribute if the WG decides to go down the path. A major concern might be how ALTO can distinguish itself from the others. I think the value of ALTO is that it comes with application-layer semantics. Right now we have endpoints and endpoint groups, identified by IP addresses and prefixes, maybe later we can have rendez-vous points (capacity regions, shared risk links, etc.), relaypoints(caches, NAT, VPN gateways, etc.) and even some NFV nodes. Regards, Kai On 07/07/16 09:52, Y. Richard Yang wrote: > Let me add one note. Please see below. > > On Wednesday, July 6, 2016, Y. Richard Yang <[email protected] > <mailto:[email protected]>> wrote: > > Greg, > > Nice discussion! > > On Wednesday, July 6, 2016, Greg Bernstein > <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > > Hi Richard, your coding of the initial design looks fine. > However we did a lot of work in the past and the effort > within the ALTO WG stalled. This did not seem to be due to > technical disagreements by various draft authors (folks seemed > fairly flexible and in rough consensus), but rather to the WG > not wanting to move in this direction at the time. > > > My understanding is that other extensions may need to be handled > first. The timing on topology can be right. > > I'm not sure what is the best way forward with topology > extensions. Various working group participants have produced > drafts over the years that clarified the problem statement, > looked at and justified two major "architectural > alternatives", worked on some encoding details, and wrote up > some advanced work (the "A Routing State Abstraction Service > Using Declarative Equivalence" draft) based on the potential > topology extensions. > > Before putting in a bunch more time and effort it would be > good to know where the WG wants to go with these extensions. > As we've discussed such extensions are very valuable in the > SDN realm for network virtualization (with flexible network > information disclosure). Either adopting a draft on topology > extensions as a WG document or chartering a design team to > write a series of documents would get my renewed participation. > > > Network graph is a chartered WG item, and hence is becoming a > higher priority, as other items move forward. > > Here is my current thinking/reasoning on topology/routing state > abstraction for application traffic optimization: > > 1. alto is somehow not allowed to change network state, which > somehow (not fully but quite likely) imply that routing is given; > > 2. Given that routing is given, what application can do is its > traffic scheduling. Assume that the application has a set of flows > F = {f1, f2, ..., f_|F|}. If routing is given, many properties > (e.g., propagation delay) of flow i are given. What application is > given to control is x1, x2, ..., x_|F|, where xi is the amount of > traffic for flow i. Let x = [x1, ..., x_|F|] be the vector. Then > what application can do is to select the value of x. Curren ALTO > (rfc7285) already can provide the properties of the routing path > of each flow i. The main missing is the **capacibity region** of x > due to correlation among flows. The motivating example we > presented is always this case. For example, the dumbbell example > is this case: flow 1 can get 10, flow 2 can get 10, but what if > the two flows together? In other words, the capacity region can be > a complex polytope. What we mean routing path abstraction is > mostly to provide this info, which is a highly important network > info for application optimization. > > > The only other case beyond capacibity region is shared risk link > group. But this may not need to reveal topology---each flow reveals > the set of risk labels can do. Make sense? > > Richard > > > If we agree with the preceding essence, we can have a pretty > precise, concise spec. Make sense? > > Richard > > Cheers > > Greg B. > > > On 7/6/2016 9:52 AM, Y. Richard Yang wrote: >> Greg, all, >> >> I read the paper and found it highly relevant, for the >> convergence of our network graph/path vector design. Here, >> let us start with the initial design, before getting into the >> details of json encoding. Any feedback will be greatly >> appreciated. >> >> - Path-vector request: >> src/dest pairs; and optionally, for each pair, additional >> hint information such as demand, requirement metrics >> Requested properties of network elements >> >> - Path-vector response: >> Path vector for each src/dst pair, where each element in a >> path vector is an abstract network element >> A description of the properties of each network element. >> >> Example: >> Req: >> src/dst pairs: {s1 -> d1, demand = 10, latency < 20 ms}, >> {s2 -> d2, ...} >> properties: available-bw, cost >> >> Response: >> s1 -> d1: "e1", "e2", ... >> ... >> "e1" properties: available-bw = 10, cost = 3, >> >> ... >> >> The preceding does not handle the case of query topology, but >> I feel that path vector, which essentially assumes that >> routing is given and no need to worry about path >> compressions, is a good, clean start. >> >> Does the preceding missing anything? >> >> Richard >> >> On Tue, Jul 5, 2016 at 1:55 PM, Greg Bernstein >> <[email protected]> wrote: >> >> Hi all since some of our original Internet Drafts >> association with ALTO "topology extensions" our well out >> of date, those that are interested may want to look at a >> technical paper that Young and I put together back in >> 2012 >> >> (https://urldefense.proofpoint.com/v2/url?u=http-3A__www.grotto-2Dnetworking.com_files_BandwidthConstraintModeling.pdf&d=CwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=bzkMATE853C7mq8KpSsYfQ4CVhl2BqBpdPkKwCmbjvw&s=I_FGEj7wmGCRa-fWF84rtryfbW8a3WpXu1nXnSeaSBg&e= >> ). This has motivations, concepts, alternative >> representations and color highlighted figures to aid in >> comprehension. We also have the short (11 slide) >> presentation that we gave at the Vancouver 2012 IETF for >> those that never saw it or need to job their memory. >> >> Cheers >> >> Greg B. >> >> >> On 7/5/2016 10:27 AM, Vijay K. Gurbani wrote: >> >> On 07/05/2016 12:25 PM, Y. Richard Yang wrote: >> >> Vijay, >> >> Please see inline. [...] OK. We should target >> posting a spec by this >> Friday so that we can discuss the spec before the >> meeting, to remove >> any confusion/bewilderment. Since the key piece >> is encoding >> specification of (1) graph; and (2) path vector >> associated w/ a >> graph. We will target posting those spec, >> precisely first. >> >> >> Richard: Awesome! Thanks. >> >> - vijay >> >> >> _______________________________________________ >> alto mailing list >> [email protected] >> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_alto&d=CwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=bzkMATE853C7mq8KpSsYfQ4CVhl2BqBpdPkKwCmbjvw&s=-othJunl7gz_02BM9c1kqLPhFmI2iJr3vD6gu41kd_w&e= >> >> >> >> >> >> -- >> -- >> ===================================== >> | Y. Richard Yang <[email protected]> | >> | Professor of Computer Science | >> | http://www.cs.yale.edu/~yry/ >> <http://www.cs.yale.edu/%7Eyry/> | >> ===================================== > > > > -- > Richard > > > > -- > Richard > > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
