Subject: [Sdn] New: Software-Defined Networking Research Group (SDNRG)

From: "Eggert, Lars" <[email-masked]>
Date: Mon, 14 Jan 2013 09:24:57 +0000

A new IRTF research group on Software-Defined Networking has been chartered:

  The Software-Defined Networking Research Group (SDNRG) investigates SDN
  from various perspectives with the goal of identifying the approaches that
  can be defined, deployed and used in the near term as well identifying
  future research challenges. In particular, key areas of interest include
  solution scalability, abstractions, and programming languages and paradigms
  particularly useful in the context of SDN. In addition, it is an explicit
  goal of the SDNRG to provide a forum for researchers to investigate key
  and interesting problems in the Software-Defined Networking field.

Charter and participation information can be found at http://irtf.org/sdnrg

Lars Eggert
IRTF Chair

---

From: [email-masked]
Date: Mon, 14 Jan 2013 22:17:43 +0530 (IST)

Hi,
 Some thoughts.
  1. Does the separation of control plane from the forwarding necessarily
mean the control now is to be centralized? It likely is not. Though the
network device itself need not implment the control plane and can be
interacted via an OpenFlow interface, the control funcationality can be
a separate distributed system.
  2. Model to represent Network
     Network and traffic flows are fundamentally flows in capacitated
graphs.  Could we look at using Stanford Graph Processing System
(GPS) for SDN based networks. The periodic communication amongst
nodes seem to naturally map to a traffic and information flow in a
network?

  3. Model to repsresent capacities of network resources and logical
abstractions of physical resources.
     SDN dosent and probably should not change anything fundamental in the
traffic flow itself. This means that here SDN must look into reusing
existing models.  TMF models is a likely candidate.
  4. Model to represent faults.
     Same as above. New type of faults related to the decoupled (possibly
yet distributed) control plane to be harmonized with model for
existing faults. Again TMF is a source.
  5. Model to respresent Business aspects (Products, Orders such as time
to delivery commitments)
     Same as above and again TMF is a source for this model. The new SDN
network could leverage by being able to be invoked or referred to in
the existing TMF business model aspects. After all these are directly
related to revenue and Customer Experience Management.
  6. Is it distributed control, distribution of control or soemwhere in
between that is preferable. Distributed control can be a conceptual
centralized control which is implemented in a distribued manner.  Can
this nature be adaptively changed. Any aspects of learning in control
plane in SDN networks.
  7. Layers of control Ethernet Layer, MPLS layer, IP layer.
  8. Service Providers' bottom line is business and this means the TMF FAB
Fulfilment, Assurance and Billing. SDN models must leverage the existing
model as transparently as is practically feasibile.
Sitaraman

 Possibly of interest.
>
> Begin forwarded message:
>
>> From: "Eggert, Lars" <[email-masked]>
>> Subject: [irtf-discuss] New: Software-Defined Networking Research Group
>> (SDNRG)
>> Date: January 14, 2013 10:24:57 GMT+01:00
>> To: "<[email-masked]>" <[email-masked]>,
>> "<[email-masked]>" <[email-masked]>
>> Cc: "[email-masked]" <[email-masked]>
>> Reply-To: "[email-masked]" <[email-masked]>
>>
> _______________________________________________
> openflow-discuss mailing list
> [email-masked]
> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
>
> --
> 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: Sharon Barkai <[email-masked]>
Date: Tue, 15 Jan 2013 04:25:29 +0000

These bring up interesting global-local distinctions.

The scope of a flow definition is clearly local to the aggregation point:
IP, IP-Port (NAT etc), TCP connection, HTTP pipeline with a connection ..depends.

The context of handling a flow in a specific point is clearly has global user-app considerations.
Distributing control logic is therefore according to global context mapping not aggregation topology. This is different then control distribution considerations for packet forwarding.

The touch point between control and forwarding is therefore a practical choice.
The control has to be both locally (scope & mechanics) and globally (user-app) aware.

Overlays work quite well in that sense, global awareness by distributed clustering,
local touch point splits, or merges encapsulates flows based on global pipeline need.

On Jan 14, 2013, at 17:49, "[email-masked]" <[email-masked]> wrote:

Hi,
Some thoughts.

Possibly of interest.

_______________________________________________
sdn mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/sdn

---

From: [email-masked]
Date: Tue, 15 Jan 2013 10:54:40 +0530 (IST)

Hi Sharon,
  Thanks for these valuable insights.
  In the preSDN networking world, due to practicality of evolution and
