Subject: Re: [Sdn] [Sdnp] SDNRG strawman

From: Bob Briscoe <[email-masked]>
Date: Thu, 10 May 2012 11:38:48 +0100

Dave,

[Continuing this thread on the new SDN IRTF list]

Thanks for the strawman. It is indeed a good basis for an r-g charter.

The hybrid models are well introduced, but then there is no bullet 
item for them under "Areas to work on". How about:

* appropriate division of labour between distributed and SDN control 
in hybrid models and feasibility of interworking between them 
(provable safety, security etc)
* Comparative evaluation of traditional and SDN control models.

[This second one is perhaps part of your "SDN applicability" point, 
but for researchers it is more appropriate to take a broader view of 
the alternatives, not just try to find everything one solution could 
do, without investigating whether others could do it better.]

Another suggestion to add to the bullet list:

* Evaluation of claims and assertions made about SDN.

[In this vein, what did you have in mind by "allowing the control 
plane to rapidly evolve by relying on well-honed design principles 
from distributed systems for implementation"? This would be better 
phrased as "aiming to allow the control plane to rapidly evolve". I 
don't think we have evidence yet that logical centralisation of 
control results in faster evolution. Also, I don't think SDN is as 
firmly based on accepted distributed systems theory as the more 
thoroughly researched distributed routing & forwarding technologies.]

Finally, I think this thread shows that we are ripe for an "Open 
Issues in Software Defined Networking Research" draft - perhaps the 
charter ought to identify that as a potential work-item.

Bob

At 15:17 08/05/2012, David Meyer wrote:
>http://www.1-4-5.net/~dmm/sdnrg.html
>
>comments?
>
>--dmm
>_______________________________________________
>SDNP mailing list
>[email-masked]
>http://lucidvision.com/mailman/listinfo/sdnp

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: [email-masked]
Date: Thu, 10 May 2012 16:37:32 +0530 (IST)

Hi Dave, Bob,
  I could take a shot at coming up with the open issues list draft
i...Things are going to get more complicated as we progress and i
thought might as well attempt to get some tangibles in when things are
relatively simpler...plus this will be a good way for me to get
introduced better to the field.
  Initial pointers if any for this will also be most appreciated.
  Let me know.
Sitaraman

> sdn mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/sdn
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

---

From: David Meyer <[email-masked]>
Date: Thu, 10 May 2012 06:26:02 -0700

Bob,

Thanks for the thoughtful comments. A few comments in-line:

On Thu, May 10, 2012 at 3:38 AM, Bob Briscoe <[email-masked]> wrote:
> The hybrid models are well introduced, but then there is no bullet item for
> them under "Areas to work on". How about:
>
> * appropriate division of labour between distributed and SDN control in
> hybrid models and feasibility of interworking between them (provable safety,
> security etc)

I just added "Hybrid Models" under areas of interest. The points you
mention fall under that. Let me know if that gets what you want.

>
> [This second one is perhaps part of your "SDN applicability" point, but for
> researchers it is more appropriate to take a broader view of the
> alternatives, not just try to find everything one solution could do, without
> investigating whether others could do it better.]
>

I didn't add this as it seems obvious that we would do that in any
area we studied.

>
> [In this vein, what did you have in mind by "allowing the control plane to
> rapidly evolve by relying on well-honed design principles from distributed
> systems for implementation"? This would be better phrased as "aiming to
> allow the control plane to rapidly evolve". I don't think we have evidence
> yet that logical centralisation of control results in faster evolution.

Done. I will just mention that if you look at the early work by Scott
and Nick you'll see that they heavily leverage what they assert is
mature work in the area of state distribution in the distributed
systems community.

> Also, I don't think SDN is as firmly based on accepted distributed systems
> theory as the more thoroughly researched distributed routing & forwarding
> technologies.]

Again, I believe this thinking originates with early work in the area.

>
>
> Finally, I think this thread shows that we are ripe for an "Open Issues in
> Software Defined Networking Research" draft - perhaps the charter ought to
> identify that as a potential work-item.

Yep. I added a "Potential Work Items" section that contains this one.
If folks have others let me know and I'll add them

Again, thanks for the thoughtful comments.

--dmm

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 10 May 2012 10:13:11 -0400

On May 10, 2012:6:38 AM, at 6:38 AM, Bob Briscoe wrote:

