Hi Sabine, Wonderful! Actually, I'm working with Dawn recently and hoping to update the draft-yang-alto-path-vector. About your suggestions, I have some comments. See below.
Best, Jensen On Sat, Mar 4, 2017 at 1:44 AM, Randriamasy, Sabine (Nokia - FR) < [email protected]> wrote: > Hi Dawn and Jensen, path-vector authors and all, > > > > Thanks a lot for resuming the discussion on the “path-vector” mode. I also > read your e-mails on the “Problems of encoding path-vector in multi-cost” > discussions. Before answering, I needed to clarify on the proposed designs > on path-vector. > > So below I have some suggestions for the path-vector extensions design on > which I would like your feedback. > > I will feel more comfortable to resume the discussion on “Problems of > encoding path-vector in multi-cost”, if I rely on the proposed design. I do > not yet include the RSADE in this discussion. > > > > Thanks, > > Sabine > > > > > > I rely on the presentation that was done at the IETF96 ALTO session in > Berlin last July and exposes a different design for the , see > https://www.ietf.org/proceedings/96/slides/slides-96-alto-6.pdf > > > > Slides 16 and 17 expose responses with particular fields for the Filtered > Cost Map service: > > ------------------------------------------------------------------ > > … > > "cost-type" : {“cost-metric”: *“ane”*, *"cost-mode" : ”path-vector” *} > > … > > "cost-map" : { > > "PID1": { "PID1":[], "PID2":["ne56", "ne67"], "PID3":[], "PID4":["ne57”]}, > > "PID2": { "PID1":["ne75"], "PID2":[], "PID3":["ne75"], "PID4":[]}, … > > …. > > “nep-map”: (full nep values or reference to map in “meta”) > > ------------------------------------------------------------------ > > > I think "ane" in slides 16 and 17 means the abstract network element. It should be computed by the RSA algorithm. > The design of the "cost-type" field looks more in line with the ALTO > logics. A Cost Map exposing a sequence of “anes” hints that “the requested > metric was “ane”. However, I understand that the motivation of the design > proposed in https://tools.ietf.org/html/draft-yang-alto-path-vector-03 is > to condense “bw” information with path vectors and avoid a separate query > for “ane” properties. > > > As I mentioned above, "ane" is computed by RSA. If we don't use RSA here, let's think about the basic path-vector. I think the result of path-vector is independent of the cost-metric like "bw" or "delay". So I suggest we just define "ne" or "link" as the cost-metric when we use path-vector as the cost-mode. > So how about requesting sets of “ane” properties such as e.g. “bw” and > “delay” by adding a filtering constraint in a Filtered Cost Map request? I > think the same would hold for the Endpoint Cost Service. > > > If we use RSA, (it's that we use "ane" as the cost-metric) "ane-properties" is an acceptable solution. But the problem is how to handle "constriants". I'm glad to borrow the design of multi-cost. So we can use "testable-cost-types" instead of "ane-properties". Is it acceptable? > The query for a FCM with the path-vector specific input could look as > follows. > > Forgive syntax errors and field names are examples. > > ------------------------------------------------------------------ > > POST /path-vector/costmap/filtered HTTP/1.1 > > Host: alto.example.com > > Accept: application/alto-costmap+json,application/alto-error+json > > Content-Type: application/alto-costmapfilter+json > > Content-Length: ### > > > > { > > "cost-type" : > > {"cost-mode": "path-vector", "cost-metric": "ane"}, > > "ane-properties" : ["bw", "delay"], > > "pids" : {}, > > "path-pids" : [ > > {"srcs" : [ "PID1" ], "dsts" : [ "PID1", "PID2", "PID3", "PID4" ]}, > > {"srcs" : [ "PID2" ], "dsts" : [ "PID1", "PID2", "PID3", "PID4" ]} > > ] > > } > > > > ------------------------------------------------------------------ > > The response would be as suggested by Richard’s presentation mentioned > above. > > With several (src, dsts) pairs in the input, we would not avoid > introducing a new mime type, but the differences would be reasonable. > > > As for the option between including the “nep-map” and values or referencing > it in the meta, it depends on the “nep-map” size. Specifying the input > member names in accordance with the Unified Properties extensions proposed > in https://tools.ietf.org/html/draft-roome-alto-unified-props-01 may > allow a fast generation of request for “ane” properties values. > > > Agree. Actually, we are going to use the unified-props to define "nep-map". So we can query "bw" or "delay" by Filtered Property Map service. If we use "constraints" and "testable-cost-types" in FCM, the property names in "nep-map" should match the names in "testable-cost-types". But for "ane", every query may generate a new "anep-map". Although you may send the same query by twice, the ALTO server may have to generate two different "anep-map"s rather than only updates the "ane" properties values. That's the only consideration from me. However, it is implementation-related. We can ignore this issue first. > > > *From:* Jensen Zhang [mailto:[email protected]] > *Sent:* mardi 28 février 2017 13:22 > *To:* Randriamasy, Sabine (Nokia - FR) <sabine.randriamasy@nokia- > bell-labs.com> > *Cc:* Gurbani, Vijay (Nokia - US) <[email protected]>; Y. > Richard Yang <[email protected]>; [email protected]; > [email protected]; IETF ALTO < > [email protected]> > *Subject:* Re: [alto] Graph representation format deliverable as WG item > > > > 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
