Subject: Re: [Sdn] {Disarmed} Re: [openflow-discuss] Fwd: [irtf-discuss] New: Software-Defined Networking Research Group (SDNRG)

From: [email-masked]
Date: Wed, 16 Jan 2013 07:33:21 +0530 (IST)

Ref: http://conferences.sigcomm.org/sigcomm/2012/paper/hotsdn/p43.pdf
It appears to me we are discussing multiple aspects here all of which are
relevant and important. At least two of which are
1. Architecture of the system (an SDN based network): This includes how
many controller sub components are there, do they work in parallel what is
their paradigm of communicating (in groups, summarization), what
topologies they form (not network topologies but the controller
themselves), aggregation, traffic related activities are performed where
and by whom and policyt related activites are performed by where and whom
2. Programming the system with the said Architecture. This (see Ref.) can
occur at several layers of granularity. This deals with how we give
expressivity using increasingly higher level languages (Assembly, C/C++,
Perl Java, Scripting...) to exploit the capabilities provided by the
hardware.
 1. and 2. are related yet different. The parallels to Computing industry
is almost complete. Indeed Sun was right, the Network IS the Computer!!

 Dave had earlier pointed us to
 In case you haven't seen these:
http://conferences.sigcomm.org/sigcomm/2012/hotsdn.php

--dmm

 Maybe we can look at some of these....

> I agree that there are several different discussions in networking
> communities about programmability.  However, most of the discussions still
> focus on topics like control plane/data plane, distributed vs centralized
> control plane, scalability of solutions, Hybrid solutions, call graph,
> networking models etc. The discussion in this thread is no exception. I
> think these discussions are very good but they need to happen in the
> context of overall programmability goals.
> Thanks
> Bhalchandra
>
> --- On Tue, 1/15/13, David Meyer <[email-masked]> wrote:
>
> From: David Meyer <[email-masked]>
> Subject: Re: [Sdn] [openflow-discuss] Fwd: [irtf-discuss] New:
> Software-Defined Networking Research Group (SDNRG)
> To: "bhal d" <[email-masked]>
> Cc: "Rana Sircar" <[email-masked]>, [email-masked],
> "Sharon Barkai" <[email-masked]>, "LarsEggert" <[email-masked]>,
> "[email-masked]" <[email-masked]>, "[email-masked]"
> <[email-masked]>
> Date: Tuesday, January 15, 2013, 10:52 AM
>
>
>
> 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:
>
>
> 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,
>  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
>> 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:
>>
>>> 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
>
>>> > 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|
>>> >
>>> >
>>> > On 15 January 2013 10:54, <[email-masked]> wrote:
>
>>> >
>>> >> 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
>
>>> >>
>>> >>
>>> >> >
>>> >> > 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.
>>> >> >  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]>
>
>>> >> >>>
>>> >> >>> 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
>
>>> >> >>
>>> >> >> _______________________________________________
>>> >> >> 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.
>
>>> >> >
>>> >> > _______________________________________________
>>> >> > sdn mailing list
>>> >> > [email-masked]
>
>>> >> > https://www.irtf.org/mailman/listinfo/sdn
>>> >> >
>>> >> >
>>> >> > _______________________________________________
>
>>> >> > 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.
>>> >>
>>> >> _______________________________________________
>
>>> >> 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.
>>>
>>>
>>
>> --
>> 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.
>
> _______________________________________________
>
> sdn mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/sdn
>
>
> _______________________________________________
>
> 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.