> The hybrid models are well introduced, but then there is no bullet item for them under "Areas to work on". How about:
> 
> * appropriate division of labour between distributed and SDN control in hybrid models and feasibility of interworking between them (provable safety, security etc)
> [This second one is perhaps part of your "SDN applicability" point, but for researchers it is more appropriate to take a broader view of the alternatives, not just try to find everything one solution could do, without investigating whether others could do it better.]
> 
> [In this vein, what did you have in mind by "allowing the control plane to rapidly evolve by relying on well-honed design principles from distributed systems for implementation"? This would be better phrased as "aiming to allow the control plane to rapidly evolve". I don't think we have evidence yet that logical centralisation of control results in faster evolution. Also, I don't think SDN is as firmly based on accepted distributed systems theory as the more thoroughly researched distributed routing & forwarding technologies.]
> 
> 
> Finally, I think this thread shows that we are ripe for an "Open Issues in Software Defined Networking Research" draft - perhaps the charter ought to identify that as a potential work-item.

	TOM: That is a great idea. 

	--Tom

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 10 May 2012 14:24:21 +0000

Hi,

also feel free to make use of the wiki at http://trac.tools.ietf.org/group/irtf/trac/wiki. There is a section on "Pages for Potential New IRTF Activities" where you can create an SDN page, and you can obviously create other pages as you see fit.

The "open research issues" item could for example be initially worked on on the wiki, and when it's stabilized it could turn into an I-D.

Lars

---

From: David Meyer <[email-masked]>
Date: Thu, 10 May 2012 07:25:46 -0700

Thanks Lars, will do...

---dmm

---

From: Tina TSOU <[email-masked]>
Date: Thu, 10 May 2012 15:56:33 +0000

Dave,
Regarding the hybrid model, perhaps we have to figure out what the supplement work to ONF hybrid WG.

Sent from my iPad

---

From: David Meyer <[email-masked]>
Date: Thu, 10 May 2012 09:01:03 -0700

> Regarding the hybrid model, perhaps we have to figure out what the supplement work to ONF hybrid WG.

My sense is that the ONF is trying to build an
architecture/standardize today's hybrid model(s), and the IRTF group
would be more concerned with the longer term view.

--dmm

---

From: Tina TSOU <[email-masked]>
Date: Thu, 10 May 2012 16:10:44 +0000

Sent from my iPad

> would be more concerned with the longer term view.
Can we say SIN mode is short term, Integrated mode is long term?

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 10 May 2012 12:53:39 -0400

I'd rather let the IRTF work exist independently of anything in ONF. Again, the point of IRTF work is to be free to examine whatever researchers are looking at around this area without being constrained by any particular SDO's goals.  If things feedback one way or another, that is cool, but it shouldn't be a hard/fast requirement.

	--Tom

---

From: David Meyer <[email-masked]>
Date: Thu, 10 May 2012 09:57:58 -0700

>        I'd rather let the IRTF work exist independently of anything in ONF. Again, the point of IRTF work is to be free to examine whatever researchers are looking at around this area without being…

Agreed.

--dmm

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 10 May 2012 16:58:36 +0000

Agreed.

Lars

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 10 May 2012 19:33:59 +0100

David,

>mention fall under that. Let me know if that gets what you want.

Fine.

>I didn't add this as it seems obvious that we would do that in any

Those currently making these assertions don't seem to find this obvious at all.

I just figured we should be at pains to look objective, rather than 
looking as if we want the research to confirm the answer we would like to hear.

>mature work in the area of state distribution in the distributed

Certainly, SDN re-uses fault tolerance and state distribution based 
on tried and tested distributed systems research. But that doesn't 
mean the SDN /system/ as a whole is backed up by years of accepted 
research - far from it. Even the state distribution part is only 
about whether the state sub-system /can/ always be made to become consistent.

I'm not aware of any research into the dynamics when this sub-system 
interacts with demand - ie what levels of churn at scale would outrun 
an SDN system's ability to maintain state consistency, and whether 
such levels are likely in the real world. Whereas there's been loads 
of research into that for the distributed routing protocols.

BTW, this is a good example of the need for research - no-one wants 
to find out about scale problems like this only when the mountain has 
reached such a scale that it has become very embarrassing (and very 
painful) to fall off the mountain.

Bob

---

From: David Meyer <[email-masked]>
Date: Thu, 10 May 2012 11:36:40 -0700

Hey Bob,

>> mention fall under that. Let me know if that gets what you want.

Good.

