Hi Dawn,
The "possible result2" doesn't make sense:
1. "nep-map" is a property, not a mutable key. It's hard to understand what
is "nep-map1" and "nep-map2".
2. "cost-map" is a map, not a list... The schema looks a little strange...
3. Why there are different path vectors between the same pair?
I think you want to talk about these two options for the response:
Option 1:
"cost-map": {
"ipv4: 192.0.1.1": {
"ipv4: 192.0.1.2": ["ne57","ne59"],
"ipv4: 192.0.1.4": ["ne57", "ne74"]
},
"nep-map": {
"ne57": {"bw": 100, "delay": 10},
"ne59": {"bw": 100, "delay": 20},
"ne74": {"bw": 100, "delay": 15}
}
Option 2: (Although it doesn't make sense because of the different
routings.)
"cost-map": {
"ipv4: 192.0.1.1": {
"ipv4: 192.0.1.2": [["ne57"], ["ne34", "ne56"]],
"ipv4: 192.0.1.4": [["ne57", "ne74"], ["ne56", "ne68"]]
}
},
"nep-map": [{
"ne57": {"bw": 100},
"ne74": {"bw": 100}
}, {
"ne34": {"delay": 15},
"ne56": {"delay": 15},
"ne68": {"delay": 10}
}]
I agree that it is a real issue when path-vector wants to be compatible
with multi-cost. Actually, I think the major problem is from the "nep-map"
design in the path-vector. Shall "nep-map" be a property of the cost-map or
the cost-type? I prefer it as a property of the cost-map. So I prefer
option 1.
There are two reasons for me to support option1:
1. Path-vector should be a static property of the network (suppose the
routing is static and we don't use RSA). So when we query multi-costs with
path-vector, we actually want to query multi-metrics of the same
path-vector.
2. Very simple reason: option 2 is redundant, right?
Now I have a question. Is it really necessary for us to query multiple
cost-modes in one request? Or we just need to query multiple cost-metrics
with the same cost-mode? e.g. shall we need to send a query like
`[{"cost-mode": "numeric", "cost-metric": "hopcount"}, {"cost-mode":
"ordinal", "cost-metric": "routingcost"}]`? @Sabine and @Wendy, may I know
your thoughts?
Thanks,
Jensen
On Mon, Feb 27, 2017 at 10:56 PM, Chan Dawn <[email protected]> wrote:
> Hi authors of draft-multi-cost and draft-alto-path-vector and all,
>
> I just find a problem of encoding cost-mode "path-vector" in multi-cost
> service. Here is the details of the problem.
>
> Suppose an ALTO client queries the ALTO server in this format:
> .........
> "multi-cost-type"[
> {"cost-metric": "bw", "cost-mode": "path-vector"} ,
> {"cost-metric": "delay", "cost-mode": "path-vector"}
> ]
> "endpoints"{
> "srcs": ["ipv4: 192.0.1.1"] ,
> "dsts": [
> "ipv4: 192.0.1.2" ,
> "ipv4: 192.0.1.4"
> ]
> }
> ......
>
> Two cost types with the same cost-mode but different cost-metrics. So,
> what is the ALTO server supposed to return? Should the server return one
> single map taking both metrics into consideration? Or should the server
> return two independent maps seperating two cost types?
>
> Possible results are listed here :
>
> 1. Return one single map
> ......
> "cost-map": {
> "ipv4: 192.0.1.1": {
> "ipv4: 192.0.1.2": ["ne57","ne59"],
> "ipv4: 192.0.1.4": ["ne57", "ne74"]
> }
> "nep-map": {
> "ne57": {"bw": 100, "delay": 10},
> "ne59": {"bw": 100, "delay": 20},
> "ne74": {"bw": 100, "delay": 15}
> }
> ......
>
> 2. Return two independent maps
> ......
> "cost-map": {
> ["ipv4: 192.0.1.1": {
> "ipv4: 192.0.1.2": ["ne57"],
> "ipv4: 192.0.1.4": ["ne57", "ne74"]
> }]
> ["ipv4: 192.0.1.1": {
> "ipv4: 192.0.1.2": ["ne34", "ne56"],
> "ipv4: 192.0.1.4": ["ne56", "ne68"]
> ]}
> }
> "nep-map1": {
> "ne57": {"bw": 100},
> "ne74": {"bw": 100}
> }
> "nep-map1": {
> "ne34": {"delay": 15},
> "ne56": {"delay": 15},
> "ne68": {"delay": 10}
> }
> ......
>
> The possible solution to eliminate such ambiguity is that we make some
> changes on the cost types in the multi-cost design. That is to say, there
> can be several cost metrics with one specific cost mode in a cost type, so
> the design of cost type may look like this:
> object {
> CostMetric cost-metric <1..*> ;
> CostMode cost-mode;
> [JSONString description;]
> }CostType;
>
> Or maybe we can modify the cost-mode path-vector, but I don't have a clear
> idea about this. Any comment on this problem?
>
> Regards,
> Dawn
>
>
> _______________________________________________
> alto mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/alto
>
>
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
