Hi Young, Very nice deck of slides with some very interesting use cases!
A quick comment/question on using approximate graphs to address the interesting issues of shared bottlenecks that may not be exposed by e2e links. In a dynamic, interactive constraint solving/joint optimization setting, such internal coupling will show up as "cost" increase on one source-dest pair, when using another independent pair. But your use case does show another way to expose infrastructure info. We consider the use case that the path for a source, destination pair is computed by the infrastructure, not by the app (otherwise, it is a different story). Then one issue of exposing only a graph is ambiguity for an app to determine the path for a source, destination pair, unless the underlying graph has no loop, since then the computed path then will depend on the policy of the infrastructure. For example, consider a graph, where each s1, s2, rs, r1, r2, rd, d1, d2 is a pid, si is source ER, and di is destination ER in your example: s1 -> rs s2 -> rs rs -> r1 rs -> r2 r1 -> rd r2 -> rd rd -> d1 rd -> d2 Then the app may not be able to figure out the path for s1 to d1, or s2 to d2. One possibility is to expose the node path in a "cost" map, where the value of each entry is a (bgp style) path vector, in addition to a graph topology map. I get a feeling that others may have better, more compact representation, but the preceding seems simple. What do you think? Thanks! Richard On Mar 23, 2012, at 1:40 PM, Leeyoung <[email protected]> wrote: > WARNING: contains banned part > This message cannot be displayed because of the way it is formatted. Ask the > sender to send it again using a different format or email program. > multipart/mixed > _______________________________________________ > altoext mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/altoext _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
