[Sdnp] Proposed SDN BOF charter
robert at raszuk.net
Tue Sep 20 14:32:50 EDT 2011
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
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
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.
More information about the SDNP