On 3/25/12 2:48 PM, Greg Bernstein wrote:
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.
Adding penalty for over-utilization (to solve the problem of internal
coupling) is a very good, and general idea!
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.
I agree that there can be use cases where apps may have control over
route choices. The case of using loose routing is quite interesting
indeed. Regarding high reliability, SRLG immediately comes to mind.
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?
s1 -> rs -> r1 -> rd -> d1, or
s1 -> rs -> r2 -> rd -> d1
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 ;-) .
A scenario is that an infrastructure exposes 3 data structures (maps):
- a network (location) map to define PIDs;
- a path-vector cost map to define (related) pair-wise (PID) path vector
(cost), for example, s1 -> d1: rs r1 rd to indicate that the provider
selects this path;
- a topology map (graph) to allow indication of link properties (e.g.,
abw, latency).
"reservation interface"? not fully clear yet :-(
I sure have learned much from the high bw use case.
Thanks.
Richard
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
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