backward compatibility needs there arose multiple ways of doing the same
thing….i.e gather and use graph reachability information.
  SDN is our chance to begin with a clean slate, while we need not throw
the interoperation with existing networks totally out the window, we
must also be careful not to avoid falling into the trap of restricting
the capabilities and flexibility due to its need, even at first as
options in isolation, for SDN.
  What we could consider in IRTF is standardizing a single way to gather
reachability information (in a capacitated graph, typically). Indeed as
you point out very aptly, such reachability information can be of
varying geographical spans and varying aggregation level spans and these
can have causal connections. If I understand you correctly, an
Aggregration pivot has implications on the geographic spans that need to
considered, and such aggregation pivots serve to segment/split the
geographic expanse (conceptually in the graph model of the network that
is) that the control has to deal with.
  It appears then if only we have a control of a control that based on the
specified aggregation pivots redistribute the division between
distributed control and distribution of control that when combined with
operations on Graph model with scalable algorithmic schemes as mentioned
in GPS, then we will have a powerful means to exercise traffic control,
shaping and delivery which are the fundamental aspects of any network. 
A source of complexity we may need to handle is to be able to allow for
multiple instances of such distributed control and distribution of
control working together.
  Such segmentation between distributed control and distribution of
control also could yield to a scalable solution…
 Sitaraman

> Distributing control logic is therefore according to global context
> mapping not aggregation topology. This is different then control
> distribution considerations for packet forwarding.
>

---

From: Sharon Barkai <[email-masked]>
Date: Tue, 15 Jan 2013 06:11:23 +0000

depends on what you try to achieve-

if you try to extend network reach then back-comp interoperable control is key, therefore a "need to know basis" distribution (topo) makes that feasible. 

If you try to extended network functionality, your control distribution emphasis changes significantly, and you still have to consider the touch point of the control application with the wire - tcams, scope, aging, etc

Since non of these reach & function needs are going away it looks like SDN overlays on IP can be used to sandbox the conflicting requirements. I haven't seen a hammer other then layers that can handle such different nails.

On Jan 15, 2013, at 6:26 AM, "[email-masked]" <[email-masked]> wrote:

Hi Sharon,
thing..i.e gather and use graph reachability information.
control also could yield to a scalable solution.
Sitaraman

> The context of handling a flow in a specific point clearly has global
> user-app considerations.

---

From: [email-masked]
Date: Tue, 15 Jan 2013 11:47:43 +0530 (IST)

Hi Sharon,
 Would appreciate if you could elaborate on the extended network
functionality and the conflict between the reach and
functionality...Thanks
Sitaraman
> if you try to extend network reach then back-comp interoperable control is
> key, therefore a "need to know basis" distribution (topo) makes that
> feasible.
>
> If you try to extended network functionality, your control distribution
> emphasis changes significantly, and you still have to consider the touch
> point of the control application with the wire - tcams, scope, aging, etc
>
> Since non of these reach & function needs are going away it looks like SDN
> overlays on IP can be used to sandbox the conflicting requirements. I
> haven't seen a hammer other then layers that can handle such different
> nails.
>
>
>

---

From: Sharon Barkai <[email-masked]>
Date: Tue, 15 Jan 2013 08:14:08 +0000

Happy to but don't want to bear on the list -
Can you take two simple examples and can extrapolate:

One: get a ping across to multiple locations, with different gear from different generations of hardware and different administrative domains that have no reason to trust one another as an example ISPs from conflicting nations or competing vendors.

Two: globally balance a function instantiated using the same address in multiple locations with global awareness in each location of the exact health state load and affinity associated with each of the resources.  

On Jan 15, 2013, at 7:19, "[email-masked]" <[email-masked]> wrote:

Hi Sharon,

---

From: [email-masked]
Date: Tue, 15 Jan 2013 13:55:07 +0530 (IST)

Thanks Sharon,  Looking at the examples, I seem to think the second one
has a strong reach component to it, only the reach is not for the traffic
that is carried but metadata about the traffic?
Sitaraman
> One: get a ping across to multiple locations, with different gear from
> different generations of hardware and different administrative domains
> that have no reason to trust one another as an example ISPs from
> conflicting nations or competing vendors.
>
> Two: globally balance a function instantiated using the same address in
> multiple locations with global awareness in each location of the exact
> health state load and affinity associated with each of the resources.
>
>
>

---