> I just figured we should be at pains to look objective, rather than looking
> as if we want the research to confirm the answer we would like to hear.
>
> Certainly, SDN re-uses fault tolerance and state distribution based on tried
> and tested distributed systems research. But that doesn't mean the SDN
> /system/ as a whole is backed up by years of accepted research - far from
> it. Even the state distribution part is only about whether the state
> sub-system /can/ always be made to become consistent.
>
> interacts with demand - ie what levels of churn at scale would outrun an SDN
> system's ability to maintain state consistency, and whether such levels are
> likely in the real world. Whereas there's been loads of research into that
> for the distributed routing protocols.

Hey, you just hit on one of my favorite research topics.

>
> BTW, this is a good example of the need for research - no-one wants to find
> out about scale problems like this only when the mountain has reached such a
> scale that it has become very embarrassing (and very painful) to fall off
> the mountain.

Yep.

Thnx,

--dmm

---

From: Edward Crabbe <[email-masked]>
Date: Thu, 10 May 2012 11:44:34 -0700

I agree with most of the points below.   One comment in-line though:

On Thu, May 10, 2012 at 3:38 AM, Bob Briscoe <[email-masked]> wrote:

> The hybrid models are well introduced, but then there is no bullet item
> for them under "Areas to work on". How about:
>
> hybrid models and feasibility of interworking between them (provable
> safety, security etc)
> [This second one is perhaps part of your "SDN applicability" point, but
> for researchers it is more appropriate to take a broader view of the
> alternatives, not just try to find everything one solution could do,
> without investigating whether others could do it better.]
>

I disagree:   we actually do - admittedly it's only one data point but:  we
(google) used openflow to produce a TE system used on our dc-dc backbone.
All in all, development to deploy was about a year.  Theres a video of a
pretty high level presentation Urs gave at

http://www.youtube.com/watch?v=VLHJUfgxEO4

>> http://www.1-4-5.net/~dmm/**sdnrg.html<http://www.1-4-5.net/~dmm/sdnrg.html>
>>
>> comments?
>>
>> --dmm
>> ______________________________**_________________
>> SDNP mailing list
>> [email-masked]
>> http://lucidvision.com/**mailman/listinfo/sdnp<http://lucidvision.com/mailman/listinfo/sdnp>
>>
>
> ______________________________**______________________________**____
> ______________________________**_________________
> sdn mailing list
> [email-masked]
> https://www.irtf.org/mailman/**listinfo/sdn<https://www.irtf.org/mailman/listinfo/sdn>
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 10 May 2012 20:57:38 +0200

I think this thread or in particular this example perfectly proves the 
huge confusion what SDN means.

I think Bob has in mind a totally centralized control of every packet in 
every network node.

Ed on the other hand provided good prove that using SDN wisely (for 
central end to end path calculation) has been proven to work in real 
networks in real time.

Yet another deployed industry example of good SDN application is ATT's 
IRSCP ... http://sysnet.ucsd.edu/~pverkaik/pubs/irscp-usenix2007.pdf

I think regardless in what forum SDN is going to be discussed we need to 
be much more precise on the applicability.

SDN is like a knife .. you can really hurt yourself if you are not 
careful yet imagine life without one. Till date vendors were preparing 
sandwiches for you .. now there is opportunity for you to do it yourself.

Rgs,
R.

> I disagree:   we actually do - admittedly it's only one data point but:
>   we (google) used openflow to produce a TE system used on our dc-dc
> backbone.   All in all, development to deploy was about a year.  Theres
> a video of a pretty high level presentation Urs gave at
>

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 10 May 2012 16:05:12 -0400

On May 10, 2012:2:33 PM, at 2:33 PM, Bob Briscoe wrote:

> I just figured we should be at pains to look objective, rather than looking as if we want the research to confirm the answer we would like to hear.
> 
> Certainly, SDN re-uses fault tolerance and state distribution based on tried and tested distributed systems research. But that doesn't mean the SDN /system/ as a whole is backed up by years of accepted research - far from it. Even the state distribution part is only about whether the state sub-system /can/ always be made to become consistent.
> 
> I'm not aware of any research into the dynamics when this sub-system interacts with demand - ie what levels of churn at scale would outrun an SDN system's ability to maintain state consistency, and whether such levels are likely in the real world. Whereas there's been loads of research into that for the distributed routing protocols.
> 
> BTW, this is a good example of the need for research - no-one wants to find out about scale problems like this only when the mountain has reached such a scale that it has become very embarrassing (and very painful) to fall off the mountain.

