Re: [alto] Graph representation format deliverable as WG item

[Jensen Zhang <[e-mail]>]

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) <
[e-mail]> 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:[e-mail]]
> *Sent:* mardi 28 février 2017 13:22
> *To:* Randriamasy, Sabine (Nokia - FR) <sabine.randriamasy@nokia-
> bell-labs.com>
> *Cc:* Gurbani, Vijay (Nokia - US) <[e-mail]>; Y.
> Richard Yang <[e-mail]>; [e-mail];
> [e-mail]; IETF ALTO <
> [e-mail]>
> *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) <
> [e-mail]> 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
>
>
>