From: Rana Sircar <[email-masked]>
Date: Tue, 15 Jan 2013 13:59:20 +0530

Dear Sitaraman,

In my opinion, there could be three scenarios for SDN deployment -
1. Greenfield deployment
2. Upgrade from existing
3. Transformation of current network

Any deployment is cost intensive. Thus, fork-lift upgrades may not be the
first choice for many. Thus, we should not create the use cases such a way
as to support only fork-lift upgrades.

I like the idea of Overlay networks. It is always helpful to roll-out new
technologies.

Best Regards,
Rana Pratap Sircar
GSM+919899003705|

---

From: [email-masked]
Date: Tue, 15 Jan 2013 14:02:25 +0530 (IST)

Hi Rana,
 I agree completely with the approach you are suggesting, but i do not see
why that negates or even changes the considerations i have raised on the
control plane deployment styles?
Sitaraman
>> > The context of handling a flow in a specific point is clearly has
>> global
>> > user-app considerations.
>> > The touch point between control and forwarding is therefore a
>> practical
>> > choice.
>> > Overlays work quite well in that sense, global awareness by
>> distributed
>> > clustering,
>> >>> from various perspectives with the goal of identifying the
>> approaches
>> >>> that

---

From: Rana Sircar <[email-masked]>
Date: Tue, 15 Jan 2013 15:12:04 +0530

Hi Sitaraman,

As I understand, you are keen on fixing a single way to
get reach-ability information from the nodes - which is based on GPS.
Thereby, in a way you are doing two things -
1. Creating a fixed way of routing in Control plane
2. Creating a fixed topology for control - that is centralized logically

If my understanding is correct, then how do you propose to migrate from
current topologies to the one proposed by you?

Best Regards,
Rana Pratap Sircar
GSM+919899003705|

On 15 January 2013 14:02, <[email-masked]> wrote:

> >> thingů.i.e gather and use graph reachability information.
> >> control also could yield to a scalable solutionů
> >>  Sitaraman
> >>
> >>
> >> >

---

From: [email-masked]
Date: Tue, 15 Jan 2013 15:18:17 +0530 (IST)

Hi Rana,
 Thanks for the discussion.
 GPS was more of mooting an implementation choice which (GPS or something
similar) philosophy seemed to mesh very well with the problem at hand. So
let us set that aside for now, as it dosent impact this particular topic
of discussion.
 I did not intend to come across as saying that there should be only a
single way to get reachability information in the control. But i did
intend to say that there should be a single way (that is, there is a
single solution possible, but that does not claim to be the only solution
that will work to get reachability information).
 In addition this single way of getting the reachability could also be
able to get reachability information from the existing sources of such
information too...
Sitaraman
>> >> thingÅ¯.i.e gather and use graph reachability information.
>> >>   It appears then if only we have a control of a control that based
>> on
>> >> the
>> >> control also could yield to a scalable solutionÅ¯
>> >>  Sitaraman
>> >>
>> >>
>> >> >
>> >> > IP, IP-Port (NAT etc), TCP connection, HTTP pipeline with a
>> connection
>> >> > ..depends.
>> >> >
>> >> > local touch point splits, or merges encapsulates flows based on
>> global
>> >> > pipeline need.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > interacted via an OpenFlow interface, the control funcationality
>> can
>> >> be
>> >> >     SDN dosent and probably should not change anything fundamental
>> in
>> >> the
>> >> >  8. Service Providers' bottom line is business and this means the
>> TMF
>> >> FAB
>> >> >>> The Software-Defined Networking Research Group (SDNRG)
>> investigates
>> >> SDN
>> >> >>> goal of the SDNRG to provide a forum for researchers to
>> investigate
>> >> key

---

From: Edward Crabbe <[email-masked]>
Date: Tue, 15 Jan 2013 10:33:00 -0800

Quick correction here: IRTF /not/ IETF.  IRTF doesn't produce standards.

---

From: bhal d <[email-masked]>
Date: Tue, 15 Jan 2013 10:39:15 -0800 (PST)

