[Sdnp] Proposed SDN BOF charter

Anton Ivanov anton.ivanov at kot-begemot.co.uk
Tue Sep 20 04:35:35 EDT 2011

On 20/09/11 08:27, Robert Raszuk wrote:
> Hi Anton,
>> [snip]
>> So what exactly prevents an SDN controller (as initially envisioned by
>> Tom and Ping) extract the relevant information from an SDN plugin which
>> in turn talks low level to the network - either polling via existing NMS
>> methods or talking to protocol extensions?
> The "extract" part.
> What you have extracted in t=0 in t=1 is already obsolete. Note that 
> bandwidth is just one tiny variable. Modern applications require more 
> predictable/guaranteed network behaviour with per application path 
> protection or not.

True, true and true. And what exactly prevents you from extracting the 
fact that all of these stats are short term and you have to "trust" the 
control plane with this and not try to provision it at SDN level?

> The only way around is the ONF approach of controller having full 100% 
> control over network resources and which can at his own decision use 
> this knowledge to centrally control the flows in his part of the 
> network. Assuming non blocking router's and switch fabrics this 
> narrows down to controller "owning" all or part of the links in the 
> network.

Who said no to that? What exactly prevents you from putting SDN as a 
unified interface on top of that controller?

>> The way I understand the SDN goal it is not about instrumentation of the
>> network, it is not about making it dynamic per se.
> Same here. The dynamic factor here is my opinion not possible to get 
> centralized to few controllers. I do think that we would be better of 
> in investigation how to make it fully distributed and instead of 
> defining north/south APIs from controller define very few new network 
> forwarding classifiers. That's it here.

We can, but the way the proposed charter is formulated that is a 
different subject

> Then we can take those and work on how to extend existing protocols in 
> other WGs to accommodate them.

We can, but the way the proposed charter is formulated that is a 
different subject.

> This as a matter of fact may turn around today's ISP business. One may 
> be able to charge for premium application transport on a per packet 
> basis. There are number of applications and customers who will be able 
> to pay for premium application treatment (roaming included).
>> It is about
>> presentation through a uniform interface and API. SDN presents to the
>> applications an interface which may or may not allow all that depending
>> on which plugins plug into the back of the SDN controller. Depending on
>> these you may have the full spectrum starting with "extended IGP"
>> dynamic, jitter and delay information collecting network which can be
>> made to change its state on a ms scale and finishing with a bog standard
>> set of statics.
> I think I see where there is slight divergence in the goals.

Yes. I am looking at one level further up the stack and sticking to the 
proposed BOF charter which says "Do not reinvent the control plane". 
What you are proposing is essentially enhance the control plane and 
making the application interface dependent on said enhancements.

> What you have just stated about is the way to present network 
> abstraction in a uniform way. I am 100% for it and I think this is 
> indeed Tom's #1 objective.

> However this will work fine as network presentation. I hardly see a 
> way to make this also work in other direction .. application modifying 
> the today's network on as needed basis. 

1. There are different levels of as needed.

2. Nobody said that the as-needed may not give more realtime 
requirements information to the underlying plugin and from there on to 
the underlying control plane. However, once again, the way I read the 
charter it is a question of presentation. You simply provide a uniform 
modern interface to apps. From there on be it ONF, be it IMS, be it a 
bunch of young ladies from one well known company which pretends to do 
OSS and hires them for their typing speed. It all becomes the same to 
the application. It commands 'em all the same.

> Hence for that part I would rather see us considering either making 
> networks aware about applications they carry or make it dumb 
> completely and outsource all the brains to controllers (which would 
> not be the first time it is attempted in the industry and clearly not 
> the last one :).

Oh definitely, however IMO one of the reasons why the industry has 
systematically failed at that is exactly because the presentation has 
always been mixed with the control plane. While you and everyone on the 
list understand that, Joe Average Developer looks at it and hiccups 
straight away. I have seen that one time too many and not just with 

That is IMO one of the biggest reasons why application developers frown 
at current control frameworks and prefer to invest into engineering 
their applications around them.

We can repeat that failure once more or try to do something different 
this time. I finally see something different and this is exactly the 
reason why I like it.


