[Sdnp] Proposed SDN BOF charter

[Thomas Nadeau]

	Hi!

	I got around to the administrative tasks on the server last night. Responses to your queries below:

> All,
> 
> Few minor comments and one fundamental one.
> 
> Minor:
> ------
> 
>> Mailing Lists: General Discussion: sdnp at lucidvision.com To Subscribe:
>> https://www.lucidvision.comf/mailman/listinfo/sdnp
> 
> Broken link. Use this one:
> http://lucidvision.com/mailman/listinfo/sdnp

	I just verified that both of these work now:

https://lucidvision.com/mailman/listinfo/sdnp

http://lucidvision.com/mailman/listinfo/sdnp

> 
>> Archive:	    http://www.lucidvision.com/mail-archive/web/sdnp
> 
> Broken link. Use this one:
> http://lucidvision.com/pipermail/sdnp/

	Yes, the archives are available here:

http://lucidvision.com/pipermail/sdnp/

	--Tom



> 
>> Description of Working Group:
>> 
>> Software Driven Networks (SDN)
> 
> Hmmmmm I am under impression that SDN means Software "Defined" Networks
> not "Driven". Are we changing this on purpose here ? IMHO we should stay
> with "Defined" as it makes the objective quite clear.
> 
> 
> 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.
> 
>