[Sdnp] Proposed SDN BOF charter

[Robert Raszuk]

Shane,

I think we all have here our own perspective how SDNP may be useful. I
see it more useful in a sort of conductor-less fashion or fully
distribute conductor residing on each network element, but this is I
think minor detail at this point.

However in the below email one point you made got my particular
attention and if you could I would like to drill it a bit :)

> My gut feeling is this *probably*
> happens in the SDNP plug-ins, because conceptually they are supposed
> to understand the intimate details of the control SW and/or fwd'ing
> HW that they are speaking with to make a certain fwd'ing action
> happen on behalf of the SDNP conductor ... in fact, if/when the SDNP
> plug-in cannot program fwd'ing state in HW (perhaps because the
> plug-in wasn't good at aggregating HW state) it needs to return a
> "busy signal" to the SDNP conductor which can then tell the
> application to 'try again'.

"Busy signal" usually means no resources ... no resources can happen 
when we reserve resources for something else.

So question .. Do you envision one role of SDNP to reserve any network 
resources ?

Even asking for resources during any admission control make sense when 
if available we will reserve those for the duration of our conversation 
as well as all other conversations will do exactly the same for a given 
resource pool.

That is why I was insisting that network recognizes the packets rather 
then application start telling the network list of requested resources 
required for given conversation. Not that this is bad idea .. but there 
will be years to come between all applications speak the new language 
and in the mean time those which do need to still shoot in the dark.

Many thx,
R.