Subject: [alto] i2aex BOF - SDN Use Case

From: Tina TSOU <[email-masked]>
Date: Fri, 23 Mar 2012 23:34:01 +0000

Dear i2aex BoF chairs,
Attached please find slides for 

Infrastructure to Application Exposure (I2AEX) Use Case

 - Software Define/Driven Networking (SDN)

Comments are welcome.

Tina

---

From: Young Lee <[email-masked]>
Date: Sat, 24 Mar 2012 23:53:20 -0500

Hi Richard

Thanks for your great comment. I think you hit the right issue. I agree
with you. The ppt slides did not make it clear but our intention was to
suggest a graph representation to "complement" the bgp fashioned cost map.
As you indicated, neither the bgp fashioned cost map alone nor graph
representation alone will satisfy the requirements necessary for the
applications with assured service quality.

We can discuss this issue on Monday. Thanks.

Young
On Mar 24, 2012 6:22 PM, "Y. R. Yang" <[email-masked]> 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.
>
> 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-masked]> 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-masked]
> > https://www.ietf.org/mailman/listinfo/altoext
> _______________________________________________
> altoext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/altoext
>