TOM: Precisely my thinking about why the IRTF group is a good idea.

	--Tom

---

From: [email-masked]
Date: Fri, 11 May 2012 03:21:38 +0530 (IST)

Hi Ed,
Very interesting keynote, thanks for this pointer, per this talk i see 
OSS systems, will be (should be ) must adapt (is well positioned to do so
and hence must be leveraged)and must be playing a central role here.  This
perhaps also means that  OSS Standards such as TMF will too, and will need
much more closer ties with IETF...

Urs talks about OAM aspects too, though he hasnt used that terminology per
se,  one of the things he did not touch is the possibility of a gradual
migration, for example, consider the question Ericsson had for Urs on
MPLS, google has moved some control plane but not others. Most likely
service providers would need to do the same thing too.
In that case the centralized controller has a greater challenge than just
handling link failures that Urs talked about....it also needs to handle,
possible misconfiguration errors, (which is perhaps even more severe with
SDN) verification of control planes (that have not yet been SDNed) against
the forwarding plane for more soft and therefore hard to find causes for
failures, also coming to aid is OAM which can (ironically) function as a
"control plane"  for SDN funcationality to handle scaling issues by
decoupling client and server from the fault analysis....
An area we could look at therefore is would IETF have a recommendation for
the migration path, which distributed control planes could be done away
with and for those that survive for now, how they could aid by providing
OAMs such as verification against the forwarding plane and server-layer
transparent  T&D aided by OAM standards.
Sitaraman

> we

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 11 May 2012 02:37:11 +0100

Robert,

At 19:57 10/05/2012, Robert Raszuk wrote:

>I think this thread or in particular this example perfectly proves 
>the huge confusion what SDN means.
>
>I think Bob has in mind a totally centralized control of every 
>packet in every network node.

Er no.

I had in mind a spectrum from v light to v heavy churn, and the 
question was how far would it be possible to go along that churn 
spectrum. For instance, it's one thing to be running a network and 
data centre for your own company's applications (Google); it's 
another to host multiple tenants, who are all pulling in different 
directions. It's yet another to give those tenants controls that 
indirectly affect your network controls through your monitors and 
automation, or even through direct APIs. We've been through this 
process with other networks (e.g. Parlay X & OneAPI on PSTN/Mobile).

If your business is hosting (as ours is), the problem becomes how to 
balance your tenants' desire for more control with a sensible level 
of tailorability. You don't have free choice over what's sensible any 
more - the market tries to pull you to give away more control than 
would otherwise be sensible.

>Yet another deployed industry example of good SDN application is 
>ATT's IRSCP ... http://sysnet.ucsd.edu/~pverkaik/pubs/irscp-usenix2007.pdf
>
>I think regardless in what forum SDN is going to be discussed we 
>need to be much more precise on the applicability.
>
>careful yet imagine life without one. Till date vendors were 
>preparing sandwiches for you .. now there is opportunity for you to 
>do it yourself.

Perhaps these points about initial SDN applicability would be better 
suited to the IETF SDNP list? We're trying to define an r-g charter here.

Bob

---

From: Ping Pan <[email-masked]>
Date: Fri, 11 May 2012 14:35:06 -0700

On Thu, May 10, 2012 at 11:57 AM, Robert Raszuk <[email-masked]> wrote:

> IRSCP ... http://sysnet.ucsd.edu/~**pverkaik/pubs/irscp-**usenix2007.pdf<http://sysnet.ucsd.edu/~pverkaik/pubs/irscp-usenix2007.pdf>
>
First of all, I do think that it's a good idea to have a SDN research forum
in IRTF. The scope being described by David makes sense, though, to me, it
looks like some of the things being cooked in ONF too.

Second, I think we need to focus. When we were floating the SDN ideas in
IETF some nine months ago, we were partly frustrated with the lack of
ability in the tools and protocols available at the time. Also we were
confused by the non-technical claims such as cost reduction and router
replacement. Since then, the industry has come a long way. A lot of solid
technical work and applications have surfaced, and we begin to see the
areas where the standardization would play a role.

If we look at the entire scope of SDN, the most disruptive area is in the
SDN-driven applications. In this area, we are facing a paradigm shift in
network architecture and services, but not necessarily new protocols. What
we need is to present an uniformed network interface to the applications,
but not to define and specify the applications themselves.

