Hi Sabine, I just noticed your were trying to resume this discussion. Thanks a lot for your effort! And I really would like to share my opinion about issue 2 since it is related to the flow-based design. See below:
On Sat, Nov 19, 2016 at 1:45 AM, Randriamasy, Sabine (Nokia - FR) < [email protected]> wrote: > Hello authors of path vector and RSADE extensions and all, > > Both drafts address several emerging use cases, in particular, the > multi-path 1st hop, where each hop corresponds to a different choice of > access technology. > > I'd like to resume the discussion started in IETF96-Berlin upon Richard's > presentation, see https://www.ietf.org/proceedings/96/slides/slides- > 96-alto-6.pdf > > - issue 2 slide 12: multiple (S,D) pairs (with S and D = sets) in a query > is more than useful. > Is there a way to allow this as well for "regular" ECS and F/CM ? Can we > apply this to both "flows/endpoints" and "PID-paths" ? > > - issue 2 design choices: a smooth transition would be using native cost > maps with multiple input several (S,D) pairs. > > If I get your point, you are suggesting to use the solution like this: (right?) "cost-map": { "SPID1": { "DPID1": xxx }, "SPID2": { "DPID2": yyy } } If so, it still cannot handle the fine-grained flow (such as L4 routing). Although Richard's presentation did not mention the fine-grained flow, it is the actual motivation of introducing flow-based design. I think the most important use case of flow-based design is the central flow-level scheduling. It will often appear in the central controlled network like SDN. So the flow is usually fine-grained. I know introducing flow-based design is a big change for ALTO. But if it is really important, I think we need to try it out. > - Cost metric and mode for "ane-aware paths": > Slide 17 illustrates for a (S,D) pair: metric = "ane", mode = > "path-vector" = array of N >= 1 "ane" > Other modes could be: > - mode = "path-graph", (multiple path-vectors - for RSADE or multi-choice > paths) > - mode = "path-e2e" (single switch N=0 base ALTO mode usually not used), > You mean (mode = "path-graph") === (mode = "path-vector", metric = "ane")? > > - conveying ane costs and properties (slides 15, 16, 17) on multi-hop maps: > In any case, ane property/cost services need to be specified and indicated > in the IRD so that the client understands what "ne24" points to. So I > suggest the anep-map to be systemetically referenced in the > dependent-vtags. As for nep-map values: > - inline: information is self-contained and saves round trips but response > may be heavy > - reference: ALTO Client gets anep map separately if needed. > > If we don't use ane, "reference" can be accepted. Because every query can share the same network elements. But ane is computed from the query input of RSADE. e.g. Query1 may send request [(s1, d1), (s2, d2)] and get the response {f1: [ane1, ane2], f2: [ane2, ane3]}; Query2 may send request [(s1, d1), (s3, d3)] and get the response {f1: [ane1', ane2', ane3'], f3: [ane1', ane4']}. For f1, [ane1, ane2] and [ane1', ane2', ane3'] should be the same route, but the result computed by ALTO server may be different. So it is hard to be referenced in the "dependent-vtags". > How about letting a Server decide what option to propose? > A Server may even directly integrate the cost values in a multi-cost > response, provided it has specified a anep-map and references it in its > response. > I am thinking about this approach. But how can a client know which option the server are using? Maybe add this claim into the "capability" of the IRD entity? > > If for instance a client requests metric "BW" in "path-vector" mode, the > protocol may request that it also requests metric "ane" in this mode (same > for "path-graph" mode). > I think "ane" is not designed clearly. Let me resume the discussion about issue 1 here: how to encode the cost-type? Maybe we really need a unified cost schema. > > Does this make sense ? > > Thanks, > Sabine > Looking forward to receiving comments from authors. I think both drafts are still valuable. We need to update them. Best, Jensen
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
