Hi Kai,
Thanks a lot for this proposal, it is a great idea to differentiate path costs
wrt flow parameters. A couple of years ago there were discussions to extend the
cost value format so as to provide several values depending on so-called
qualitative parameters. This draft on the Openflow case is a progress in that
direction.
I would have a couple of questions and rough ideas illustrated with an example
below.
--- Section 2.3 Cost Confidence and example in section 3.7:
It is valuable to guess the level of reliability of cost values. It may be
useful as well for the application clients to have an idea on the value range
with indicators such as "+/- X%" (I am not claiming any format here). They
would both reflect the confidence and the value range. For instance a value
like "20 +/- 200%" may be interpreted differently than "20 +/- 10%". Do you
think it makes sense?
--- Section 3 Flow cost service
In addition to flow parameters such as "eth S and D", path costs may be refined
wrt considerations such as SLA, access type or other qualitative parameters to
be identified.
It would be nice to gather those qualitative parameters in a IRD so that ALTO
clients have a list in which to pick parameters wrt which to evaluate path
costs.
Having this flexible list, the IRD may then associate an ID "Pi" to each param
and the ALTO Server could deliver values in an array such as V1, V2, V3 that
would be associated to an array of Pi allowing an easy mapping together with a
light encoding.
Do you think you could then consider creating new resources rather than a new
media-type?
A rough example (again, names are examples)
-------------------------
IRD capabilities for a flow-cost-map-resource could include:
"capabilities" : {
…..
"cost-type-names" : [ "num-routingcost", "num-hopcount" ],
"flow-parameter-names" : [access-type,
SLA,
ethernet
source-destination, ... ]
}
A response may have the following example members (please don't blame the
syntax errors)
{
"meta" : {
...
"cost-types" : {"cost-mode": "numerical", "cost-metric": "routingcost"},
"flow-parameters" : [access-type : A1,
SLA : S1,
ethernet source-destination :
["12:34:56:78:00:01",
"12:34:56:78:00:02"] ],
}
"endpoint-cost-map" : {
"ipv4:192.0.2.2": {
"ipv4:192.0.2.89": [15, 5, 12],
"ipv4:203.0.113.45": [4, 23, 13]
}
"ipv6:2001:db8::1:0": {
"ipv4:198.51.100.34": [16, 5, 14],
"ipv6:2001:db8::10": [10, 2, 15]
}
}
-------------------------
Of course a fully fleshed example would be better. I just wanted first to sense
opinions and see if you think this makes sense.
Thanks
Sabine
De : alto [mailto:[email protected]] De la part de Gao Kai
Envoyé : samedi 9 juillet 2016 03:43
À : IETF ALTO
Objet : [alto] New ALTO I-D: draft-gao-alto-fcs
Dear all,
We have submitted a new draft [1] in which a new service type named flow cost
service is introduced. The extension allows clients to specify queries at the
flow level, which might result in more accurate costs especially in a network
using new forwarding abstractions such as OpenFlow. The flow cost service can
also reduce the redundancy of endpoint cost maps in certain scenarios, mostly
the flow scheduling problem such as VM migration or large-volume data transfer
coordination.
Your comments and opinions are highly appreciated!
Thanks!
Regards,
Kai
[1] https://datatracker.ietf.org/doc/draft-gao-alto-fcs/
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