Then there is the south-bound network interface portion. Some of the work
has been defined in the context of OpenFlow. Some can be done by the
existing protocols. In this area, there is a strong need to define an
common interface where the application can query and monitor the underlying
networks. We can certainly borrow some of the ideas in ALTO. And the recent
BGP-TE work from Juniper makes a lot of sense too. Also how much we can
borrow from the PCE work would be interesting too.

Further, there is a strong need in the north-bound network interface, where
the applications can interface with the SDN "controller" and issue commands
for configuration, monitoring and discovery. There has been a lot of
interface being defined in this area to date, most notably, OpenFlow
Quantum. Nevertheless, we believe that there is a strong need to have
a standardized interface here.

In other words, we need to focus on the interface to applications and the
interface to the networks. Our goal is that, one day, the providers can
create and define new services spanning from virtual machines, to ToR's, to
routers, to transport gears, seamlessly over the existing infrastructure,
and transparent to the applications.

> SDN is like a knife .. you can really hurt yourself if you are not careful
> yet imagine life without one. Till date vendors were preparing sandwiches
> for you .. now there is opportunity for you to do it yourself.
>
>
IMHO, SDN is not a controllable movement. We cannot un-invent something
that has been deployed and working. (I remember a wise guy were saying:
"OpenFlow is here today. Why? We are going to uninvent it?" :-))  But I
think we will be experiencing chaos for some time to come. As always, the
main motivation in SDN is not driven by technology choices, rather, it's by
business incentive and opportunities. In the past many months, I have
spoken to many SDN-related parties, and the answers are everywhere. :-) But
as soon as we align the answers with their business, they all make perfect
sense. :-)

So yes, it's like a knife, and the network, as we know it, will be forever
changed after this. ;-)

Regards,

Ping

>> http://www.youtube.com/watch?**v=VLHJUfgxEO4<http://www.youtube.com/watch?v=VLHJUfgxEO4>
>>
>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 12 May 2012 00:09:02 +0200

Hello Ping,

Some specific comments ...

> First of all, I do think that it's a good idea to have a SDN research
> forum in IRTF. The scope being described by David makes sense, though,
> to me, it looks like some of the things being cooked in ONF too.

I do not mind having one more group to discuss SDN .. the more the 
better. However I think there is really no clarity reg what belongs to 
IRTF vs IETF. Some consider SDN as pure research and future from the 
light years ahead of us and some have deployed SDN applications already 
in production.

If IRTF will focus on System Complexity type of issues per today's 
slides from Dave then perhaps it is a good idea to separate it from SDNP.

> replacement.

Well believe it or not those non-technical claims are real today. And if 
you recall keynote talk from Ito-san during last ONF meeting they were 
listed on his slides.

> If we look at the entire scope of SDN, the most disruptive area is in
> the SDN-driven applications. In this area, we are facing a paradigm
> shift in network architecture and services, but not necessarily new
> protocols. What we need is to present an uniformed network interface to
> the applications, but not to define and specify the applications themselves.

100% agree !

> Then there is the south-bound network interface portion. Some of the
> work has been defined in the context of OpenFlow. Some can be done by
> the existing protocols. In this area, there is a strong need to define
> an common interface where the application can query and monitor the
> underlying networks.

Actually query and monitoring underlying networks is not sufficient at 
all. "Defined" means that application can insert required state into the 
network. Such state can be as simple as destination based route or as 
complex as L1 to L7 match to perform some forwarding decision.

Here horizontal network slicing comes into the picture. Again you are 
right that the idea is not new. For years vendors were busy on 
Multi-Topology-Routing slicing or virtual/logical network planes - and 
real customers were and still are asking for it.

With SDN and in particular with OF new tool has surfaced - FlowVisor. I 
do not know if this is the topic for IRTF or IETF, but horizontal 
network slicing yet controlling the scope of each slice is gaining a lot 
of real attention both in the running networks (OFELIA) as well as 
starting to become a consideration in number of other non-research 
projects.

> We can certainly borrow some of the ideas in ALTO.
> And the recent BGP-TE work from Juniper makes a lot of sense too. Also
> how much we can borrow from the PCE work would be interesting too.

Here honestly I am not sure if this is good idea to "borrow" pieces from 
here and there. I would rather let those work continue as-is in their 
respective working groups and let the SDN application designer to choose 
which standard based ingredient he considers fit to his project.

