Subject: [alto] i2aex BOF - Large Bandwidth Use Case

From: Leeyoung <[email-masked]>
Date: Fri, 23 Mar 2012 17:40:52 +0000

WARNING: contains banned part

Subject: i2aex BOF - Large Bandwidth Use Case
From: Leeyoung <[email-masked]>
To: "Vijay K. Gurbani" <[email-masked]>, Spencer Dawkins <[email-masked]>
Cc: Enrico Marocco <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Greg Bernstein <[email-masked]>, DIEGO LOPEZ GARCIA <[email-masked]>
Date: Fri, 23 Mar 2012 17:40:52 +0000

Hi Vijay,

Here' the PPT slides for Large Bandwidth Use Case. I'd appreciate it if you can upload to the pertinent place.

Please send us your comments and suggestions to the list.

Thanks.
Greg, Diego and Young

---

From: Tina TSOU <[email-masked]>
Date: Sat, 24 Mar 2012 21:14:36 +0000

Attached are the updated slides after some discussion with chairs. Thank you.
C u soon in Paris.

Tina

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Tina TSOU
> Sent: Friday, March 23, 2012 4:34 PM
> To: Vijay K. Gurbani; Spencer Dawkins
> Cc: [email-masked]; [email-masked]
> Subject: [altoext] i2aex BOF - SDN Use Case
> 
> 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: "Y. R. Yang" <[email-masked]>
Date: Sat, 24 Mar 2012 19:27:19 -0400

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:

> 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

---

From: ZongNing <[email-masked]>
Date: Sun, 25 Mar 2012 10:52:34 +0000

Hi, Tina,

Very interesting topic! One comment after a quick review:
In page 5 in the slides, it seems that you prefer to put ALTO on top of SDN controller. I am wondering if the primary goal of ALTO-SDN is for better SDN control or better ALTO service?
If the goal is for better SDN, then how ALTO could help SDN? Receive information from SDN controller, then combine with other ALTO information and feedback to SDN?
Also in page 5, I don't understand why the data are forwarded from SDN to ALTO?
Would you please elaborate this? Thanks.

-Ning
________________________________________
From: [email-masked] [[email-masked]] on behalf of Tina TSOU [[email-masked]]
Sent: Sunday, March 25, 2012 5:14 AM
To: Vijay K. Gurbani; Spencer Dawkins
Cc: [email-masked]; [email-masked]
Subject: Re: [altoext] i2aex BOF - SDN Use Case

Tina

---

From: Ping Pan <[email-masked]>
Date: Sun, 25 Mar 2012 14:04:37 +0200

Concur.

ALTO is currently used in support of P2P and CDN operation. It has the
functionality to query the network topological data. However that's where
the similarity with SDN ends. Running them together, how are they
inter-related?

Also you have brought up the concept of SDN Domains. What are they? Who
owns them? Why do we need them? For scaling? For admin? If for scaling, SDN
controller intrinsically has no scaling problem per sa. For admin, SDN is
to offer an overlay architecture on top of the network with a uniformed
view from application perspective, which is opposite of having some sort of
peering models. Please elaborate your thoughts.

On Sun, Mar 25, 2012 at 12:52 PM, ZongNing <[email-masked]> wrote:

> In page 5 in the slides, it seems that you prefer to put ALTO on top of
> SDN controller. I am wondering if the primary goal of ALTO-SDN is for
> better SDN control or better ALTO service?
> If the goal is for better SDN, then how ALTO could help SDN? Receive
> information from SDN controller, then combine with other ALTO information
> and feedback to SDN?
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>

---

From: Greg Bernstein <[email-masked]>
Date: Sun, 25 Mar 2012 11:48:15 -0700

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
> 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…
--> 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
>
--> 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 bet…
--> 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-masked]>  wrote:
>

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

---

From: Ken Gray <[email-masked]>
Date: Sun, 25 Mar 2012 14:22:38 -0700

I always thought the relationship of ALTO to SDN was to be one of perhaps multiple topological information sources.  In short, I don't see ALTO on top of SDN, I see it as a plug-in module under the category of topology.

/jumpingontosoapbox

SDN decisions aren't made in a vacuum 8^), so any SDN-like broker needs information on how to get from here (client or client by proxy of some querying service) to there (service).  The extensions to ALTO that make it preferential as such a tool are those that make it more dynamic (partial updates, push) and the separation of cost from something harder to manipulate (or that you don't want to manipulate, like IGP metric) …and maybe even express something like … policy.