This is great discussion. Since we are talking about "Software defined", I think it implies some type of software programmability of a network. In present day I haven't seen too many applications trying to program network. So it is a new concept for them. So how about first defining, what programmability of network means in simple terms ? 
I think many programmers are not networking experts and don't necessarily understand details about different protocols, link types, topological graphs etc. However for them behavior of their application is important and they certainly understand importance of things like control over available bandwidth, data loss, availability of network, having shortest path to the destination etc. So my question is can we define what programmability or "software defined " means in simple terms ? We can then go on to define what it takes to create that programmability including API, infrastructure etc.
This discussion can also involve what level of network programmability is desirable and then there can be a discussion about what is achievable.
At present I see most of the discussion about splitting control plane and data plane or distributed controller etc. All this discussion is good but without considering what user wants and type of user programmability model we have in mind, it is incomplete.
Thanks
Bhalchandra
--- On Tue, 1/15/13, [email-masked] <[email-masked]> wrote:

From: [email-masked] <[email-masked]>
Subject: Re: [Sdn] [openflow-discuss] Fwd: [irtf-discuss] New: Software-Defined Networking Research Group (SDNRG)
To: "Rana Sircar" <[email-masked]>
Cc: "Eggert, Lars" <[email-masked]>, "Sharon Barkai" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tuesday, January 15, 2013, 1:48 AM

Hi Rana,

---

From: David Meyer <[email-masked]>
Date: Tue, 15 Jan 2013 08:52:55 -1000

On Tue, Jan 15, 2013 at 8:39 AM, bhal d <[email-masked]> wrote:

>
> This is great discussion. Since we are talking about "Software defined", I
> think it implies some type of software programmability of a network. In
> present day I haven't seen too many applications trying to program network.
> So it is a new concept for them. So how about first defining, what
> programmability of network means in simple terms ?
> I think many programmers are not networking experts and don't necessarily
> understand details about different protocols, link types, topological
> graphs etc. However for them behavior of their application is important and
> they certainly understand importance of things like control over available
> bandwidth, data loss, availability of network, having shortest path to the
> destination etc. So my question is can we define what programmability or
> "software defined " means in simple terms ? We can then go on to define
> what it takes to create that programmability including API, infrastructure
> etc.
> This discussion can also involve what level of network programmability is
> desirable and then there can be a discussion about what is achievable.
> At present I see most of the discussion about splitting control plane and
> data plane or distributed controller etc. All this discussion is good but
> without considering what user wants and type of user programmability model
> we have in mind, it is incomplete.
>

dmm> actually my sense (and experience) is quite different. While I can
agree that in the early days of "SDN" folks were talking about the issues
you mention (splitting the control and data planes, programmable forwarding
planes, etc), generally thinking in both the research community and
industry and evolved quite a bit to include not only OF/SDN but a much
wider scope. Consider for example I2RS or PCE(P), or what's going on in *Sophia
Antipolis* this week (ETSI ISG on NfV). In addition, there are robust
discussions going on (again, both in industry and in the research
community) around the question of abstractions for "network programming" as
well as ecosystem models for SDN. BTW, there are literally hundreds of use
cases proposed by every segment of the network community around some form
of network programmability, data models, and the like. --dmm

Thanks
> Bhalchandra
> --- On *Tue, 1/15/13, [email-masked] <[email-masked]>*wrote:
>
>
> Subject: Re: [Sdn] [openflow-discuss] Fwd: [irtf-discuss] New:
> Software-Defined Networking Research Group (SDNRG)
> Cc: "Eggert, Lars" <[email-masked]>, "Sharon Barkai" <
> [email-masked]>, "[email-masked]" <[email-masked]>, "
> [email-masked]" <
> [email-masked]>
> > On 15 January 2013 14:02, <[email-masked]<http://mc/compose?to=[email-masked]>>
> wrote:
> >
> >> Hi Rana,
> >> > On 15 January 2013 10:54, <[email-masked]<http://mc/compose?to=[email-masked]>>
> wrote:
> >> >
> >> >> Hi Sharon,
> >> >> > On Jan 14, 2013, at 17:49, "[email-masked]<http://mc/compose?to=[email-masked]>
> "
> >> >> > <[email-masked]<http://mc/compose?to=[email-masked]>>
> wrote:
> >> >> >
> >> >> > Hi,
> >> >> > Some thoughts.
> >> >> >>> From: "Eggert, Lars" <[email-masked]<http://mc/compose?to=[email-masked]>
> >
> >> >> >>> To: "<[email-masked]<http://mc/compose?to=[email-masked]>>"
> <[email-masked] <http://mc/compose?to=[email-masked]>>,
> >> >> >>> "<[email-masked]<http://mc/compose?to=[email-masked]>>"
> <[email-masked] <http://mc/compose?to=[email-masked]>>
> >> >> >>> Cc: "[email-masked] <http://mc/compose?to=[email-masked]>" <
> [email-masked] <http://mc/compose?to=[email-masked]>>
> >> >> >>> Reply-To: "[email-masked]<http://mc/compose?to=[email-masked]>"
> <[email-masked] <http://mc/compose?to=[email-masked]>>
> >> >> >>>
> >> >> >> [email-masked]<http://mc/compose?to=[email-masked]>
> >> >> > [email-masked] <http://mc/compose?to=[email-masked]>
> >> >> > [email-masked] <http://mc/compose?to=[email-masked]>
> >> >> [email-masked] <http://mc/compose?to=[email-masked]>
> [email-masked] <http://mc/compose?to=[email-masked]>