> Cheers,
> R.
>> The important thing is that in either case you talk to it the same way.
>> My 2p, cheers,
>>> Fundamental:
>>> ------------
>>>> These abstractions must also
>>>> allow applications to manipulate resources at varying levels of
>>>> granularity, policy and security.
>>> I have just went via all archives of discussions so far and would like
>>> to share my perspective on few comments made on the list so far.
>>> I think it will be pretty accurate conclusion that this BOF/WG aims to:
>>> "The goal is having the applications programming the network, without
>>> breaking it."
>>> "IMHO, we need to leverage the existing control-plane, and try to
>>> "virtualize" and program the physical networks for more efficient data
>>> transport."
>>> Other comments where suggesting to not define new data planes nor do
>>> any changes to existing data planes.
>>> That means that the goal of this WG has been set to: "Making
>>> Applications Network Aware"
>>> If I have an application which is very delay and jitter sensitive or
>>> like someone mentioned should not use 3G but WiFi access to a mobile
>>> device when downloading the new app update that this effectively means
>>> that controller would need to centrally collect and process massive
>>> amount of dynamic network states in order to "manage" or "program" the
>>> network to serve given application. Sorry to say but there are number
>>> of issues with this:
>>> A) Networks today do not report or use in IGP's SPF or BGP best path
>>> jitter, delay, packet loss, e2e path rtt in any path calculation.
>>> B) Even if they would exporting such massive dynamic state up even the
>>> single layer IMHO is a pretty terrible idea.
>>> C) Networks are extremely dynamic. If we have avoided considering
>>> dynamic constrains in routing for all those years it was done for a
>>> reason .. it is hard. Doing it dynamically on controllers then
>>> "programming" the network with the answer is a challenge as by the
>>> time you are done with the computation the network in any of the
>>> decent size has already changed - you may as well start over.
>>> D) If this is to be done from controller POV I think the only way is
>>> to do it in a sort of circuit switching mode ... even if circuit would
>>> be based in flow rule recognition of each packet.
>>> So what is the conclusion ?
>>> ...
>>> Perhaps just thinking loud here, but I would like to solicit group's
>>> feedback on turning 180 degrees from the above goal.
>>> We are in IETF and we all quite well know how to define, build and
>>> operate networks and network protocols.
>>> Why don't we instead of exposing network parameters to applications do
>>> the opposite ... make network application aware ? Today networks just
>>> transport packets. They have no clue on what they carry in those 
>>> packets.
>>> What if the goal of this WG would instead read: "Making Networks
>>> Applications Aware"
>>> Today operationally we could do RSVP Intserv (as Ed very correctly
>>> pointed out). With some recent enhancements we have provided tools to
>>> operators to do the thinking and construct mostly intra-domain TE
>>> paths centrally to engineer the flows. This does not work inter-domain
>>> when we are to talk across continents or globe. This also is all about
>>> control plane reservations therefor any unaccounted flow in the
>>> network messes up the picture.
>>> My vision is to give network a packet and let the network transport it
>>> not only like today by dry SPF or BGP best path rules, but taking into
>>> the forwarding decision the nature/type of such packet.
>>> That means effectively three things:
>>> - define a very small set of application primitives which must be
>>> handled by the network (delay, link affinity, jitter, loss, bandwith,
>>> protection etc ...)
>>> - extend current network protocols to measure and use in their
>>> decision above primitives
>>> - define (or perhaps share with existing work in other similar bodies
>>> example ONF) the way to communicate the primitives to the network (per
>>> packet, per flow, per src application etc ..)
>>> Advantages:
>>> - make the networks smarter to carry today and tomorrow apps,
>>> - completely distribute the smartness,
>>> - supporting small set of primitives would be easy to agree inter-
>>> vendor or inter-provider,
>>> - good scaling property,
>>> - drastic shift from today's "full manual operator control" how his
>>> bits are flowing in entire network or in subset of the network
>>> allowed for being applications aware.
>>> While this is just a very short note I welcome your comments,
>>> questions, flames to the sort of fully reversed out of the box
>>> approach as compared with the just proposed charter.
>>> Best,
>>> R.
>>> _______________________________________________
>>> SDNP mailing list
>>> SDNP at lucidvision.com
>>> http://lucidvision.com/mailman/listinfo/sdnp
> _______________________________________________
> SDNP mailing list
> SDNP at lucidvision.com
> http://lucidvision.com/mailman/listinfo/sdnp

     Humans are allergic to change. They love to say, "We've always
done it this way." I try to fight that. That's why I have a clock
on my wall that runs counter-clockwise.   -- R.A. Grace Hopper

A. R. Ivanov
E-mail:  anton.ivanov at kot-begemot.co.uk

More information about the SDNP mailing list