> Further, there is a strong need in the north-bound network interface,
> where the applications can interface with the SDN "controller" and issue
> commands for configuration, monitoring and discovery. There has been a
> lot of interface being defined in this area to date, most notably,
> OpenFlow Quantum. Nevertheless, we believe that there is a strong need
> to have a standardized interface here.

Brilliant idea however there is one fundamental problem to realize it. 
The higher you bring the abstraction from actual data plane the harder 
it becomes to match diverse needs of the SDN applications.

Let's bring one example ...

- Do you find feasible for vendors to provide you the same API to their 
global RIBs .. even for simplicity assuming only destination based 
forwarding paradigm ?

+

- And do you expect them to drop the price of the box 10 times or more 
to match commodity gear if customers comes and says I want this box with 
RIB API, but without license to your control plane ?

> In other words, we need to focus on the interface to applications and
> the interface to the networks. Our goal is that, one day, the providers
> can create and define new services spanning from virtual machines, to
> ToR's, to routers, to transport gears, seamlessly over the
> existing infrastructure, and transparent to the applications.

I think that "one day" has already happened. Of course it does depend 
what infrastructure you have ;).

> So yes, it's like a knife, and the network, as we know it, will be
> forever changed after this. ;-)

100% agreed !

Best regards,
R.

---

From: Ping Pan <[email-masked]>
Date: Fri, 11 May 2012 16:01:05 -0700

> you recall keynote talk from Ito-san during last ONF meeting they were
My problem was that I understand the methods in deriving network
development and deployment cost and the margins. What thrown me off is the
introduction of non-networking-vendor-related dirt-cheap networking
switches: simple boxes with simple OpenFlow or routing function at an
off-the-chart discount.

This level of economics, IMHO, makes a lot of non-technical claims somewhat
real...

> Multi-Topology-Routing slicing or virtual/logical network planes - and real
> customers were and still are asking for it.
>
> With SDN and in particular with OF new tool has surfaced - FlowVisor. I do
> not know if this is the topic for IRTF or IETF, but horizontal network
> slicing yet controlling the scope of each slice is gaining a lot of real
> attention both in the running networks (OFELIA) as well as starting to
> become a consideration in number of other non-research projects.
>
>
>
Let's keep the actual implementation of FlowVisors out of the scope of any
standard bodies. :-) But the horizontal slicing is very good idea. Let's
talk in detail off-line. ;-)

> which standard based ingredient he considers fit to his project.
OK.

> Brilliant idea however there is one fundamental problem to realize it. The
> higher you bring the abstraction from actual data plane the harder it
> becomes to match diverse needs of the SDN applications.
>
> - And do you expect them to drop the price of the box 10 times or more to
> match commodity gear if customers comes and says I want this box with RIB
> API, but without license to your control plane ?
>
>
Frankly, I know what you are saying, but don't know the answer. I think
that a lot of answers will emerge, not through academic guess, rather from
actual deployment.

Regards,

Ping

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 12 May 2012 01:18:58 +0200

> Let's keep the actual implementation of FlowVisors out of the scope of
> any standard bodies. :-)

Why ? Shouldn't we rather do the opposite ? Acknowledge the values of 
good ideas and standardize them ?

IETF has already spend a lot of time to standardize slicing of IGPs for 
MTR. Market proved that it was not that good of idea after all.

It could be that if we attempt to standardize FlowVisor's approach to 
horizontal network slicing, we could really get to the crux of the 
issues which are obstacles for innovation and true SDN deployments in 
the current networks.

Best,
R.

---

From: [email-masked]
Date: Sat, 12 May 2012 20:04:58 +0530 (IST)

Hi,
 I fervently hope the below orthogonal viewpoint is not completely obtuse...

Escheric Interpretation of Network Operations:
Orthogonality and Duality are tightly related.  What Escher in the
Waterfall has done could be interpreted as to give a visual depiction of
the interplay between orthogonality and duality.  To keep it simple let us
consider two dimensions alone.  It would have been very difficult to
depict a conduit move down and the water flowing down at the same time if
there were no horizontal extent to the conduit.   The horizontal component
is one of the orthogonal component, and the vertical the other. 
Conservation demands that as one orthogonal component increases the other
one decreases to compensate.  The apparent contradiction in the stepping
down of   the conduit and water  to later fall is an expression of  two
orthogonal components balancing each other.
Let us for the moment get  rid of the "discontinuity" of the water
suddenly falling down and instead imagine for a moment that Escher
continued further  at what is a point of discontinuity down and chose to
step up while the conduit does down and end at the same level at a point
distant from the starting point.  Now we have the analogy to networks and
how Service Providers are now carrying traffic:  Traffic flows from aEnd 
to zEnd all right, both something along the way has gone up and come down,
 what could it be?  Why couldnt it be the level of aggregation