---

From: Sharon Barkai <[email-masked]>
Date: Wed, 16 Jan 2013 04:07:51 +0000

Yes, but not exactly.

In the first example we want to achieve basic packet delivery service that works under the worst possible conditions.
After all the Internet was first designed to withstand a nuclear strike.  

In the second example we ask for much more. Essentially we ask the network to perform global balancing or global map-reduce on behalf of applications. Instead of each app doing its own.

This level of network programmability is possible IFF there is a basic underlying connectivity because its based on distributed SDN control software.
This is a bootstrap sequence.

Hence the complementary aspect of traditional and software defined networking and the overlay models SDN models converge towards.

Based on this basic reachability you can also apply sophisticate traffic engineering for certain flows on graphs, facilitate mobility and workflows etc.
Additional driver is security and the ability to account for each and every packet. This is virtually impossible under the autonomous control models, but again without that foundation you can not build these next levels of functionality.

Hope this makes sense - it's supposed to simplify network management as well - because sophisticated configuration need not be scattered into interface configuration - end points are moving between those. Instead, all SDN programable policies should be available in a similar to database programming mode vs manager-agents mode, for the complex and massive things at least.  

Sent from my iPhone 650 492 0794

On Jan 15, 2013, at 9:27 AM, "[email-masked]" <[email-masked]> wrote:

---

From: [email-masked]
Date: Wed, 16 Jan 2013 10:11:45 +0530 (IST)

Thanks Sharon for the engaging discussion...you throw insightful
perspectives...
 I will get back to the below shortly, but i have an overall feeling as
follows.
 SDN must create a paradigm shift in Networking that it is designed to do.
SDN network will have truly lived up to its promise and potential if one
day the networks dont look at all like todays. SDN folks should have this
freedom so that the concept can be exploited to the fullest.

 Granted, this may take a while, quite a while even. But this potential
must be kept in mind until realization and kind of avoid throwing the
baby with the bathwater. I do agree that the delay/evolutionary as
opposed to revolutionary pace could be necessary for criterias other than
technical such as economic interests of a complex meshed network of
businesses that have heavy sunken production, research and strategic
investments and interrelationships. Ironically it could be these very
businesses that have the muscle to see this technology to fruition. Slow
gradual transition is necessary but perhaps necessary evil :-)
 The key is to have an architecture that allows for a smooth transition
from overlays with traditional network but i would like to stress that 
it could be very important to factor in the need to not limit the
complete decoupling when the time is right. This is why i was discussing
the possibility of defining the SDN control (network, application and
all) hierarchically on top of existing controls therefore allowing for a
neat removal of the traditional control when time arises and slide in the
SDN control purely without having to go back to the drawing board or
worse having to lock in with it for any longer than necessary...
Sitaraman
> Yes, but not exactly.
>
> In the first example we want to achieve basic packet delivery service that
> works under the worst possible conditions.
> In the second example we ask for much more. Essentially we ask the network
> to perform global balancing or global map-reduce on behalf of
> applications. Instead of each app doing its own.
>
> This level of network programmability is possible IFF there is a basic
> underlying connectivity because its based on distributed SDN control
> software.
> Hence the complementary aspect of traditional and software defined
> networking and the overlay models SDN models converge towards.
>
> Based on this basic reachability you can also apply sophisticate traffic
> engineering for certain flows on graphs, facilitate mobility and workflows
> etc.
> Additional driver is security and the ability to account for each and
> every packet. This is virtually impossible under the autonomous control
> models, but again without that foundation you can not build these next
> levels of functionality.
>
> Hope this makes sense - it's supposed to simplify network management as
> well - because sophisticated configuration need not be scattered into
> interface configuration - end points are moving between those. Instead,
> all SDN programable policies should be available in a similar to database
> programming mode vs manager-agents mode, for the complex and massive
> things at least.
>