Hi Richard good questions and comments see below for a few more comments.
Folks remember to talk clearly into the microphones at the meeting. A
number of use will be "remote"!
Cheers
Greg
On 3/24/2012 4:27 PM, Y. R. Yang wrote:
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.
--> When Young and I have formulated multi-commodity flow problems for
TDM and wavelength networks we usually start by keeping the constraint
notions of bandwidth (timeslots, wavelength) separate from cost
notions. In some formulations we will allow for overcapacity (generally
to see where to light up more fiber) by adding a severe cost penalty for
over utilized links.
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).
--> We consider the case where an app may have some control/preference
over route choices. In GMPLS we have the notion of loose routes/paths.
In the optical world, particularly high reliability, there may be more
factors in the app wanting to have some say over the routes.
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.
--> The "tree" graph in the draft was easiest to draw but the slides
show more realistic graphs with rings and meshes. If the app will not
have a choice in path or has no way to tell the infrastructure the path,
then I'm not sure of need of a graph over a cost map or a distance vector.
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.
--> From the perspective of ambiguity since there are multiple paths
that could be taken?
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?
--> Hmm, interesting. Are you suggesting to use both a graph to capture
bottlenecks and a path vector to show costs and provider selected
routes? Hmm, this sounds useful without the "reservation interface" that
we would also like ;-) .
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
_______________________________________________
altoext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/altoext
--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