Where I see there being a pending collision is when a tool like ALTO expresses multiple sub-services of an overall SDN solution (like topology and policy) …and how we account for that in SDNP.  Because the challenge of SDNP is to see ALTO, OF, PCEP, BGP-TE, overlays (NOV3 for example) …as tools (some of them interchangeable) used to describe a service to some application through a northbound API.

What SDN needs is a standardized interface for representing topology amongst the many candidates (there's at least one other source I can think of off the top of my head … BGP-TE …and of course, static maps) that allows for varying richness in functionality.

/jumpingoffsoapbox

From: Ping Pan <[email-masked]<mailto:[email-masked]>>
Date: Sun, 25 Mar 2012 05:04:37 -0700
To: ZongNing <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Vijay K. Gurbani" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Spencer Dawkins <[email-masked]<mailto:[email-masked]>>, Tina TSOU <[email-masked]<mailto:[email-masked]>>
Subject: Re: [altoext] [alto] i2aex BOF - SDN Use Case

Concur.

ALTO is currently used in support of P2P and CDN operation. It has the functionality to query the network topological data. However that's where the similarity with SDN ends. Running them together, how are they inter-related?

Also you have brought up the concept of SDN Domains. What are they? Who owns them? Why do we need them? For scaling? For admin? If for scaling, SDN controller intrinsically has no scaling problem per sa. For admin, SDN is to offer an overlay architecture on top of the network with a uniformed view from application perspective, which is opposite of having some sort of peering models. Please elaborate your thoughts.

On Sun, Mar 25, 2012 at 12:52 PM, ZongNing <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Tina,

-Ning
________________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] on behalf of Tina TSOU [[email-masked]<mailto:[email-masked]>]
Sent: Sunday, March 25, 2012 5:14 AM
To: Vijay K. Gurbani; Spencer Dawkins
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [altoext] i2aex BOF - SDN Use Case

Tina

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
> Behalf Of Tina TSOU
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
_______________________________________________
alto mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/alto

---

From: Ping Pan <[email-masked]>
Date: Sun, 25 Mar 2012 23:32:51 +0200

Agree 100%.

On Sun, Mar 25, 2012 at 11:22 PM, Ken Gray <[email-masked]> wrote:

> What SDN needs is a standardized interface for representing topology
> amongst the many candidates (there's at least one other source I can think
> of off the top of my head … BGP-TE …and of course, static maps) that allows
> for varying richness in functionality.

---

From: "Y. Richard Yang" <[email-masked]>
Date: Sun, 25 Mar 2012 22:38:54 -0400

On 3/25/12 2:48 PM, Greg Bernstein wrote:
>> 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.
> 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).
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.
> 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
>>
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
>>> 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

---

From: Tina TSOU <[email-masked]>
Date: Mon, 26 Mar 2012 20:50:04 +0000

Sorry I could not attend today's meeting, as I was in ER.
Comments r in line.

Sent from my iPad

On Mar 25, 2012, at 2:05 PM, "Ping Pan" <[email-masked]<mailto:[email-masked]>> wrote:

Concur.

ALTO is currently used in support of P2P and CDN operation. It has the functionality to query the network topological data. However that's where the similarity with SDN ends. Running them together, how are they inter-related?
That is the purpose of this draft to handle

Also you have brought up the concept of SDN Domains. What are they? Who owns them? Why do we need them? For scaling? For admin? If for scaling, SDN controller intrinsically has no scaling problem per sa. For admin, SDN is to offer an overlay architecture on top of the network with a uniformed view from application perspective, which is opposite of having some sort of peering models. Please elaborate your thoughts.
SDN domains are built by network operator for flexible admin purpose. It depends on the scale of underlying network that operator how to divide whole network into SDN domains. For some small scale data centers, only one SDN domain may be enough. For some carrier’s large networks, it make sense to operate thru several SDNs. Letting single one SDN controller to overview whole ATT/Verizon’s network seems not realistic. For example, Operator can divide its network into different SDN domains based on physical locations. It can lease such part of its network to local content provider, or DC, etc. Such deployment scenario requires SDN controller providing powerful network service capability to applications which depends on implementation. Here we only talk about some basic requirements for SDN, like collecting fine grain underlying device information. This information can be shared with ALTO. ALTO protocol can be simplified with SDN, and SDN can use ALTO’s result to provide more flexible service to user applications in path defining. Here we are assuming SDN controller works as an open platform based on that user can build its own applications.

We are not saying the goal is for better SDN or better ALTO. We are talking both of them can benefit from each other when they work interactively. Since SDN is only emerging and has no such real products, so here we can say it may be better for ALTO.  While with the development and implementation of SDN techniques, we think SDN can benefit as well from ALTO and provide in path defining and selection at user application level.

-Ning

Tina