(hierarchical composition)?  From the edge the level of hierarchy to which
the substance(network traffic) is subjected to increases up to the core
and then is deaggregated back to the edge.  There is the going up and down
as traffic simply spatially goes from source to destination.
So, we have a going up and coming down back to the exact same level of
aggregation we started with,  so there has to be some " middle" state
somewhere which is a zero if the goal of carrying the traffic at the same
protocol level to the destination has been achieved.
The Riemann Zeta function and the hypothesis jumps to mind.  The real part
of the Riemann function  is zero.  The function itself has a very
probabilistic appearance to it,  the 1/x and the multiplication(ANDs, ie
the complex exponent) and the additions (ORs).  What would this translate
to?
When the frame is at the source it has well, in an ideally flexibile
network infrastructure at least, has infiinte possibilities to take the
next step. We got to  start from the last term in the Riemann function,
the probability it takes any given next step is 1/infinity,  and then the
available choices  sequentially reduces down to 1.
That leaves the pesky, complex at that, exponential.   What could that be?
 We have  only considered conceptual aggregation not the geographical
expanse along which it takes place. With the following statement i am
making a shameless attempt to gain some brownie points with Mathematicians
which i scheme to leverage to have them spare some time to enlighten us
with their miraculous ways...The apparently  so "real" geographic distance
measure is the actual imaginary thing and the mathematical concept of
aggregation is the  "real real" thing. The absolute truth.
The getting from one point to the next  is viewed fractally, that is the
entire network is fractally composed between point aEnd and point 1 and
there is both the mathematical aggregation and the conceptually imaginary
geographical expanse traversed.  Take for example the last conceptual jump
from the infinite points from source to destination,  and consider
a)the imaginary part is zero,  this allows modeling  n number of
deaggreation steps within the last jump!  Pretty powerful model. Not only
that it  if you consider
b) the real part zero,  n number of physical steps
 and anything in between.
The lay man physicist says what goes up must come down,  there's  got to
be a middle, the Riemanian conceptual middle if the goal has indeed been
achieved,  if the Riemannian middle is not there, the problem could have
been murdered but the soul that has not rested in peace could come back to
haunt us, casparian or not,  the problem is still not truly dead.
Could the SDN controller be another viewpoint of the Reimannian middle for
the network, possibly in the migration scenario with fractal such middles
distributed across the unreal geographic expanse the very real aggregation
layer rates?
Could we have an abstract algebraic representation of the network and
therefore leverage the huge amount of  painstakingly acquired cumulative
knowledge to ensure that the problem dies a natural death and its soul
rests in peace?
Sitaraman

>>ATT's IRSCP ...
>> http://sysnet.ucsd.edu/~pverkaik/pubs/irscp-usenix2007.pdf
>>

---

From: [email-masked]
Date: Sat, 12 May 2012 20:27:54 +0530 (IST)

Apologies, I meant to say the real part of the zero is half...

---

From: [email-masked]
Date: Sun, 13 May 2012 16:47:22 +0530 (IST)

Hi Dave/Ed/Bob,
  I was reading Frenetic that Dave pointed to. Making an analogy with the
Server or Personal Computer using a nework of VLSI circuits in the Chip
i was wondering if there is any effort that provides and "Operating
Systems" layer for the programing languages to work on.
  One could imagine that other languages apart form Freneti may later come
into existence.
  Many of the issues we are discussing could be handled at an abstraction
layer provided by operating systems. For example,
       The O/S could provide services to define coarse grained "processes"
that can time share the "CPU" or parts of it i.e the Network which
plays the role of CPU here.
       Provide coarse grained caching services (along with coherency)
which map to network states akin to memory management, vis a vis
storing in hard disk.
       Security primitives.
       Coarse Grained Schedulers services where network activities can be
given to the scheduler. This for example may be useful to build
applicaitons on top of the programming language for Network
Operations purposes
      And perhaps there are others, such as analogies for services
provided by distributed operating systems.

Sitaraman