Re: [altoext] i2aex BOF - Large Bandwidth Use Case

[Greg Bernstein <[e-mail]>]

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<[e-mail]>  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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/altoext
> _______________________________________________
> altoext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/altoext
>
>


-- 
===================================================
Dr Greg Bernstein, Grotto Networking [phone]